Re: [PATCH] fix GIN index search sometimes losing results
От | Tom Lane |
---|---|
Тема | Re: [PATCH] fix GIN index search sometimes losing results |
Дата | |
Msg-id | 30330.1588886131@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [PATCH] fix GIN index search sometimes losing results (Pavel Borisov <pashkin.elfe@gmail.com>) |
Ответы |
Re: [PATCH] fix GIN index search sometimes losing results
|
Список | pgsql-hackers |
Pavel Borisov <pashkin.elfe@gmail.com> writes: > It appeared than GIN index sometimes lose results if simultaneously: > 1 if query operand contains weight marks > 2 if weight-marked operand is negated by ! operator > 3 if there are only logical (not phrase) operators from this negation > towards the root of query tree. Nice catch ... but if you try it with a GIST index, that fails too. Even if it were only GIN indexes, this patch is an utter hack. It might accidentally work for the specific case of NOT with a single QI_VAL node as argument, but not for anything more complicated. I think the root of the problem is that if we have a query using weights, and we are testing tsvector data that lacks positions/weights, we can never say there's definitely a match. I don't see any decently clean way to fix this without redefining the TSExecuteCallback API to return a tri-state YES/NO/MAYBE result, because really we need to decide that it's MAYBE at the level of processing the QI_VAL node, not later on. I'd tried to avoid that in e81e5741a, but maybe we should just bite that bullet, and not worry about whether there's any third-party code providing its own TSExecuteCallback routine. codesearch.debian.net suggests that there are no external callers of TS_execute, so maybe we can get away with that. regards, tom lane
В списке pgsql-hackers по дате отправления: