Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Marko Kreen escribió:
>> I've experienced something similar.  The reason turned out to be
>> combination of overcommit=off, big maint_mem and several parallel
>> vacuums for fast-changing tables.  Seems like VACUUM allocates
>> full maint_mem before start, whatever the actual size of the table.

> Hmm.  Maybe we should have VACUUM estimate how much is the maximum
> amount of memory that would be used, given the size of the table, and
> allocate only that much.

Yeah --- given the likelihood of parallel vacuum activity in 8.3,
it'd be good to not expend memory we certainly aren't going to need.

We could set a hard limit at RelationGetNumberOfBlocks *
MaxHeapTuplesPerPage TIDs, but that is *extremely* conservative
(it'd work out to allocating about a quarter of the table's actual size
in bytes, if I did the math right).

Given that the worst-case consequence is extra index vacuum passes,
which don't hurt that much when a table is small, maybe some smaller
estimate like 100 TIDs per page would be enough.  Or, instead of
using a hard-wired constant, look at pg_class.reltuples/relpages
to estimate the average tuple density ...

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to