From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com>, pghackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Vik Fearing <vik(at)postgresfriends(dot)org> |
Subject: | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |
Date: | 2023-02-15 08:02:31 |
Message-ID: | CAApHDvqkHZsT2gaAWFM7D=7qyQ=eKXQvvn+BkwCn4Rvj1w4EKQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 15 Feb 2023 at 17:23, John Naylor <john(dot)naylor(at)enterprisedb(dot)com> wrote:
> HEAD:
>
> 4 ^ 8: latency average = 113.976 ms
> 5 ^ 8: latency average = 783.830 ms
> 6 ^ 8: latency average = 3990.351 ms
> 7 ^ 8: latency average = 15793.629 ms
>
> Skip rechecking first key:
>
> 4 ^ 8: latency average = 107.028 ms
> 5 ^ 8: latency average = 732.327 ms
> 6 ^ 8: latency average = 3709.882 ms
> 7 ^ 8: latency average = 14570.651 ms
Thanks for testing that. It's good to see improvements in each of them.
> I gather that planner hack was just a demonstration, so I didn't test it, but if that was a move toward something larger I can run additional tests.
Yeah, just a hack. My intention with it was just to prove we had a
problem because sometimes Sort -> Incremental Sort was faster than
Sort. Ideally, with your change, we'd see that it's always faster to
do the full sort in one go. It would be good to see your patch with
and without the planner hack patch to ensure sort is now always faster
than sort -> incremental sort.
David
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2023-02-15 08:03:22 | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |
Previous Message | David Geier | 2023-02-15 07:51:56 | Re: pg_stat_statements and "IN" conditions |