From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | t-ishii(at)sra(dot)co(dot)jp, Mike Mascari <mascarim(at)yahoo(dot)com>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] vacuum process size |
Date: | 1999-08-24 20:21:24 |
Message-ID: | 3691.935526084@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> If there's no objection, I will commit included patches to the stable
>> tree (seems Tom has more aggressive idea, so I'll leave the current
>> tree as it is).
> No, please make the change in current as well. I was thinking about
> tweaking aset.c to be smarter about releasing large chunks, but in any
> case having the doubling behavior at the request point will be a big
> improvement.
I have just committed changes into current (but not REL6_5) to make
aset.c smarter about giving back memory from large requests. Basically,
for chunk sizes >= ALLOC_BIGCHUNK_LIMIT, pfree() does an actual free()
and repalloc() does an actual realloc(). There is no change in behavior
for smaller chunk sizes. This should cap the amount of space that can
be wasted by aset.c while repalloc'ing a chunk larger and larger.
For lack of a better idea I set ALLOC_BIGCHUNK_LIMIT to 64K. I don't
think it'd pay to make it very small, but I don't really know whether
this is a good choice or not.
It would still be a good idea to fix vacuum.c to double its repalloc
requests at each step, but Tatsuo was already working on that part
so I won't joggle his elbow...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-08-24 20:36:04 | Re: memory requirements question |
Previous Message | Hub.Org News Admin | 1999-08-24 19:15:20 |