From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(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:03:22 |
Message-ID: | CAFBsxsEz9k9K74uT0gfbW1xXnJme5+CVccWTx6_9kOnN-t8-Bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> it might be worthwhile to "zoom in" with more measurements, but haven't
done that yet.
I've attached the script and image for 1 million / random / varying the mod
by quarter-log intervals. Unfortunately I didn't get as good results as
yesterday. Immediately going from mod 1 to mod 2, sort pushdown regresses
sharply and stays regressed up until 10000. The tiebreaker patch helps but
never removes the regression.
I suspect that I fat-fingered work_mem yesterday, so next I'll pick a
badly-performing mod like 32, then range over work_mem and see if that
explains anything, especially whether L3 effects are in fact more important
in this workload.
--
John Naylor
EDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
image/png | 23.6 KB | |
bench_windowsort-jcn-random-finegrained.sh | application/x-shellscript | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | wangw.fnst@fujitsu.com | 2023-02-15 08:16:43 | Fix the description of GUC "max_locks_per_transaction" and "max_pred_locks_per_transaction" in guc_table.c |
Previous Message | David Rowley | 2023-02-15 08:02:31 | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |