| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Marco Di Cesare <Marco(dot)DiCesare(at)pointclickcare(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Query with large number of joins |
| Date: | 2014-10-22 13:22:50 |
| Message-ID: | CAHyXU0xrKAHZNhw-BPfPnnRyERP1X8jWmLyeEeo96xn4NijYug@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Oct 21, 2014 at 11:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marco Di Cesare <Marco(dot)DiCesare(at)pointclickcare(dot)com> writes:
>> COUNT(DISTINCT "foxtrot_india"."bravo_romeo")
>
> Ah. That explains why the planner doesn't want to use a hash aggregation
> step --- DISTINCT aggregates aren't supported with those.
yup. With this query, the planner statistics are pretty good for the
most part. Considering that the query is generated and amount of data
is significant the runtime isn't too bad. The query could be
rewritten to support a hash aggregate...
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Igor Neyman | 2014-10-22 13:57:34 | Re: extremly bad select performance on huge table |
| Previous Message | Laurent Martelli | 2014-10-22 06:29:18 | Re: IS NOT NULL and LEFT JOIN |