Re: Pre-alloc ListCell's optimization

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pre-alloc ListCell's optimization
Date: 2011-05-27 03:52:35
Message-ID: 20110527035235.GP4548@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Greg Stark (gsstark(at)mit(dot)edu) wrote:
> On Thu, May 26, 2011 at 11:57 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Handling the 1-entry case would likely be pretty
> > straight-forward, but you need book-keeping as soon as you go to two,
> > and all that book-keeping feels like overkill for just a 2-entry cache
> > to me.
>
> Incidentally what if I call nconc and pass a second arg of a list that
> has the first few elements stashed in an array. Do you copy those
> elements into cells before doing the nconc? Does our nconc support
> having lists share cells? I suspect it doesn't actually so perhaps
> that's good enough.

nconc() turns into list_concat() which turns into adding list2 on to the
end of list1 using the other normal lappend() routines which will
utilize space in the cache of list1 if there is space available. Trying
to use the old list2 for storage or much of anything turned into a real
pain, unfortunately. list_concat() does explicitly say that cells will
be shared afterwards and that you can't pfree() either list (note that
there's actually a couple cases currently that I discovered which were
also addressed in the original patch where I commented out those
pfree()'s).

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2011-05-27 03:58:58 Re: Pre-alloc ListCell's optimization
Previous Message Tom Lane 2011-05-27 03:48:21 Re: Expression Evaluator used for creating the plan tree / stmt ?