Re: Does redundant extension exist During faster COPY in PG16

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Does redundant extension exist During faster COPY in PG16
Дата
Msg-id 20240122200921.fnk2y73lcpsmgejx@awork3.anarazel.de
обсуждение исходный текст
Ответ на Does redundant extension exist During faster COPY in PG16  ("何柯文(渊云)" <hekewen.hkw@alibaba-inc.com>)
Список pgsql-hackers
Hi,

On 2024-01-22 19:54:00 +0800, 何柯文(渊云) wrote:
> 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?

I think so, yes.


> 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).

If there's this much contention on the extension lock, there's no harm in
extending more - the space will be used soon. The alternatives would be a) to
search the FSM with the extension lock held, making contention worse, b) to
release the extension lock again if we couldn't immediately acquire it, search
the fsm, and retry if we couldn't find any free space, which would
substantially increase contention.

The FSM is the source of substantial contention, disabling it actually results
in substantial throughput increases. Vastly increasing the number of lookups
in the FSM would make that considerably worse, without a meaningful gain in
density.

Greetings,

Andres Freund



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

Предыдущее
От: "Tristan Partin"
Дата:
Сообщение: Re: make dist using git archive
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Improve WALRead() to suck data directly from WAL buffers when possible