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
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 |
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 |