Re: default_table_access_method is not in sample config file

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Asim R P <apraveen(at)pivotal(dot)io>, pgsql-hackers(at)postgresql(dot)org, Ashwin Agrawal <aagrawal(at)pivotal(dot)io>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Subject: Re: default_table_access_method is not in sample config file
Date: 2019-08-17 13:07:22
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Aug 16, 2019 at 03:29:30PM -0700, Andres Freund wrote:
> but I don't quite see GUCs like default_tablespace, search_path (due to
> determining a created table's schema), temp_tablespace,
> default_table_access_method fit reasonably well under that heading. They
> all can affect persistent state. That seems pretty different from a
> number of other settings (client_min_messages,
> default_transaction_isolation, lock_timeout, ...) which only have
> transient effects.


> Should we perhaps split that group? Not that I have a good proposal for
> better names.

We could have a section for transaction-related parameters, and move
the vacuum ones into the section for autovacuum so as they get
grouped, renaming the section "autovacuum and vacuum". An idea of
group for search_path, temp_tablespace, default_tablespace & co would
be "object parameters", or "relation parameters" for all the
parameters which interfere with object definitions?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Migowski 2019-08-17 13:57:47 Patch: New GUC prepared_statement_limit to limit memory used by prepared statements
Previous Message Michael Paquier 2019-08-17 12:57:50 Re: some SCRAM read_any_attr() confusion