Skip site navigation (1) Skip section navigation (2)

Re: RFC: list API / memory allocations

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFC: list API / memory allocations
Date: 2011-11-21 19:19:24
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Sat, Nov 19, 2011 at 12:33 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> You've mentioned that before and, to be honest, I could have sworn that
> we're doing that already..

I tried to write a patch for that at one point, but it crashed and
burned over the exact same set of issues discussed upthread, which I
wasn't able to resolve satisfactorily.  It's just really difficult to
change the API for something like memory allocation after the fact;
it's too hard to find the bits of code that do whatever naughty thing
you don't want them to.

One random idea... would there by any sense in having a palloc-like
function that is defined to allocate multiple objects at once?  In
other words, if you need 4 list cells, then instead of asking palloc
for them one at a time, you make one function call and get four
pointers back at one go.  I'm not sure whether that would help at all;
palloc might not be able to take advantage of the additional
information usefully.

To some extent I feel like this is all optimizing something that's
likely already so well-optimized that future gains, if any, are likely
to be small.  I feel like the only way we're likely to get much of a
win here is if we can reduce the amount of memory that has to be
allocated in the first place (allocate fewer data structures, don't
copy them as much, etc.).

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-11-21 19:30:37
Subject: Re: psql \ir filename normalization
Previous:From: Robert HaasDate: 2011-11-21 19:05:54
Subject: Re: EXPLAIN (plan off, rewrite off) for benchmarking

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group