Re: doc: alter table references bogus table-specific planner parameters

On Mon, 6 Jan 2020 at 02:56, Justin Pryzby <pryzby@telsasoft.com> wrote:

> commit 6f3a13ff058f15d565a30c16c0c2cb14cc994e42 Enhance docs for ALTER
> TABLE lock levels of storage parms
> Author: Simon Riggs <simon@2ndQuadrant.com>
> Date:   Mon Mar 6 16:48:12 2017 +0530
>
>     <varlistentry>
>      <term><literal>SET ( <replaceable
> class="PARAMETER">storage_parameter</replaceable> = <replaceable
> class="PARAMETER">value</replaceable> [, ... ] )</literal></term>
> ...
> -      Changing fillfactor and autovacuum storage parameters acquires a
> <literal>SHARE UPDATE EXCLUSIVE</literal> lock.
> +      <literal>SHARE UPDATE EXCLUSIVE</literal> lock will be taken for
> +      fillfactor and autovacuum storage parameters, as well as the
> +      following planner related parameters:
> +      effective_io_concurrency, parallel_workers, seq_page_cost
> +      random_page_cost, n_distinct and n_distinct_inherited.
>
> effective_io_concurrency, seq_page_cost and random_page_cost cannot be set
> for
> a table - reloptions.c shows that they've always been
> RELOPT_KIND_TABLESPACE.
>

Right, but if they were settable at table-level, the lock levels shown
would be accurate.

I agree with the sentiment of the third doc change, but your patch removes
the mention of n_distinct, which isn't appropriate.

The second change in your patch alters the meaning of the sentence in a way
that is counter to the first change. The name of these parameters is
"Storage Parameters" (in various places); I might agree with describing
them in text as "storage or planner parameters", but if you do that you
can't then just refer to "storage parameters" later, because if you do it
implies that planner parameters operate differently to storage parameters,
which they don't.


> n_distinct lock mode seems to have been changed and documented at e5550d5f
> ;
> 21d4e2e2 claimed to do the same, but the LOCKMODE is never used.
>

But neither does it need to because we don't lock tablespaces.

Thanks for your comments.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise