RE: [PATCH] Speedup truncates of relation forks - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: [PATCH] Speedup truncates of relation forks
Date
Msg-id 0A3221C70F24FB45833433255569204D1FC4D560@G01JPEXMBYT05
Whole thread Raw
In response to Re: [PATCH] Speedup truncates of relation forks  (Masahiko Sawada <sawada.mshk@gmail.com>)
List 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 by date:

Previous
From: "kuroda.hayato@fujitsu.com"
Date:
Subject: RE: Is PREPARE of ecpglib thread safe?
Next
From: Michael Paquier
Date:
Subject: Re: Race conditions with checkpointer and shutdown