Horton

Thread

Commits

  1. doc: Document that MAINTAIN privilege allows statistics manipulation functions.

  1. Add missing references to database object statistics manipulation functions in documentation

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2025-05-22T11:17:19Z

    Hi,

I noticed that the documentation is missing references to the database
object statistics manipulation functions such as pg_restore_relation_stats
in a few relevant places. For instance, the MAINTAIN privilege section
lists allowed operations but doesn't mention these functions, even though
they're covered. Likewise, the pg_class catalog section describes
what can update fields like reltuples, but omits these functions,
which also affect those fields.

So I'd like to propose adding these missing references to improve clarity.
Patch attached. Thought?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

  2. Re: Add missing references to database object statistics manipulation functions in documentation

    Robert Treat <rob@xzilla.net> — 2025-06-06T18:11:17Z

    On Thu, May 22, 2025 at 7:17 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> I noticed that the documentation is missing references to the database
> object statistics manipulation functions such as pg_restore_relation_stats
> in a few relevant places. For instance, the MAINTAIN privilege section
> lists allowed operations but doesn't mention these functions, even though
> they're covered. Likewise, the pg_class catalog section describes
> what can update fields like reltuples, but omits these functions,
> which also affect those fields.
>
> So I'd like to propose adding these missing references to improve clarity.
> Patch attached. Thought?
>

I'm not enthusiastic about most this patch, mostly because I read the
phrasing "are updated by... <commands>" as "are kept up to date
periodically by..." rather than "can be manipulated in some way...",
especially when you consider that the current wording is most useful
because the updating commands have a secondary effect, but
pg_restore_relation_stats and pg_clear_relation_stats have a primary
purpose of updating stats and are only called in specific
circumstances, making the extra information feel excessively detailed.

That said, I do very much think it is worth adding this part in,
because most people seem to think about MAINTAINS as a way to run
utility commands, but I think they might very well be overlooking that
there are additional functions that folks will also get access to.

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index fcd1cb85352..96936bcd3ae 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -2223,8 +2223,9 @@ REVOKE ALL ON accounts FROM PUBLIC;
      <para>
       Allows <command>VACUUM</command>, <command>ANALYZE</command>,
       <command>CLUSTER</command>, <command>REFRESH MATERIALIZED VIEW</command>,
-      <command>REINDEX</command>, and <command>LOCK TABLE</command> on a
-      relation.
+      <command>REINDEX</command>, <command>LOCK TABLE</command>,
+      and database object statistics manipulation functions
+      (see <xref linkend="functions-admin-statsmod"/>) on a relation.
      </para>
     </listitem>
    </varlistentry>


Robert Treat
https://xzilla.net

  3. Re: Add missing references to database object statistics manipulation functions in documentation

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2025-06-11T03:50:44Z

    
On 2025/06/07 3:11, Robert Treat wrote:
> On Thu, May 22, 2025 at 7:17 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>> I noticed that the documentation is missing references to the database
>> object statistics manipulation functions such as pg_restore_relation_stats
>> in a few relevant places. For instance, the MAINTAIN privilege section
>> lists allowed operations but doesn't mention these functions, even though
>> they're covered. Likewise, the pg_class catalog section describes
>> what can update fields like reltuples, but omits these functions,
>> which also affect those fields.
>>
>> So I'd like to propose adding these missing references to improve clarity.
>> Patch attached. Thought?
>>
> 
> I'm not enthusiastic about most this patch, mostly because I read the
> phrasing "are updated by... <commands>" as "are kept up to date
> periodically by..." rather than "can be manipulated in some way...",
> especially when you consider that the current wording is most useful
> because the updating commands have a secondary effect, but
> pg_restore_relation_stats and pg_clear_relation_stats have a primary
> purpose of updating stats and are only called in specific
> circumstances, making the extra information feel excessively detailed.

I see your point and dropped that part of the patch.


> That said, I do very much think it is worth adding this part in,
> because most people seem to think about MAINTAINS as a way to run
> utility commands, but I think they might very well be overlooking that
> there are additional functions that folks will also get access to.

Yes, so I've updated the patch to only include the change to
the MAINTAIN privilege documentation. Patch attached.
Barring any objections, I plan to commit it.


> Additionally, this function accepts argument name version of type integer, which specifies
> the server version from which the statistics originated. This is anticipated to be helpful in
> porting statistics from older versions of PostgreSQL.

By the way, while reviewing the docs for pg_restore_relation_stats
and pg_restore_attribute_stats, I noticed this description.
While it's accurate, the parameter is currently always ignored.
Should we document that explicitly? Otherwise, users might waste time
trying to figure out what value to set, even though it has no effect.
Alternatively, since this isn’t a parameter most users care about,
maybe we should just remove the description altogether? Thoughts?

Regards,

-- 
Fujii Masao
NTT DATA Japan Corporation

  4. Re: Add missing references to database object statistics manipulation functions in documentation

    Robert Treat <rob@xzilla.net> — 2025-06-11T15:54:51Z

    On Tue, Jun 10, 2025 at 11:50 PM Fujii Masao
<masao.fujii@oss.nttdata.com> wrote:
> On 2025/06/07 3:11, Robert Treat wrote:
> > On Thu, May 22, 2025 at 7:17 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >> I noticed that the documentation is missing references to the database
> >> object statistics manipulation functions such as pg_restore_relation_stats
> >> in a few relevant places. For instance, the MAINTAIN privilege section
> >> lists allowed operations but doesn't mention these functions, even though
> >> they're covered. Likewise, the pg_class catalog section describes
> >> what can update fields like reltuples, but omits these functions,
> >> which also affect those fields.
> >>
<snip>
> > That said, I do very much think it is worth adding this part in,
> > because most people seem to think about MAINTAINS as a way to run
> > utility commands, but I think they might very well be overlooking that
> > there are additional functions that folks will also get access to.
>
> Yes, so I've updated the patch to only include the change to
> the MAINTAIN privilege documentation. Patch attached.
> Barring any objections, I plan to commit it.
>

+1 from me.

>
> > Additionally, this function accepts argument name version of type integer, which specifies
> > the server version from which the statistics originated. This is anticipated to be helpful in
> > porting statistics from older versions of PostgreSQL.
>
> By the way, while reviewing the docs for pg_restore_relation_stats
> and pg_restore_attribute_stats, I noticed this description.
> While it's accurate, the parameter is currently always ignored.
> Should we document that explicitly? Otherwise, users might waste time
> trying to figure out what value to set, even though it has no effect.
> Alternatively, since this isn’t a parameter most users care about,
> maybe we should just remove the description altogether? Thoughts?
>

Ah, nice catch. It could probably be removed until it does something
useful, but if we wanted to keep it, maybe something like:

This function also accepts an argument named "version", of type
"integer", that is meant to be used to identify the server version
from which the statistics were collected. Although this argument is
not yet utilized, it is intended to support migration of statistics
from earlier PostgreSQL versions in the future.


Robert Treat
https://xzilla.net