Horton

Re: Pre-alloc ListCell's optimization

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Greg Stark <gsstark@mit.edu>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@commandprompt.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-05-27T03:52:35Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Replace the parser's namespace tree (which formerly had the same

  2. Turns out that my recent elimination of the 'redundant' flatten_andors()

* Greg Stark (gsstark@mit.edu) wrote:
> On Thu, May 26, 2011 at 11:57 AM, Stephen Frost <sfrost@snowman.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