From: Tom Lane <tgl@sss.pgh.pa.us>
To: charlie@torqinterface.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16388: Different results when bitmap scan enabled/disabled
Date: Fri, 24 Apr 2020 20:12:31 -0400
Message-ID: <27773.1587773551@sss.pgh.pa.us> (raw)
In-Reply-To: <16388-98cffba38d0b7e6e@postgresql.org>
References: <16388-98cffba38d0b7e6e@postgresql.org>
PG Bug reporting form <noreply@postgresql.org> writes:
> When Postgres uses a bitmap heap scan to evaluate a tsquery that includes !,
> it is giving me different (and incorrect) results compared to when it
> performs a seqscan.
> Can anybody shed some light on this?
It's a bug, without a doubt.
It looks to me like what is happening is that when gin_tsquery_consistent
asks TS_execute if the query is matched, we recurse down to
TS_phrase_execute which does this:
/*
* If either operand has no position information, then we can't
* return position data, only a "possible match" result. "Possible
* match" answers are only wanted when TS_EXEC_PHRASE_NO_POS flag
* is set, otherwise return false.
*/
if ((Ldata.npos == 0 && !Ldata.negate) ||
(Rdata.npos == 0 && !Rdata.negate))
return (flags & TS_EXEC_PHRASE_NO_POS) ? true : false;
so that returns "true" up to the calling TS_execute level:
case OP_NOT:
if (flags & TS_EXEC_CALC_NOT)
return !TS_execute(curitem + 1, arg, flags, chkcond);
else
return true;
which returns "false" and we conclude the index entry doesn't match.
AFAICS this is fundamentally broken and the only way to un-break it
is to introduce explicit three-valued logic, ie we have to return
"maybe" which OP_NOT mustn't invert. Various people have tried to
wiggle around that by inventing assorted more-or-less-bogus flags,
like the TS_EXEC_PHRASE_NO_POS flag seen above, but in the end it
Just Does Not Work to take shortcuts.
Depressingly, although tsginidx.c has decided to invent its
own version with three-valued logic (TS_execute_ternary),
that isn't being used in this scenario ... and it looks like
it'd get the case wrong if it were used, because it's got its
own set of bogosities.
I'll see about getting this fixed in time for next month's
minor releases, but it's definitely not a trivial change.
Thanks for the report!
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, charlie@torqinterface.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16388: Different results when bitmap scan enabled/disabled
In-Reply-To: <27773.1587773551@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox