Re: PostgreSQL Tuning Results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ron Mayer" <ron(at)intervideo(dot)com>
Cc: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au>, "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL Tuning Results
Date: 2003-02-14 02:18:18
Message-ID: 3263.1045189098@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

"Ron Mayer" <ron(at)intervideo(dot)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

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Tom Lane 2003-02-14 02:29:17 Re: [HACKERS] More benchmarking of wal_buffers
Previous Message Bruce Momjian 2003-02-13 22:58:18 Re: [HACKERS] Changing the default configuration

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Brown 2003-02-14 02:20:05 Re: location of the configuration files
Previous Message Bruce Momjian 2003-02-14 02:13:29 Re: location of the configuration files