Re: Gather performance analysis
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-09-24T07:50:35Z
Lists: pgsql-hackers
On Fri, Sep 24, 2021 at 1:30 AM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > > On 9/23/21 9:31 PM, Robert Haas wrote: > > On Wed, Sep 8, 2021 at 2:06 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > >> But I am attaching both the patches in case you want to play around. > > > > I don't really see any reason not to commit 0001. Perhaps some very > > minor grammatical nitpicking is in order here, but apart from that I > > can't really see anything to criticize with this approach. It seems > > safe enough, it's not invasive in any way that matters, and we have > > benchmark results showing that it works well. If someone comes up with > > something even better, no harm done, we can always change it again. > > > > Objections? > > Yeah, it seems like a fairly clear win, according to the benchmarks. > > I did find some suspicious behavior on the bigger box I have available > (with 2x xeon e5-2620v3), see the attached spreadsheet. But it seems > pretty weird because the worst affected case is with no parallel workers > (so the queue changes should affect it). Not sure how to explain it, but > the behavior seems consistent. > > Anyway, the other machine with a single CPU seems perfectly clean. Tomas, can you share your test script, I would like to repeat the same test in my environment and with different batching sizes. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
shm_mq: Update mq_bytes_written less often.
- 46846433a03d 15.0 landed