Re: Use generation context to speed up tuplesorts
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Tomas Vondra <tv@fuzzy.cz>,
PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2021-08-08T12:28:10Z
Lists: pgsql-hackers
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
Commits
-
Use Generation memory contexts to store tuples in sorts
- 40af10b571bd 15.0 landed
-
Adjust tuplesort API to have bitwise option flags
- 77bae396df3f 15.0 landed
-
Improve the generation memory allocator
- 1b0d9aa4f728 15.0 landed