From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Gather performance analysis |
Date: | 2021-09-29 16:39:50 |
Message-ID: | CA+TgmoY829B1KpY3w3PqdRRoDu7oGgt0i6N_N5JKKmL_Sddtbw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 28, 2021 at 2:49 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> 16k 64k 256k 1024k
> Head 1232.779 804.24 1134.723 901.257
> Patch 1371.493 1277.705 862.598 783.481
>
> So what I have noticed is that in most of the cases on head as well as
> with the patch, increasing the queue size make it faster, but with
> head suddenly for this particular combination of rows, column and
> thread the execution time is very low for 64k queue size and then
> again the execution time increased with 256k queue size and then
> follow the pattern. So this particular dip in the execution time on
> the head looks a bit suspicious to me. I mean how could we justify
> this sudden big dip in execution time w.r.t the other pattern.
Oh, interesting. So there's not really a performance regression here
so much as that one particular case ran exceptionally fast on the
unpatched code.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-09-29 17:36:14 | Re: when the startup process doesn't (logging startup delays) |
Previous Message | Richard Yen | 2021-09-29 16:15:14 | Re: Patch to allow pg_filedump to support reading of pg_filenode.map |