| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | Benjamin Coutu <ben(dot)coutu(at)zeyos(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Unclamped row estimates whith OR-ed subplans |
| Date: | 2020-06-19 16:14:57 |
| Message-ID: | CAKFQuwazEdPX7VmkAosCs=d1WK2+HFOzJhi9OVxdzf9aj7BPxg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Friday, June 19, 2020, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Benjamin Coutu | 2020-06-19 17:33:31 | Re: Unclamped row estimates whith OR-ed subplans |
| Previous Message | Tom Lane | 2020-06-19 16:04:47 | Re: Unclamped row estimates whith OR-ed subplans |