pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tv@fuzzy.cz>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Use generation context to speed up tuplesorts
Date: Sun, 8 Aug 2021 14:28:10 +0200
Message-ID: <330e3918-df5c-1ef5-01bb-d3387d12e86d@enterprisedb.com> (raw)
In-Reply-To: <CAApHDvpyYZcFNvisfzZNT-3mgzVOrp52Qr4OiNviGqS8B-DO2A@mail.gmail.com>
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>



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





view thread (50+ messages)  latest in thread

Message-ID: <330e3918-df5c-1ef5-01bb-d3387d12e86d@enterprisedb.com>
Permalink:  ../330e3918-df5c-1ef5-01bb-d3387d12e86d@enterprisedb.com/
Also on:    postgresql.org/message-id/330e3918-df5c-1ef5-01bb-d3387d12e86d@enterprisedb.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@enterprisedb.com, dgrowleyml@gmail.com, andres@anarazel.de, tv@fuzzy.cz, pgsql-hackers@lists.postgresql.org
  Subject: Re: Use generation context to speed up tuplesorts
  In-Reply-To: <330e3918-df5c-1ef5-01bb-d3387d12e86d@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox