[PostgreSQL-Hackers] Re: New project launched : PostgreSQL GUI Installer for

Err, yes. pgAdmin? It's somewhat more than a simple text editor.

:-)

/D

Dave Page schrieb:
...
Ah, right ;) Didnt see it in action before :-) Now when I actually
load a postgresql.conf file I see what you mean. Nice job :-)

Figuring out the correct values for some of the buffers and costs
is still a bit tough. Otoh, I guess there is no easy way to predict
all these.

Regards
Tino

pgAdmin has a mechanism to suggest values (currently for autovacuum and
listen_address only), which waits for expansion :-) I could think of a
wizard that asks decent questions, resulting in proposals.

Whether implemented as GUI or not, a questionaire and suggested
algorithms to calculate settings (eyeballed from Core) would be a good
starting point.

Regards,
Andreas

PostgreSQL *desperately* needs a better means of dealing with
configuration (though I guess I shouldn't be pushing too hard for this
since the current state of affairs brings me business). Any improvement
in this area would be very welcome.
http://pgfoundry.org/projects/configurator/ is something worth looking
at.

An ideal facility would be a program that analyzes the workload at
runtime and adjusts accordingly. That doesn't sound too hard, within
some unambitious boundary. If anyone would like to work on this, I'd be
happy to contribute.

-jwb

Jeffery,
It seems pretty hard to *me*, compared with static configuration. If you
have ideas for runtime analysis of configuration criteria, I'd be thrilled
to hear them. From my perspective, most of them depend on backend
monitoring that we don't have yet (like querying how full the FSM is).

I agree that some instrumentation of the backend might be needed. But
several of the performance-critical parameters seem tractable:

Effective cache size - should be easy to monitor the system for this
Shared buffers - easy to start from a rule-of-thumb and monitor usage
Work mem - trace the size and frequency of temp files
Wal buffers - trace the average or 80th percentile number of pages
generated by transactions
Commit delay - track the concurrency level and avg distance btw commits
Checkpoint segments - should be very easy to auto-adjust
Random page cost - should possible to determine this at runtime
Vacuum* - may be possible to determine vacuum impact on concurrent
queries

Jeffrey,
Great. Wanna join the configurator project? I won't have much time to
work on it before March, but anyone with ideas is welcome.

Before worrying about random_page_cost at all it makes a lot more sense
to look at the query cost estimates, some of which are pretty far out of
wack.

I agree, but this problem is orthogonal, no?

No. The problem is that random_page_cost has the wrong effect in some of
the cost functions, so even if you set it more accurately you're not
buying anything. In fact, you might well be hurting performance.