Re: Statistics Import and Export
От | jian he |
---|---|
Тема | Re: Statistics Import and Export |
Дата | |
Msg-id | CACJufxEuGBhrri47raxC8MKFZ7Jz6pqKgsL6wkEGeDwqODyw+w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Statistics Import and Export (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Statistics Import and Export
|
Список | 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 по дате отправления: