Horton

Re: Pre-alloc ListCell's optimization

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-05-16T16:24:39Z
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()

* Stephen Frost (sfrost@snowman.net) wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > ISTM the first thing we'd need to have before
> > we could think about this rationally is some measurements about the
> > frequencies of different List lengths in a typical workload.
> 
> I agree, that'd be a good thing to have.  I'll look into measuring that.

Ok, it took me, uh, a little while to get around to this, but:

http://tamriel.snowman.net/~sfrost/list_histgram.svg

Is what our list lengths look like for the regression tests.  We could
do a pg_bench run, but it looks like Tom's right here- the vast majority
of our lists are small.  Highlights:

63% are 1-element
25% are 2-element

Lists of 4 or fewer elements are 97%
Lists of 8 or fewer elements are 99%

So, when it comes to palloc() reduction, this patch would eliminate 99%
of palloc's due to lists.  For the regression tests, we're talking about
reducing 893,206 palloc calls to only 1.

	Thanks,

		Stephen