| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Luís Roberto Weck <luisroberto(at)siscobra(dot)com(dot)br> |
| Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Parallel Query |
| Date: | 2019-11-13 22:21:26 |
| Message-ID: | CAMkU=1wqPMzYoRo2zcqwqBkSd_AHnXjPWDmBRnTLFkpCwc7NXw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Nov 13, 2019 at 4:01 PM Luís Roberto Weck <
luisroberto(at)siscobra(dot)com(dot)br> wrote:
>
> Maybe PostgreSQL can't find a way to calculate having estimates?
>
I wasn't even thinking of the HAVING estimates I was thinking of just the
raw aggregates. It can't implement the HAVING until has the raw aggregate
in hand. But, what is the actual row count without the HAVING? Well, I
notice now this line:
Rows Removed by Filter: 6787359
So the row count of rows=86 is mostly due to the HAVING, not due to the raw
aggregation, a point I overlooked initially. So the planner is not
mistaken in thinking that a huge number of rows need to be passed up--it is
correct in thinking that.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Luís Roberto Weck | 2019-11-14 11:14:25 | Re: Parallel Query |
| Previous Message | Jeff Janes | 2019-11-13 22:08:15 | Re: Parallel Query |