Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> We could probably fix that by adding it to the stats structs that are
>> passed around during VACUUM. I'd rather not hardwire a GIN special case
>> in vacuum.c as per your "quick hack".
> ok. amskipcheck?
Oh, I was thinking of having VACUUM put the heap tuple count into the
struct and then amvacuumcleanup could copy it over to the index tuple
count. A "skipcheck" flag only solves the cosmetic problem of not
getting the warning, it doesn't fix things so that the correct count
ends up in the index's reltuples entry.
>> Actually, does clustering on *any* current index type except btree make
>> sense? None of them have semantically interesting index ordering
> I don't know about hash index, but for GiST clustering can speed up query's
> execution.
OK, in that case we'd better add a real amclusterable flag to pg_am,
rather than assuming amorderstrategy can be used to decide.
> So, two columns about clustering?
> amclustered
> amclusterable
Huh? Why two? Either you are allowed to cluster on indexes of this
type, or you're not. I don't see the point of any other distinction.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
