Does redundant extension exist During faster COPY in PG16

Поиск
Список
Период
Сортировка
От 何柯文(渊云)
Тема Does redundant extension exist During faster COPY in PG16
Дата
Msg-id 3dbb9c7f-7b81-43f0-98d9-b76f33b4aca1.hekewen.hkw@alibaba-inc.com
обсуждение исходный текст
Ответы Re: Does redundant extension exist During faster COPY in PG16  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi,
I'm learning faster COPY of PG16. I have some questions about extension lock improvement.
From ./src/backend/storage/buffer/bufmgr.c:1901 (ExtendBufferedRelShared)
```
/*
* Lock relation against concurrent extensions, unless requested not to.
*
* We use the same extension lock for all forks. That's unnecessarily
* restrictive, but currently extensions for forks don't happen often
* enough to make it worth locking more granularly.
*
* Note that another backend might have extended the relation by the time
* we get the lock.
*/
if (!(flags & EB_SKIP_EXTENSION_LOCK))
{
LockRelationForExtension(bmr.rel, ExclusiveLock);
if (bmr.rel)
bmr.smgr = RelationGetSmgr(bmr.rel);
}
...
smgrzeroextend(bmr.smgr, fork, first_block, extend_by, false);
```
During concurrent extension, when we obtain the extension lock, we use smgrzeroextend() to extend relation files instead of searching fsm through GetPageWithFreeSpace(). Is this approach reasonable?
During concurrent extensions, one backend bulk extend successfully, meaning that other backends waiting on extension lock have free pages to use.
If all concurrent extend backends extend the relation file after getting the extension lock, the extension lock will be held (extention backends * smgrzeroextend() executing time).

Any feedback is welcome.

--
Best Regards
Kewen He

В списке pgsql-hackers по дате отправления:

Предыдущее
От: shveta malik
Дата:
Сообщение: Re: Synchronizing slots from primary to standby
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Synchronizing slots from primary to standby