Re: Performance problem in aset.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Performance problem in aset.c
Date
Msg-id 21834.963379260@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance problem in aset.c  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Performance problem in aset.c
Re: Performance problem in aset.c
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> Can you maintain one free list for each power of 2 (which it might already
> be doing by the look of it), and always allocate the max size for the list.
> Then when you want a 10k chunk, you get a 16k chunk, but you know from the
> request size which list to go to, and anything on the list will satisfy the
> requirement.

That is how it works for small chunks (< 1K with the current
parameters).  I don't think we want to do it that way for really
huge chunks though.

Maybe the right answer is to eliminate the gap between small chunks
(which basically work as Philip sketches above) and huge chunks (for
which we fall back on malloc).  The problem is with the stuff in
between, for which we have a kind of half-baked approach...
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: Vacuum only with 20% old tuples
Next
From: Alfred Perlstein
Date:
Subject: Re: Connection pooling.