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. 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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
