Re: [PATCH] fix GIN index search sometimes losing results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] fix GIN index search sometimes losing results
Date: 2020-07-01 19:16:22
Message-ID: 721491.1593630982@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> writes:
> Below is my variant how to patch Gin-Gist weights issue:

I looked at this patch, but I'm unimpressed, because it's buggy.
You would have noticed if you'd included the test cases I wrote:

--- /home/postgres/pgsql/src/test/regress/expected/tsearch.out 2020-07-01 14:58
:56.637627628 -0400
+++ /home/postgres/pgsql/src/test/regress/results/tsearch.out 2020-07-01 14:59
:10.996990037 -0400
@@ -1008,13 +1008,13 @@
SELECT count(*) FROM test_tsvector WHERE a @@ '!wd:A';
count
-------
- 452
+ 2
(1 row)

SELECT count(*) FROM test_tsvector WHERE a @@ '!wd:D';
count
-------
- 450
+ 0
(1 row)

-- Test optimization of non-empty GIN_SEARCH_MODE_ALL queries

In general, I'm not very convinced by your arguments about preserving the
option for external TS_execute callers to still use bool flags/results.
Given what we've seen so far, it seems almost certain that any such code
is buggy and needs to be rewritten anyway. Converting to ternary logic
is far more likely to produce non-buggy code than if we continue to
try to put band-aids on the wounds.

Also, at this point I feel like it's a bit late to consider putting
anything API-breaking in v13. But if this is a HEAD-only patch then
the argument for preserving API is even weaker.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2020-07-01 19:32:38 Re: SQL-standard function body
Previous Message Andres Freund 2020-07-01 18:34:33 Re: POC: postgres_fdw insert batching