| From: | David Christensen <david(dot)christensen(at)crunchydata(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
| Subject: | Re: Initdb-time block size specification |
| Date: | 2023-06-30 21:28:59 |
| Message-ID: | CAOxo6XKdN1C39miUZhzAe0n-Cb7hBESQ2B6OQNnM3-0FN-aZMw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 30, 2023 at 3:29 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> And indeed. Comparing e.g. TPC-H, I see *massive* regressions. Some queries
> are the same, sobut others regress by up to 70% (although more commonly around
> 10-20%).
Hmm, that is definitely not good.
> That's larger than I thought, which makes me suspect that there's some bug in
> the new code.
Will do a little profiling here to see if I can figure out the
regression. Which build optimization settings are you seeing this
under?
> Interestingly, repeating the benchmark with a larger work_mem setting, the
> regressions are still quite present, but smaller. I suspect the planner
> chooses smarter plans which move bottlenecks more towards hashjoin code etc,
> which won't be affected by this change.
Interesting.
> IOW, you seriously need to evaluate analytics queries before this is worth
> looking at further.
Makes sense, thanks for reviewing.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2023-06-30 21:29:04 | Re: Should we remove db_user_namespace? |
| Previous Message | Tomas Vondra | 2023-06-30 21:27:45 | Re: Initdb-time block size specification |