Re: [PATCH] Speedup truncates of relation forks

From: Alvaro Herrera from 2ndQuadrant <alvherre(at)alvh(dot)no-ip(dot)org>
To: "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>
Cc: 'Fujii Masao' <masao(dot)fujii(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>
Subject: Re: [PATCH] Speedup truncates of relation forks
Date: 2019-09-06 14:51:04
Message-ID: 20190906145104.GA9308@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera from 2ndQuadrant 2019-09-06 14:52:53 Re: [proposal] de-TOAST'ing using a iterator
Previous Message Alexander Korotkov 2019-09-06 14:44:52 Re: Bug in GiST paring heap comparator