Postgresql.conf cleanup

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Postgresql.conf cleanup
Date: 2007-07-02 11:03:32
Message-ID: 4688DB84.6010201@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

All,

I'm working on cleaning up postgresql.conf and pg_settings for the
release. Attached is a sample WIP. It's not in patch form because I'm
not done yet; I've just been editing postgresql.conf and need to fix the
docs and pg_settings to match.

Issues encountered and changes made:

PostgreSQL.conf
----------------

suggestions: added section with the 7 most important obvious settings at
the top and suggestions on how to calculate them. If people like this,
I'll add it to the Tutorial in the docs as well.

seq_scan_cost: this is independant of all of the other _costs. I can't
think of any way in which that doesn't make the whole set of costs
unmanageable. For example, if you want to change seq_scan_cost in order
to make query cost more-or-less match up with ms execution time, you
have to modify all 6 settings. If we do implement per-tablespace
costs, then we'll need per-tablespace random_page_cost as well. Or am I
missing something?

(change requires restart): this phrase appears over 20 times in the
notes. This is enough times to be really repetitive and take up a lot
of scrolling space, while not actually covering all startup-time
parameters. We should either (a) remove all such notes and rely on
docs, or (b) make an annotation symbol (e.g. *R) and mark 100% of them.
Votes?

Vacuum: all vacuum & autovacuum parameters put under their own section.

Client Cost Defaults: this section became a "catch-all" for all userset
parameters which people weren't sure what to do with. I've divided it
into logical subsections, and moved some parameters to other sections
where they logically belong (for example, explain_pretty_print belongs
in Query Tuning).

pg_settings issues
--------------------

transaction_isolation and transaction_read_only appear more than once in
the pg_settings pseudo_table. The setting column is supposed to be unique.

Given the amount of cleanup/improvement which I'm seeing as necessary
for the GUCs, I'm wondering if I put this off too long for 8.3.

--Josh

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2007-07-02 11:05:22 Re: Postgresql.conf cleanup
Previous Message Jeroen T. Vermeulen 2007-07-02 10:59:46 ANALYZE and index/stats degradation