Subject: Re: Use generation context to speed up tuplesorts
To: David Rowley <dgrowleyml@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Tomas Vondra <tv@fuzzy.cz>,
 PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
References: 
 <CAApHDvoH4ASzsAOyHcxkuY01Qf++8JJ0paw+03dk+W25tQEcNQ@mail.gmail.com>
 <20210730203853.utjj43f6zzn5e2hy@alap3.anarazel.de>
 <bc765deb-ca2b-838e-f980-16a77dd0922b@enterprisedb.com>
 <d987fd54-01f8-0f73-af6c-519f799a0ab8@enterprisedb.com>
 <CAApHDvp4cFZ6Qdw1Z2wrd1Uv5s6rPKP7FWC5jHFfzR=vU2Ox+w@mail.gmail.com>
 <36829a8a-63d0-c428-89d5-07e49561973e@enterprisedb.com>
 <CAApHDvqMyMQc9b-mBnGvqsudfVysgD4Xz7c7LsGrP524bsv47w@mail.gmail.com>
 <13808af0-2bb5-b506-62d0-1fb67e3385d0@enterprisedb.com>
 <CAApHDvpyYZcFNvisfzZNT-3mgzVOrp52Qr4OiNviGqS8B-DO2A@mail.gmail.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
Message-ID: <330e3918-df5c-1ef5-01bb-d3387d12e86d@enterprisedb.com>
Date: Sun, 8 Aug 2021 14:28:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
 <CAApHDvpyYZcFNvisfzZNT-3mgzVOrp52Qr4OiNviGqS8B-DO2A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/330e3918-df5c-1ef5-01bb-d3387d12e86d%40enterprisedb.com>
Precedence: bulk


On 8/8/21 9:02 AM, David Rowley wrote:
> On Sat, 7 Aug 2021 at 12:10, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:
>>
>> On 8/6/21 3:07 PM, David Rowley wrote:
>>> All of the tests show that the patches to improve the allocation
>>> efficiency of generation.c don't help to improve the results of the
>>> test cases. I wondered if it's maybe worth trying to see what happens
>>> if instead of doubling the allocations each time, quadruple them
>>> instead. I didn't try this.
>>>
>>
>> I doubt quadrupling the allocations won't help very much, but I suspect
>> the problem might be in the 0004 patch - at least that's what shows
>> regression in my results. Could you try with just 0001-0003 applied?
> 
> But 0004 only changes the logic which controls the threshold of when
> we allocate an oversized chunk.  It looks like the threshold is 512KB
> with the 0004 patch.  My test is only doing a maximum allocation of
> 296 bytes so will never allocate an oversized chunk.
> 
> Can you explain why you think 0004 would cause performance regressions?
> 

It's based solely on results of my benchmarks, where this patch seems to 
cause performance regression. I agree it's a bit bizzare, considering 
what the patch does.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company