| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Sebastien Arod <sebastien(dot)arod(at)gmail(dot)com> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Is postgres able to share sorts required by common partition window functions? |
| Date: | 2020-07-06 22:48:34 |
| Message-ID: | CAKFQuwYWuVZYnX9RCrv__L_0G_WJfGg6R9iPO9d39DK8FHOuWg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Monday, July 6, 2020, Sebastien Arod <sebastien(dot)arod(at)gmail(dot)com> wrote:
> I would have expected postgresql to "share" a preliminary sort on c1 that
> would then be useful to reduce the work on all window functions but it
> doesn't.
>
The plan shown does share - the output of one sort goes into another.
Subsequent sorts still have to happen but they should be faster as the
first field is already grouped. Doesn’t change the plan though.
> I even created an index on c1 hoping that postgresql would be able to use
> it in order to minimize the cost of the sorts but I couldn't make it use it.
>
Use it how? You are still evaluating 250k groups so doing anything
piece-wise seems like an expected loss compared to sequential scan.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Paul McGarry | 2020-07-07 02:06:11 | Efficiently advancing a sequence without risking it going backwards. |
| Previous Message | David G. Johnston | 2020-07-06 22:40:52 | Re: Is postgres able to share sorts required by common partition window functions? |