If I set work-mem at a particular amount of memory how do I answer the
following questions:
1) How many of my queries were able to run inside the memory I
allocated for work-mem?
2) How many of my queries had to run from disk because work-mem
was not set high enough?
3) If a
Josh Berkus writes:
>> -checkpoint_segments - this is crucial as one of the server is
>> transaction heavy
> Well, it only helps you to raise this if you have a dedicated disk resource
> for the xlog. Otherwise having more segments doesn't help you much.
Au contraire, large checkpoint_segment
John,
> -work_mem
Depends on the number of concurrent queries you expect to run and what size
sorts you expect them to do.
> -maintenance_work_mem - 50% of the largest table?
Actually, in current code I've found that anything over 256mb doesn't actually
get used.
> -shared_buffers - max valu
"Campbell, Lance" <[EMAIL PROTECTED]> wrote:
>
> I have been researching how to improve my overall performance of
> postgres. I am a little confused on the reasoning for how work_mem is
> used in the postgresql.conf file. The way I understand the
> documentation is you define with work_mem how mu
work-mem tells the size of physical memory only, virtual memory is
always there off course in case you run out of available memory.
I recommend you reading PostgreSQL internals for all this stuff:
http://www.postgresql.org/docs/8.0/static/internals.html
--Imad
www.EnterpriseDB.com
On 1/29/07, C
I have been researching how to improve my overall performance of
postgres. I am a little confused on the reasoning for how work-mem is
used in the postgresql.conf file. The way I understand the
documentation is you define with work-mem how much memory you want to
allocate per search. Couldn't yo
"Dave Dutcher" <[EMAIL PROTECTED]> writes:
> Thanks for looking into it. I thought I might actually test if it was the
> patch you mentioned which changed my results, but I haven't had time.
> Because you mentioned it was grouping on the results of a UNION ALL which
> was throwing off the row esti
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
>
>
> In fact, since there isn't any "parent relation" in a UNION, I'm not
> sure that this patch actually changed your results ... but I'm not
> seeing what else would've ...
>
Thanks for looking into it. I thought I
