Re: [HACKERS] RFC: list API / memory allocations

2012-08-16 Thread Bruce Momjian
On Thu, Aug 16, 2012 at 09:51:28PM -0400, Stephen Frost wrote: > Bruce, > > * Bruce Momjian (br...@momjian.us) wrote: > > Did we make any headway on this? > > I've got the code written but I need to test it in a stable environment > to see what kind of improvment it provides. I've actually been

Re: [HACKERS] RFC: list API / memory allocations

2012-08-16 Thread Stephen Frost
Bruce, * Bruce Momjian (br...@momjian.us) wrote: > Did we make any headway on this? I've got the code written but I need to test it in a stable environment to see what kind of improvment it provides. I've actually been fighting for the past 2 months with the box that I want to use and think I ma

Re: [HACKERS] RFC: list API / memory allocations

2012-08-16 Thread Bruce Momjian
Is this a TODO? --- On Sat, Nov 19, 2011 at 12:31:09PM -0500, Stephen Frost wrote: > Andres, > > * Andres Freund (and...@anarazel.de) wrote: > > For that I added new functions/defines which allocate all the needed memory >

Re: [HACKERS] RFC: list API / memory allocations

2012-08-16 Thread Bruce Momjian
Did we make any headway on this? --- On Sat, Nov 19, 2011 at 12:31:09PM -0500, Stephen Frost wrote: > Andres, > > * Andres Freund (and...@anarazel.de) wrote: > > For that I added new functions/defines which allocate all the

Re: [HACKERS] RFC: list API / memory allocations

2011-11-21 Thread Robert Haas
On Sat, Nov 19, 2011 at 12:33 PM, Stephen Frost 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 was

Re: [HACKERS] RFC: list API / memory allocations

2011-11-19 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Now, if you could do something that *doesn't* restrict what operations > could be applied to the lists, that would be good. If the API is followed, I believe my previous patch works for everything, but it wasn't variable about the size of the new list. Perh

Re: [HACKERS] RFC: list API / memory allocations

2011-11-19 Thread Stephen Frost
Andres, * Andres Freund (and...@anarazel.de) wrote: > For that I added new functions/defines which allocate all the needed memory > in > one hunk: > list_immutable_make$n(), > List *list_new_immutable_n(NodeTag t, size_t n); > List *list_make_n(NodeTag t, size_t n, ...); A while back, I posted

Re: [HACKERS] RFC: list API / memory allocations

2011-11-18 Thread Andres Freund
On Friday, November 18, 2011 10:11:29 PM Tom Lane wrote: > Andres Freund writes: > > In many scenarios memory allocation is one of the top 3 functions showing > > up in profiles. Looking at hierarchical profiles > > (-fno-omit-frame-pointer) at least during parsing, planning and executor > > start

Re: [HACKERS] RFC: list API / memory allocations

2011-11-18 Thread Tom Lane
Andres Freund writes: > In many scenarios memory allocation is one of the top 3 functions showing up > in profiles. Looking at hierarchical profiles (-fno-omit-frame-pointer) at > least > during parsing, planning and executor startup most of that is spent around > the > list API. > Many - es

[HACKERS] RFC: list API / memory allocations

2011-11-18 Thread Andres Freund
Hi List, In many scenarios memory allocation is one of the top 3 functions showing up in profiles. Looking at hierarchical profiles (-fno-omit-frame-pointer) at least during parsing, planning and executor startup most of that is spent around the list API. Many - especially in the parse-analyz