Re: Statistics Import and Export - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Statistics Import and Export
Date
Msg-id 31307315e23c281bdb7d9a8960dd58507b40a530.camel@j-davis.com
Whole thread Raw
In response to Re: Statistics Import and Export  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: Statistics Import and Export
List pgsql-hackers
On Wed, 2025-03-05 at 23:04 -0500, Corey Huinker wrote:
>
> Anyway, here's a rebased set of the existing up-for-consideration
> patches, plus the optimization of avoiding querying on non-expression
> indexes.

Comments on 0003:

* All the argument names for pg_restore_attribute_stats match pg_stats,
except relname vs tablename. There doesn't appear to be a great answer
here, because "relname" is the natural name to use for
pg_restore_relation_stats(), so either the two restore functions will
be inconsistent, or the argument name of one of them will be
inconsistent with its respective catalog. I assume that's the
reasoning?

* it decides to only issue a WARNING, rather than an ERROR, if the
table can't be found, which seems fine

* Now that it's doing a namespace lookup, we should also check for the
USAGE privilege on the namespace, right?

Based on the other changes we've made to this feature, I think 0003
makes sense, so I'm inclined to move ahead with it, but I'm open to
opinions.

0004 looks straightforward, though perhaps we should move some of the
code into a static function rather than indenting so many lines.

Did you collect performance results for 0004?

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Add contrib/pg_logicalsnapinspect
Next
From: Alexander Pyhalov
Date:
Subject: Re: SQLFunctionCache and generic plans