[postgis-devel] CLUSTER in 8.3

Kevin Neufeld 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.

-- Kevin

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...
> Chris
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

More information about the postgis-devel mailing list