| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | kimaidou <kimaidou(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Lewis <mlewis(at)entrata(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Aggregate and many LEFT JOIN |
| Date: | 2019-02-26 13:52:29 |
| Message-ID: | CAMkU=1yOtT4xA4SfuPdEqKxcFPNwjXByC5a6f=Tua__yZkAVAQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Feb 25, 2019 at 3:54 AM kimaidou <kimaidou(at)gmail(dot)com> wrote:
> Wich strikes me is that if I try to simplify it a lot, removing all data
> but the main table (occtax.observation) primary key cd_nom and aggregate,
> the query plan should be able tu use the cd_nom index for sorting and
> provide better query plan (hash aggregate), but it does not seems so :
>
HashAggregate doesn't support aggregates with DISTINCT. I don't think
there is any reason it can't, it is just that no one has gotten around to
it.
Aggregates with DISTINCT also kill your ability to get parallel queries.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Lewis | 2019-02-26 19:08:51 | Re: Query slow for new participants |
| Previous Message | Justin Pryzby | 2019-02-26 13:51:34 | Re: Aggregate and many LEFT JOIN |