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
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... |