Re: Unclamped row estimates whith OR-ed subplans - Mailing list pgsql-performance

From David G. Johnston
Subject Re: Unclamped row estimates whith OR-ed subplans
Date
Msg-id CAKFQuwazEdPX7VmkAosCs=d1WK2+HFOzJhi9OVxdzf9aj7BPxg@mail.gmail.com
Whole thread Raw
In response to Re: Unclamped row estimates whith OR-ed subplans  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-performance
On Friday, June 19, 2020, Laurenz Albe <laurenz.albe@cybertec.at> wrote:

> I am absolutely aware that those are hashed sub plans below a seqscan and that Postgres therefore has to scan all tuples of the table. But the problem is that upper nodes (which are excluded from
> this example for simplicity) think they will receive 1301316 rows from the seqscan, when in fact they will probably only see a hand full, which the planner could have (easily?) deduced by taking the
> greater of the two subplan row estimates.
>
> What am I missing, or is this perhaps a shortfall of the planner?

The subplans are executed *fpr each row* found in "transactions",
and the estimate on the subplans is *per execution".

I understood Tom’s nearby answer but not this one.  This seems to be referring to correlated subplans which the examples are not.

David J.
 

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unclamped row estimates whith OR-ed subplans
Next
From: "Benjamin Coutu"
Date:
Subject: Re: Unclamped row estimates whith OR-ed subplans