Re: [PATCH] Speedup truncates of relation forks

On 2019-Sep-05, Jamison, Kirk wrote:

> I also mentioned it from my first post if we can just remove this dead code.
> If not, it would require to modify the function because it would also
> need nforks as input argument when calling DropRelFileNodeBuffers. I kept my
> changes in the latest patch.
> So should I remove the function now or keep my changes?

Please add a preliminary patch that removes the function. Dead code is
good, as long as it is gone. We can get it pushed ahead of the rest of
this.

What does it mean to "mark" a dirty page in FSM? We don't have the
concept of marking pages as far as I know (and I don't see that the
patch does any sort of mark). Do you mean to find where it is and
return its block number? If so, I wonder how this handles concurrent
table extension: are we keeping some sort of lock that prevents it?
(... or would we lose any newly added pages that receive tuples while
this truncation is ongoing?)

I think the new API of smgrtruncate() is fairly confusing. Would it be
better to define a new struct { ForkNum forknum; BlockNumber blkno; }
and pass an array of those?

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services