More fun with GIN lossy-page pointers
in [PgSql]
|
Prev: Feel the amatory impulse
Next: [HACKERS] english parser in text search: support for multiple words in thesame position
From: Alvaro Herrera on 31 Jul 2010 21:35 Excerpts from Tom Lane's message of sáb 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 am thoroughly unfamiliar with this stuff, so forgive me if I've gotten the concepts and terminology all wrong) -- Álvaro Herrera <alvherre(a)commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 31 Jul 2010 21:38 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Excerpts from Tom Lane's message of sáb 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? Hmm ... interesting thought. I'm not sure what the implications are, but it's definitely worth considering. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 1 Aug 2010 11:16
Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Excerpts from Tom Lane's message of sáb 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |