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

From jian he
Subject Re: Statistics Import and Export
Date
Msg-id CACJufxEuGBhrri47raxC8MKFZ7Jz6pqKgsL6wkEGeDwqODyw+w@mail.gmail.com
Whole thread Raw
In response to Re: Statistics Import and Export  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Statistics Import and Export
List pgsql-hackers
On Tue, Jan 21, 2025 at 2:43 PM Corey Huinker <corey.huinker@gmail.com> wrote:
>
>
>
> On Mon, Jan 20, 2025 at 10:59 PM Corey Huinker <corey.huinker@gmail.com> wrote:
>>>
>>> Are you saying that there is a path for a partitioned index to have
>>> stats today? If so, we can just follow that locking protocol. If not,
>>> I'm concerned about trying to define the locking protocol for doing so
>>> as a side-effect of this work.
>>
>>
>> A quick test on v17 indicates that, no, there is no path for a partitioned index to have stats of its own, so I'm
finewith removing RELKIND_PARTITIONED_INDEX from the allowable relkinds. The partitions of the partitioned index have
statsbut the umbrella index does not. 
>>
>>>
>>> Wouldn't it be easy enough to issue a WARNING and skip it?
>>
>>
>> Sure.
>>
>
>
> So this is the next iteration - it rejects setting stats on partitioned indexes entirely, and it does all the ACL
checksagainst the underlying relation instead of the indexrel. The only oddity is that if a user calls a statistics
settingfunction on some_index of some_table, and they do not have permission to modify stats on some_table, the error
messagethey get reflects the lack of permission on some_table, not the some_index that was invoked. That may be
initiallysurprising, but it actually is more helpful because the permissions that need to change are on the table not
theindex. 


    /*
     * For indexes, we follow what do_analyze_rel() does so as to avoid any
     * deadlocks with analyze/vacuum, which is to take out a
     * ShareUpdateExclusive on table/matview first and only after that take
     * a a AccessShareLock on the index itself.
     */
there are two "a a".


 #include "access/relation.h"
+#include "c.h"
+#include "catalog/pg_class_d.h"
 #include "catalog/pg_database.h"
+#include "catalog/index.h"
+#include "storage/lockdefs.h"
+#include "storage/lmgr.h"
 #include "utils/acl.h"
+#include "utils/lsyscache.h"
 #include "utils/rel.h"
+#include "utils/syscache.h"

+#include "c.h", no need. since we have "postgres.h"
+#include "storage/lockdefs.h" no need. because #include
"storage/lmgr.h" already have it.
+#include "utils/syscache.h" no need. because get_rel_relkind is in
``#include "utils/lsyscache.h"``


in pg_class.h we have
#include "catalog/pg_class_d.h" /* IWYU pragma: export */
if i read
https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUPragmas.md#iwyu-pragma-export
correctly.
here
+#include "catalog/pg_class_d.h"
should be
+#include "catalog/pg_class.h"



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Year of first commit
Next
From: Ivan Kush
Date:
Subject: Re: pg_stat_statements: improve loading and saving routines for the dump file