Re: postgresql.conf (Proposed settings) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: postgresql.conf (Proposed settings)
Date
Msg-id 3130.1006483773@sss.pgh.pa.us
Whole thread Raw
In response to Re: postgresql.conf (Proposed settings)  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> ...  However, I feel we should have *some*
> data points before we commit to a number that, as you say, most users will
> implicitly be stuck with.

Data points would be a good thing.  I will freely admit that I have made
no measurements to back up my opinion :-(

> As for sort memory, I have no idea why this isn't much larger by default.

The problem with sort memory is that you don't know what the multiplier
is for it.  SortMem is per sort/hash/whatever plan step, which means
that not only might one backend be consuming several times SortMem on
a complex query, but potentially all MaxBackend backends might be doing
the same.  In practice that seems like a pretty unlikely scenario, but
surely you should figure *some* function of SortMem * MaxBackends as
the number you need to compare to available RAM.

The present 512K default is on the small side for current hardware,
no doubt, but that doesn't mean we should crank it up without thought.
We just recently saw a trouble report from someone who had pushed it
to the moon and found out the hard way not to do that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: v7.2b3 packaged, but not announced beyond here yet
Next
From: Tom Lane
Date:
Subject: Re: pg_config.h.win32