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

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 15:26:54
Message-ID: 20070924152653.GB6353@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Gregory Stark wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>
> > 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.
>
> For reference, MaxHeapTuplesPerPage on an 8k block is 291. If there are any
> columns in your tuples (meaning they're not either HOT updates which have been
> pruned or rows with 8 or fewer columns all of which are null) then the most
> you can have is 255 rows.

How about we change it to MaxHeapTuplesPerPage for now. That closes all
complaints in this thread.

Later we can think about better ways of doing the whole thing, like
using non-lossy tidbitmaps.

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"Para tener más hay que desear menos"

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message User Dpage 2007-09-24 15:50:53 stackbuilder - wizard: When a file to be downloaded already exists but
Previous Message Andrew Dunstan 2007-09-24 14:59:37 pgsql: Use correct PG_GETARG macro in pg_convert

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-09-24 15:27:05 Re: Reducing NUMERIC size for 8.3
Previous Message Tom Lane 2007-09-24 15:17:11 Re: Bytea as C string in pg_convert?