Re: [COMMITTERS] pgsql: Reduce the size of memoryallocations by lazy vacuum when

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Alvaro Herrera" <alvherre(at)postgresql(dot)org>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Reduce the size of memoryallocations by lazy vacuum when
Date: 2007-09-24 09:39:59
Message-ID: 46F785EF.1070907@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Simon Riggs wrote:
> On Mon, 2007-09-24 at 10:02 +0100, Heikki Linnakangas wrote:
>> How about just using MaxHeapTuplesPerPage? With the default 8K block
>> size, it's not that much more than 200, but makes the above gripes
>> completely go away. That seems like the safest option at this point.
>
> It would be much better to use a value for each table. Any constant
> value will be sub-optimal in many cases.

Allocating extra memory doesn't usually do much harm, as long as you
don't actually use it. The reason we're now limiting it is to avoid Out
Of Memory errors if you're running with overcommit turned off, and
autovacuum triggers a vacuum on multiple tables at the same time.

Let's keep it simple. Per-table setting would be much more complex and
would be something that the DBA would need to calculate and set. If you
really do run into this problem, you can just dial down
maintenance_work_mem.

> Let's use our knowledge of the table to calculate a sensible value. We
> often have average row length available from last VACUUM, don't we? Use
> that, plus 10%.

If there's dead line pointers in the table, left behind by HOT pruning,
the average row length would be completely bogus. Using the dead_tuples
stats directly would be more reasonable, but I would like us to keep
this even more conservative than that.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Simon Riggs 2007-09-24 10:23:01 Re: [COMMITTERS] pgsql: Reduce the size of memoryallocations by lazy vacuum when
Previous Message Simon Riggs 2007-09-24 09:28:22 Re: [COMMITTERS] pgsql: Reduce the size of memory allocations by lazy vacuum when

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-09-24 09:53:35 Re: GUC variable renaming, redux
Previous Message Simon Riggs 2007-09-24 09:28:22 Re: [COMMITTERS] pgsql: Reduce the size of memory allocations by lazy vacuum when