Postgresql.conf cleanup - Mailing list pgsql-hackers

From Josh Berkus
Subject Postgresql.conf cleanup
Date
Msg-id 4688DB84.6010201@agliodbs.com
Whole thread Raw
Responses Re: Postgresql.conf cleanup  (Josh Berkus <josh@agliodbs.com>)
Re: Postgresql.conf cleanup  (Jim Nasby <decibel@decibel.org>)
Re: Postgresql.conf cleanup  (Peter Eisentraut <peter_e@gmx.net>)
Re: Postgresql.conf cleanup  (Bruce Momjian <bruce@momjian.us>)
Re: Postgresql.conf cleanup  (Bruce Momjian <bruce@momjian.us>)
List 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





pgsql-hackers by date:

Previous
From: "Jeroen T. Vermeulen"
Date:
Subject: ANALYZE and index/stats degradation
Next
From: Josh Berkus
Date:
Subject: Re: Postgresql.conf cleanup