Re: Fixing GIN for empty/null/full-scan cases
От | Bruce Momjian |
---|---|
Тема | Re: Fixing GIN for empty/null/full-scan cases |
Дата | |
Msg-id | 201101140316.p0E3GXB13910@momjian.us обсуждение исходный текст |
Ответ на | Re: Fixing GIN for empty/null/full-scan cases (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Fixing GIN for empty/null/full-scan cases
|
Список | pgsql-hackers |
Robert Haas wrote: > On Tue, Jan 4, 2011 at 4:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > >> On Tue, Jan 4, 2011 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> * Existing GIN indexes are upwards compatible so far as on-disk storage > >>> goes, but they will of course be missing entries for empty, null, or > >>> null-containing items. ?Users who want to do searches that should find > >>> such items will need to reindex after updating to 9.1. > > > >> This is the only part of this proposal that bothers me a little bit. > >> It would be nice if the system could determine whether a GIN index is > >> "upgraded from 9.0 or earlier and thus doesn't contain these entries" > >> - and avoid trying to use the index for these sorts of queries in > >> cases where it might return wrong answers. > > > > I don't think it's really worth the trouble. ?The GIN code has been > > broken for these types of queries since day one, and yet we've had only > > maybe half a dozen complaints about it. ?Moreover there's no practical > > way to "avoid trying to use the index", since in many cases the fact > > that a query requires a full-index scan isn't determinable at plan time. > > > > The best we could really do is throw an error at indexscan start, and > > that doesn't seem all that helpful. ?But it probably wouldn't take much > > code either, if you're satisfied with that answer. ?(I'm envisioning > > adding a version ID to the GIN metapage and then checking that before > > proceeding with a full-index scan.) > > I'd be satisfied with that answer. It at least makes it a lot more > clear when you've got a problem. If this were a more common scenario, > I'd probably advocate for a better solution, but the one you propose > seems adequate given the frequency of the problem as you describe it. What does pg_upgrade need to do about this for 9.1? Just tell people they might get an GIN error someday? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: