public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: David Rowley <[email protected]>
Cc: Jonah H. Harris <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Reducing System Allocator Thrashing of ExecutorState to Alleviate FDW-related Performance Degradations
Date: Mon, 20 Feb 2023 11:46:48 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAApHDvqWa7zTHq2mnrfnPqZNiPJj+8e+eBFniuVfk-bmupPo0g@mail.gmail.com>
References: <CADUqk8Uqw5QaUqLdd-0SBCvZVncrE3JMJB9+yDwO_uMv_hTYCg@mail.gmail.com>
	<[email protected]>
	<CADUqk8UoG-zg-HEjF5xhPi5=j9h5=_BdCvxWwp1K8EKavbZe0g@mail.gmail.com>
	<[email protected]>
	<CAApHDvrbaGtG5CXRmh0aK5O8EAhxJGwGGXu9=m9GRLOQRkPTkw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAApHDvqWa7zTHq2mnrfnPqZNiPJj+8e+eBFniuVfk-bmupPo0g@mail.gmail.com>

Hi,


On 2023-02-21 08:33:22 +1300, David Rowley wrote:
> On Tue, 21 Feb 2023 at 07:30, Andres Freund <[email protected]> wrote:
> > 2) We should introduce an API mcxt.c API to perform allocations that the
> >    caller promises not to individually free.
> 
> It's not just pfree. Offhand, there's also repalloc,
> GetMemoryChunkSpace and GetMemoryChunkContext too.

Sure, and all of those should assert out / crash if done with the allocation
function.


> I am interested in a bump allocator for tuplesort.c. There it would be
> used in isolation and all the code which would touch pointers
> allocated by the bump allocator would be self-contained to the
> tuplesorting code.
> 
> What use case do you have in mind?

E.g. the whole executor state tree (and likely also the plan tree) should be
allocated that way. They're never individually freed. But we also allocate
other things in the same context, and those do need to be individually
freeable. We could use a separate memory context, but that'd increase memory
usage in many cases, because there'd be two different blocks being allocated
from at the same time.

To me opting into this on a per-allocation basis seems likely to make this
more widely usable than requiring a distinct memory context type.

Greetings,

Andres Freund

view thread (4+ messages)  latest in thread

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Reducing System Allocator Thrashing of ExecutorState to Alleviate FDW-related Performance Degradations
  In-Reply-To: <[email protected]>

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

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