On Thu, 4 Dec 2008, Gregory Stark wrote:
Right now, my program doesn't fiddle with any memory settings if you've got
less than 256MB of RAM.
What I'm suggesting is that you shouldn't have to special case this. That you
should expect whatever formulas you're using to produce the same values as
initdb if they were run on the same machine initdb is targeting.
The reason that approach isn't taken is that the model here assumes the OS
overhead is negligable relative to everything else going on. If you've
only got a small amount of RAM, that assumption is so badly broken that
you can't just extend the curves for everything down to there and expect
that what comes out will make any sense. I started to make a more
complicated bit that did scale down to the bottom by modeling the overhead
better, Josh talked me out of doing it for now.
But actually I'm more concerned with the *non* memory related parameters. It
may make sense to tweak those one way or the other for oltp or dss but "mixed"
should be exactly what initdb produces since that's exactly what it's
targeting -- a system that will have a wide mixture of queries and must
function reasonably well for both data warehouse and oltp queries.
The only way this line of discussion will go is toward talking about what
should be changed in initdb to make it more representative of the current
real world, and I know that's not going anywhere (see
"default_statistics_target=10"). The idea that the sample configuration
is tuned usefully for any application whatsoever gets nothing from me but
a chuckle.
And "desktop" seems like an outlier here. I suppose it's meant to capture
whether postgres is on a dedicated box? But it's possible to have a
non-dedicated oltp application or non-dedicated data warehouse box just as
easily.
That's the target for something that's not a dedicated server--a desktop
PC you use as a general workstation, maybe you're installing PostgreSQL as
a developer that's competing with your web server and other apps;
something like that. There might be a better name for that.
Is 368MB of overhead unreasonable for a web application database today
Well I think it's more than most people expect a single application install to
take up before they start putting data in it.
Segments don't get allocated until you churn through that much WAL
activity; that figure is an upper-bound after you've pushed more than that
worth of data through WAL and into the database. The only example where
this overhead isn't dwarfed by the size of the resulting database is where
some small number of records are inserted, then constantly updated and
vacuumed. And you know what? The person doing that is likely to really
benefit from having checkpoint_segments set to a larger value. Update and
vacuum heavy workloads are exactly the sort where you end up checkpointing
too often with the default parameters.
I'm really beginning to think the root of the problem is the name. If it were
"transaction_log_max_space" and measured in megabytes people would be happy to
say "ok, I'll make space for 100MB of logs" or whatever. Today they don't know
what to set it to or what the impact of setting it will be.
Unless they do something crazy like read the documentation:
http://www.postgresql.org/docs/8.3/static/wal-configuration.html
"There will always be at least one WAL segment file, and will normally not
be more than (2 + checkpoint_completion_target) * checkpoint_segments + 1
files. Each segment file is normally 16 MB (though this size can be
altered when building the server). You can use this to estimate space
requirements for WAL."
Too complicated for most people you say? I agree; that's why I put some
annotated examples for what those translate into
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server like "32
(checkpoint every 512MB)".
What fun. I'm beginning to remember why nobody has ever managed to
deliver a community tool that helps with this configuration task before.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
