Re: postmaster growing to consume all memory - Mailing list pgsql-general

From Lincoln Yeoh
Subject Re: postmaster growing to consume all memory
Date
Msg-id 5.2.0.9.1.20040128132508.01ee2b28@mbox.jaring.my
Whole thread Raw
In response to Re: postmaster growing to consume all memory  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: postmaster growing to consume all memory  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
I'll try to look into that. I'm doing the processing on 7.3.4, so I'll have
to find some spare resources for 7.4.1. Maybe it was a fluke or something.
I did an "overwrite" make install into the same directory as the original
7.3.4 (new data directory though), so maybe I shouldn't have done that?

However, is there a way to get postgresql to handle this more gracefully?
E.g. once it starts using more than max mem it switches or
aborts_and_switches to a more disk based method? Doesn't look easy tho ;).

No offense intended but I doubt the estimator will get things right all the
time (esp if my built-in Murphy Field Intensifier happens to be on).

At 11:25 AM 1/27/2004 -0500, Tom Lane wrote:
>Martijn van Oosterhout <kleptog@svana.org> writes:
> > I'm afraid I'll have to defer to someone else (Tom?) as why the
> estimate was
> > out by three orders of magnitude.
>
>I'd like to know that, too.
>
> > I'd suggest playing around with statistics and seeing if you can work out
> > why they were so bad.
>
>Could we see the pg_stats row for the ip_saddr column?  Also, does the
>estimate get better if you increase the stats target for ip_saddr and
>re-analyze?



pgsql-general by date:

Previous
From: Jerome Lyles
Date:
Subject: Re: Permission Problems:-)?
Next
From: Tom Lane
Date:
Subject: Re: postmaster growing to consume all memory