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 по дате отправления: