On 2016-07-13 16:39:58 -0400, Tom Lane wrote:
> Robert Haas <robertmh...@gmail.com> writes:
> > On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra
> > <tomas.von...@2ndquadrant.com> wrote:
> > What's not clear to me is to what extent slowing down pfree is an
> > acceptable price for improving the behavior in other ways.  I wonder
> > how many of the pfree calls in our current codebase are useless or
> > even counterproductive, or could be made so.
> I think there's a lot, but I'm afraid most of them are in contexts
> (pun intended) where aset.c already works pretty well, ie it's a
> short-lived context anyway.

FWIW, hacking up the aset/mcxt.c to use a trivial allocator with less
overhead (i.e. just hand out sections out of a continuous block of
memory) results in a noticeable speedup in parse heavy workloads. It's a
bit ugly though, because of the amount of retail pfrees in random

> The areas where we're having pain are
> where there are fairly long-lived contexts with lots of pfree traffic;
> certainly that seems to be the case in reorderbuffer.c.  Because they're
> long-lived, you can't just write off the pfrees as ignorable.

That's a problem too.

> I wonder whether we could compromise by reducing the minimum "standard
> chunk header" to be just a pointer to owning context, with the other
> fields becoming specific to particular mcxt implementations.  That would
> be enough to allow contexts to decide that pfree was a no-op, say, or that
> they wouldn't support GetMemoryChunkSpace(), without having to decree that
> misuse can lead to crashes.  But that's still more than zero overhead
> per-chunk.

I think that's a sensible compromise for some use-cases (e.g. parsing,
parse analysis, potentially expression contexts).


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to