Re: More fun with GIN lossy-page pointers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of sb jul 31 09:57:13 -0400 2010:
>> So far as I can see, it's impossible to handle this situation when
>> examining only one TID per stream with no lookahead. Choosing to
>> advance the second stream would obviously fail in many other cases,
>> so there is no correct action. The only reasonable way out is to
>> forbid the case --- that is, decree that a keystream may *not*
>> contain both lossy and nonlossy pointers to the same page.

> Would it make sense to order the streams differently? I mean, what if
> whole-page pointers in the lossy stream are processed before regular ones?

I thought about this for awhile and decided that, although it's probably
possible to fix the problem along those lines, it would still add quite
a lot of ugliness to the code. One point in particular is that there's
no natural representation of lossy-page pointers that would make them
sort that way (we can't use blocknum/0 because 0/0 has to be reserved
for ItemPointerSetMin). So part of the price would be to make
compareItemPointers uglier and slower. And we'd still need special
cases in keyGetItem and scanGetItem, to teach them not to advance past a
lossy pointer as long as we were dealing with non-lossy pointers to the
same page in other streams. So on the whole it seems better to confine
the ugliness to the immediately-relevant functions.

regards, tom lane