Re: postgresql.conf (Proposed settings)

Just a thought, when using ORACLE there are a lot of system views that
enable a DBA to look at how much resources are being used by ORACLE
system. With this type of info the DBA is able to determine if he need
to adjust the 100+'s of configuration options in the init.ora file. I
have many Postgres system with db's from 10MB to 900GB and shared memory
from 128MB to 512MB. As far as I can tell there is know way for a
Postgres DB to determine how must of the memory is being used. I would
like to see some type of tool (either a program and or system views)
that would tell the DBA how the shared memory is being used. With this
type of info, the DBA can tune the memory better.

What do you think.
Jim

> Peter Eisentraut <peter_e(at)gmx(dot)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
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>