Re: Bitmapscan changes - Mailing list pgsql-patches

From Tom Lane
Subject Re: Bitmapscan changes
Date
Msg-id 17140.1173719845@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bitmapscan changes  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Bitmapscan changes  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-patches
Heikki Linnakangas <heikki@enterprisedb.com> writes:
>>> With the unapplied GIT patch, the index doesn't store the index key of
>>> every tuple.
>>
>> I thought the design was to eliminate *duplicate* keys from the index.
>> Not to lose data.

> The idea really is to lose information from the leaf index pages, in
> favor of a drastically smaller index. On a completely clustered table,
> the heap effectively is the leaf level of the index.

I'm really dubious that this is an intelligent way to go.  In the first
place, how will you keep the index sorted if you can't determine the
values of all the keys?  It certainly seems that this would break the
ability to have a simple indexscan return sorted data, even if the index
itself doesn't get corrupted.  In the second place, this seems to
forever kill the idea of indexscans that don't visit the heap --- not
that we have any near-term prospect of doing that, but I know a lot of
people remain interested in the idea.

The reason this catches me by surprise is that you've said several times
that you intended GIT to be something that could just be enabled
universally.  If it's lossy then there's a much larger argument that not
everyone would want it.

            regards, tom lane

pgsql-patches by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Bitmapscan changes
Next
From: Gregory Stark
Date:
Subject: Packed varlena patch update