[postgis-devel] CLUSTER in 8.3
kneufeld at refractions.net
Fri Dec 5 12:56:07 PST 2008
I've tried numerous permutations of index type on various data types.
I can't reproduce the problem a btree index on any datatype, but the problem is repeatable on
- our gist,
- btree_gist on integers,
- btree_gist on characters, and
- btree_gist on text using varchar_pattern_ops.
Chris Hodgson wrote:
> Kevin Neufeld wrote:
>> Mark Cave-Ayland wrote:
>> > I think the GiST part is a red herring - there is no way that a
>>> COUNT(*) FROM foo" can use an index in PostgreSQL. My suspicion is
>>> that it's related to the use of ANALYZE/VACUUM/CLUSTER.
>> Maybe. You're right that "SELECT ..." doesn't use the index, but the
>> CLUSTER physically reorders the table based on the index. If there is
>> a bizzare bug in our GiST implementation that produces an empty
>> traversal list some of the time, the table would be empty.
>> Never mind, I just saw Paul's post. This is good news for us in that
>> it's not related to our implementation of GiST ... but it still could
>> be related to PostgreSQL's implementation, no?
> Well, can anyone replicate the problem by clustering on a non-gist
> index? If so, then we should really be able to just throw this problem
> at the Postgres Devs. I'd be surprised if this was the case though, I
> can't believe no-one else would have come across this yet...
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
More information about the postgis-devel