Re: On disable_cost - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 6, 2024 at 9:39 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> It's not very clear that this mechanism is actually 100% reliable,

> It isn't. Here's a test case.

Very interesting.

> ... Which then allowed me to
> construct the example above, where there are two possible TID quals
> and the logic in tidpath.c latches onto the wrong one.

Hmm.  Without having traced through it, I'm betting that the
CurrentOfExpr qual is rejected as a tidqual because it's not
considered leakproof.  It's not obvious to me why we couldn't consider
it as leakproof, though.  If we don't want to do that in general,
then we need some kind of hack in TidQualFromRestrictInfo to accept
CurrentOfExpr quals anyway.

In general I think you're right that something less rickety than
the disable_cost hack would be a good idea to ensure the desired
TidPath gets chosen, but this problem is not the fault of that.
We're not making the TidPath with the correct contents in the first
place.

            regards, tom lane