From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Gather performance analysis |
Date: | 2021-09-24 07:50:35 |
Message-ID: | CAFiTN-s15yEarudGEsLV-SOSXsjSCUYfRUaggi1ESkfiW8RR1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 24, 2021 at 1:30 AM Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>
> On 9/23/21 9:31 PM, Robert Haas wrote:
> > On Wed, Sep 8, 2021 at 2:06 AM Dilip Kumar <dilipbalaut(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | osumi.takamichi@fujitsu.com | 2021-09-24 08:02:38 | RE: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns |
Previous Message | Etsuro Fujita | 2021-09-24 07:20:24 | Re: a comment in joinrel.c: compute_partition_bounds() |