Re: Statistics Import and Export
От | Jeff Davis |
---|---|
Тема | Re: Statistics Import and Export |
Дата | |
Msg-id | 0b4c098ae3968aa23d6accb691f47bdba143aedd.camel@j-davis.com обсуждение исходный текст |
Ответ на | Statistics Import and Export (Corey Huinker <corey.huinker@gmail.com>) |
Список | pgsql-hackers |
On Wed, 2025-02-05 at 23:01 -0500, Corey Huinker wrote: > And here's an update to the pg_dump code itself. This currently has > failing TAP tests for statistics in the custom and dir formats, but > is working otherwise. This thread got slightly mixed up, so I'm replying to the v45-0001 posted here, and also in response to Michael's and Corey's comments from: https://www.postgresql.org/message-id/Z5H0iRaJc1wnDVLE%40paquier.xyz On Thu, 2025-01-23 at 16:49 +0900, Michael Paquier wrote: > On Tue, Jan 21, 2025 at 10:21:51PM -0500, Corey Huinker wrote: > > After some research, I think that we should treat partitioned > > indexes like > > we were before, and just handle the existing special case for > > regular > > indexes. > > Hmm, why? Sounds strange to me to not have the same locking > semantics > for the partitioned parts, and this even if partitioned indexes don't > have stats that can be manipulated in relation_stats.c as far as I > can see. These stats APIs are designed to be permissive as Jeff > says. > Having a better locking from the start makes the whole picture more > consistent, while opening the door for actually setting real stat > numbers for partitioned indexes (if some make sense, at some point)? v45-0001 addresses this by locking both the partitioned index, as well as its table, in ShareUpdateExclusive mode. That satisfies the in-place update requirement to take a ShareUpdateExclusiveLock on the partitioned index, while otherwise being the same as normal indexes (and therefore unlikely to cause a problem if ANALYZE sets stats on partitioned indexes in the future). That means: * For indexes: ShareUpdateExclusiveLock on table and AccessShareLock on index * For partitioned indexes: ShareUpdateExclusiveLock on table and ShareUpdateExclusiveLock on index * Otherwise, ShareupdateExclusiveLock on the relation which makes sense to me. The v45-0001 patch itself could use some cleanup, but I can take care of that at commit time if we agree on the locking scheme. Regards, Jeff Davis
В списке pgsql-hackers по дате отправления: