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

From Marko Kreen
Subject Re: Out of Memory - 8.2.4
Date
Msg-id e51f66da0708300101s448ee88bw6ca884615b8a3e8e@mail.gmail.com
Whole thread Raw
In response to Re: Out of Memory - 8.2.4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Out of Memory - 8.2.4  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Out of Memory - 8.2.4  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
On 8/29/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > I'm not having much luck really.  I think the problem is that ANALYZE
> > stores reltuples as the number of live tuples, so if you delete a big
> > portion of a big table, then ANALYZE and then VACUUM, there's a huge
> > misestimation and extra index cleanup passes happen, which is a bad
> > thing.
>
> Yeah ... so just go with a constant estimate of say 200 deletable tuples
> per page?

Note that it's much better to err on the smaller values.

Extra index pass is really no problem.  VACUUM getting
"Out of memory" may not sound like a big problem, but the scary
thing is - the last VACUUM's memory request may succeed and that
means following queries start failing and that is big problem.

--
marko

pgsql-general by date:

Previous
From: "Nitin Verma"
Date:
Subject: Re: What kind of locks does vacuum process hold on the db?
Next
From: Ow Mun Heng
Date:
Subject: accessing PG using Perl:DBI