RE: [PATCH] Speedup truncates of relation forks

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема RE: [PATCH] Speedup truncates of relation forks
Дата
Msg-id 0A3221C70F24FB45833433255569204D1FC4D560@G01JPEXMBYT05
обсуждение исходный текст
Ответ на Re: [PATCH] Speedup truncates of relation forks  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
From: Masahiko Sawada [mailto:sawada.mshk@gmail.com]
> We do RelationTruncate() also when we truncate heaps that are created
> in the current transactions or has a new relfilenodes in the current
> transaction. So I think there is a room for optimization Thomas
> suggested, although I'm not sure it's a popular use case.

Right, and I don't think of a use case that motivates the opmitizaion, too.


> I've not look at this patch deeply but in DropRelFileNodeBuffer I
> think we can get the min value of all firstDelBlock and use it as the
> lower bound of block number that we're interested in. That way we can
> skip checking the array during scanning the buffer pool.

That sounds reasonable, although I haven't examined the code, either.


> Don't we use each elements of nblocks for each fork? That is, each
> fork uses an element at its fork number in the nblocks array and sets
> InvalidBlockNumber for invalid slots, instead of passing the valid
> number of elements. That way the following code that exist at many places,

I think the current patch tries to reduce the loop count in DropRelFileNodeBuffers() by passing the number of target
forks.


Regards
Takayuki Tsunakawa


 

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

Предыдущее
От: "kuroda.hayato@fujitsu.com"
Дата:
Сообщение: RE: Is PREPARE of ecpglib thread safe?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Race conditions with checkpointer and shutdown