Re: Postgresql.conf cleanup

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Postgresql.conf cleanup
Дата
Msg-id 200709131630.l8DGULo28155@momjian.us
обсуждение исходный текст
Ответ на Postgresql.conf cleanup  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Postgresql.conf cleanup  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Postgresql.conf cleanup  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Postgresql.conf cleanup  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Josh, is any of this happening for 8.3?

---------------------------------------------------------------------------

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

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: autovacuum launcher eating too much CPU
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Postgresql.conf cleanup