Re: Performance problem in aset.c

From: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Performance problem in aset.c
Date: 2000-07-13 10:04:34
Message-ID: Pine.LNX.3.96.1000713105731.7197A-100000@ara.zf.jcu.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Tue, 11 Jul 2000, Tom Lane wrote:

> A straightforward solution would be to scan the entire freelist
> and give back the smallest block that's big enough for the request.
> That could be pretty slow (and induce lots of swap thrashing) so
> I don't like it much.

Yes. It is right solution. A little better chunk selection can be allowed
with more freelist than current 8. If we will 16 free lists a chunk real
size and request size will more similar.

> Another idea is to split the returned chunk and put the wasted part back
> as a smaller free chunk, but I don't think this solves the problem; it
> just means that the wasted space ends up on a small-chunk freelist, not
> that you can actually do anything with it. But maybe someone can figure
> out a variant that works better.

If I good understand it is a little like my idea with one-free-chunk from
block residual space.

It is not bad idea, but we have aligned chunks now. A question is if in
wasted part will always space for new *aligned* chunk. And second question,
not will this method create small and smaller chunks? For example you
after 1000 free/alloc you will have very much small chunks (from the wasted
part).

The chunk from wasted part is good, but you must have usage of this chunks.

*IMHO* current new mem design create new demand on context. In old design
we used one context for more different proccess and request-allocation-size
was more heterogeneous. But now, we use for specific operetions specific
contexts and it probably very often create context that use very homogeneous
chunks. For example if a testing my query cache 90% of all alocation are in
the range 16-32b and one cached plan need 2000-5000b --- effect it that
query cache not need 8Kb blocks ...etc. Very simular situation will in
other parts in PG.
Tom add to AllocSet context defaul/max block size setting for each context.
It is good and it is first step to more specific context setting. Hmm,
I haven't idea for some next step now... But something setting is needful
for chunks operations (for example primary-default chunk size and from this
frequent freelist, big chunk limit setting ..etc.)

Karel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2000-07-13 10:21:16 Re: A postgreSQL question
Previous Message Zeugswetter Andreas SB 2000-07-13 08:47:35 AW: AW: lztext and compression ratios...