Re: refactoring relation extension and BufferAlloc(), faster COPY

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: refactoring relation extension and BufferAlloc(), faster COPY
Дата
Msg-id 3d8b0834-c8eb-88cd-deac-5321870652b0@iki.fi
обсуждение исходный текст
Ответ на Re: refactoring relation extension and BufferAlloc(), faster COPY  (Andres Freund <andres@anarazel.de>)
Ответы Re: refactoring relation extension and BufferAlloc(), faster COPY  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: refactoring relation extension and BufferAlloc(), faster COPY  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
> v2-0007-bufmgr-Move-relation-extension-handling-into-Bulk.patch

> +static BlockNumber
> +BulkExtendSharedRelationBuffered(Relation rel,
> +                                 SMgrRelation smgr,
> +                                 bool skip_extension_lock,
> +                                 char relpersistence,
> +                                 ForkNumber fork, ReadBufferMode mode,
> +                                 BufferAccessStrategy strategy,
> +                                 uint32 *num_pages,
> +                                 uint32 num_locked_pages,
> +                                 Buffer *buffers)

Ugh, that's a lot of arguments, some are inputs and some are outputs. I 
don't have any concrete suggestions, but could we simplify this somehow? 
Needs a comment at least.

> v2-0008-Convert-a-few-places-to-ExtendRelationBuffered.patch

> diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
> index de1427a1e0e..1810f7ebfef 100644
> --- a/src/backend/access/brin/brin.c
> +++ b/src/backend/access/brin/brin.c
> @@ -829,9 +829,11 @@ brinbuild(Relation heap, Relation index, IndexInfo *indexInfo)
>       * whole relation will be rolled back.
>       */
>  
> -    meta = ReadBuffer(index, P_NEW);
> +    meta = ExtendRelationBuffered(index, NULL, true,
> +                                  index->rd_rel->relpersistence,
> +                                  MAIN_FORKNUM, RBM_ZERO_AND_LOCK,
> +                                  NULL);
>      Assert(BufferGetBlockNumber(meta) == BRIN_METAPAGE_BLKNO);
> -    LockBuffer(meta, BUFFER_LOCK_EXCLUSIVE);
>  
>      brin_metapage_init(BufferGetPage(meta), BrinGetPagesPerRange(index),
>                         BRIN_CURRENT_VERSION);

Since we're changing the API anyway, how about introducing a new 
function for this case where we extend the relation but we what block 
number we're going to get? This pattern of using P_NEW and asserting the 
result has always felt awkward to me.

> -        buf = ReadBuffer(irel, P_NEW);
> +        buf = ExtendRelationBuffered(irel, NULL, false,
> +                                     irel->rd_rel->relpersistence,
> +                                     MAIN_FORKNUM, RBM_ZERO_AND_LOCK,
> +                                     NULL);

These new calls are pretty verbose, compared to ReadBuffer(rel, P_NEW). 
I'd suggest something like:

buf = ExtendBuffer(rel);

Do other ReadBufferModes than RBM_ZERO_AND_LOCK make sense with 
ExtendRelationBuffered?

Is it ever possible to call this without a relcache entry? WAL redo 
functions do that with ReadBuffer, but they only extend a relation 
implicitly, by replay a record for a particular block.

All of the above comments are around the BulkExtendRelationBuffered() 
function's API. That needs a closer look and a more thought-out design 
to make it nice. Aside from that, this approach seems valid.

- Heikki




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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Commitfest Manager
Следующее
От: Nazir Bilal Yavuz
Дата:
Сообщение: Re: meson: Non-feature feature options