Re: [HACKERS] vacuum process size - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] vacuum process size
Date
Msg-id 3691.935526084@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] vacuum process size  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] vacuum process size
List 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


pgsql-hackers by date:

Previous
From: "Hub.Org News Admin"
Date:
Subject: ...
Next
From: Tom Lane
Date:
Subject: Re: memory requirements question