Re: Out of Memory - 8.2.4 - Mailing list pgsql-general

From Tom Lane
Subject Re: Out of Memory - 8.2.4
Date
Msg-id 19213.1188351929@sss.pgh.pa.us
Whole thread Raw
In response to Re: Out of Memory - 8.2.4  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Out of Memory - 8.2.4  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Out of Memory - 8.2.4  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane escribió:
>> 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).

> Another idea is to consider applying this patch:
> http://thread.gmane.org/gmane.comp.db.postgresql.devel.patches/19384/focus=19393
> which is said to reduce the amount of memory needed to store the TID
> array.

Yeah, but that's orthogonal to the question of how many TID slots we need.

>> 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 ...

> This sounds like a reasonable compromise.

Do you want to make it happen?

            regards, tom lane

pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: autovacuum not running
Next
From: Alvaro Herrera
Date:
Subject: Re: Out of Memory - 8.2.4