Re: Postgresql.conf cleanup

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Postgresql.conf cleanup
Date: 2007-09-13 17:26:27
Message-ID: 46E972C3.8020205@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruce Momjian wrote:
> Josh, is any of this happening for 8.3?

Should I run with this or let it lay?

>
> ---------------------------------------------------------------------------
>
> Josh Berkus wrote:
>> 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
>>
>>
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 5: don't forget to increase your free space map settings
>

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6XLDATb/zqfZUUQRAt4eAJ93xvOvRRIWnqOgZzj1LmnZF1TvGwCfbMd9
Sm/parspTeRDOqZ7KQ3mHXM=
=Uv7U
-----END PGP SIGNATURE-----

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2007-09-13 17:54:29 Re: Postgresql.conf cleanup
Previous Message Alvaro Herrera 2007-09-13 17:03:52 Re: autovacuum launcher eating too much CPU