Re: planner weirdness: a join uses nestloop with checking conditionwhen there are two subplan-or-hashed subqueries - Mailing list pgsql-bugs

From Alexey Bashtanov
Subject Re: planner weirdness: a join uses nestloop with checking conditionwhen there are two subplan-or-hashed subqueries
Date
Msg-id a25b34f8-f3fe-3a74-044a-3ad5ad6b26ce@imap.cc
Whole thread Raw
In response to Re: planner weirdness: a join uses nestloop with checking condition when there are two subplan-or-hashed subqueries  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Hi Tom,

On 25/02/2020 20:34, Tom Lane wrote:
> cost_qual_eval_walker is not very bright about what to do with
> the AlternativeSubPlan constructs.  It looks like it's assuming
> that the non-hashed alternatives will be chosen, which they aren't
> (if they were, this estimate might not be so far out of line).
> But we can't just switch it to make the other assumption, because
> that would skew the results for other cases.

What do you think of making it take both into account?
That's an approximation of a piecewise linear function by a linear one,
so it cannot be very precise, but I think it's better than the current one.

Best, Alex

Attachment

pgsql-bugs by date:

Previous
From: Ruslana Akyk
Date:
Subject: error
Next
From: PG Bug reporting form
Date:
Subject: BUG #16456: Implicit unsigned integer truncation at multixact.c:2626