Re: [HACKERS] vacuum process size

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

Browse pgsql-hackers by date

  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