Re: optimization ideas for frequent, large(ish) updates - Mailing list pgsql-performance

From Tom Lane
Subject Re: optimization ideas for frequent, large(ish) updates
Date
Msg-id 17527.1076902128@sss.pgh.pa.us
Whole thread Raw
In response to Re: optimization ideas for frequent, large(ish) updates  ("Marinos J. Yannikos" <mjy@geizhals.at>)
List pgsql-performance
"Marinos J. Yannikos" <mjy@geizhals.at> writes:
> Jeff Trout wrote:
>> Remember that it is going to allocate 800MB per sort.

> I didn't know that it always allocates the full amount of memory
> specificed in the configuration

It doesn't ... but it could use *up to* that much before starting to
spill to disk.  If you are certain your sorts won't use that much,
then you could set the limit lower, hm?

Also keep in mind that sort_mem controls hash table size as well as sort
size.  The hashtable code is not nearly as accurate as the sort code
about honoring the specified limit exactly.  So you really oughta figure
that you could need some multiple of sort_mem per active backend.

            regards, tom lane

pgsql-performance by date:

Previous
From: "Marinos J. Yannikos"
Date:
Subject: Re: optimization ideas for frequent, large(ish) updates
Next
From: David Teran
Date:
Subject: select max(id) from aTable is very slow