Heikki Linnakangas <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to