Re: Postgresql.conf cleanup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Postgresql.conf cleanup
Date
Msg-id 19571.1183393837@sss.pgh.pa.us
Whole thread Raw
In response to Re: Postgresql.conf cleanup  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Postgresql.conf cleanup
Re: Postgresql.conf cleanup
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
>> I'm working on cleaning up postgresql.conf and pg_settings for the 
>> ...

>> seq_scan_cost: this is independant of all of the other _costs.

So?  All the other costs are independent of it, too.  I don't understand
what problem you have with it.

>> (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. 

That was put in deliberately not long ago, so I doubt (a) will pass.
(b) seems fine to me.

>> transaction_isolation and transaction_read_only appear more than once in 
>> the pg_settings pseudo_table.

Not for me.

> # work_mem = ( RAM * 0.5 ) / max_connections, or less

That seems guaranteed to drive people into swap hell, unless they
execute only trivial queries.

> # wal_buffers = 1MB

Is there really evidence in favor of such a high setting for this,
either?  (I expect the walwriter in the async-commit patch will change
the landscape here, btw.)

> # max_fsm_pages = expected database size * 0.1

This might be too small.

> # checkpoint_segments = 8 to 16 if you have the disk space (0.3 to 0.6 GB)

This seems definitely too small --- for write-intensive databases I like
to set it to 30 or so, which should eat about a GB if I did the
arithmetic right.

> #explain_pretty_print = on

Putting this under "planner options" is wrong and illogical.

The file seems to be missing the effects of some recently committed
patches, eg, bgwriter_all_percent shouldn't be there anymore.
        regards, tom lane


pgsql-hackers by date:

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