Re: PostgreSQL Tuning Results - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PostgreSQL Tuning Results
Date
Msg-id 3263.1045189098@sss.pgh.pa.us
Whole thread Raw
In response to Re: PostgreSQL Tuning Results  ("Ron Mayer" <ron@intervideo.com>)
List pgsql-hackers
"Ron Mayer" <ron@intervideo.com> writes:
> One thing I've been wondering, is if "sort_mem" could be 
> per connection/backend-process instead of per sorting operation 
> so that sort_mem could be set more aggressivelly without running out
> of memory so easily with large queries.

Not very readily.  To estimate the cost of a given operation that
needs working memory, the planner has to know how much memory that
operation will be permitted to use.  If you try to make that depend
on how many such operations exist in the total plan, then you are
chasing your tail, because the number of such operations depends on
what the total plan looks like, which depends on which operations are
chosen, which depends on the cost estimates.  The cost estimates are
pretty squishy anyway, but they'd become a complete joke if we didn't
know how much RAM each operation would be allowed ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: location of the configuration files
Next
From: Kevin Brown
Date:
Subject: Re: location of the configuration files