From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Marko Kreen <markokr(at)gmail(dot)com>, Jeff Amiel <becauseimjeff(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Out of Memory - 8.2.4 |
Date: | 2007-08-29 01:45:29 |
Message-ID: | 19213.1188351929@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-08-29 01:47:00 | Re: Out of Memory - 8.2.4 |
Previous Message | Alvaro Herrera | 2007-08-29 01:45:09 | Re: autovacuum not running |