Date: Tue, 4 Jun 2024 15:50:51 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: michael@paquier.xyz, postgres@jeltef.nl, smithpb2250@gmail.com,
	vignesh21@gmail.com, jakub.wartak@enterprisedb.com,
	stark.cfm@gmail.com, hlinnaka@iki.fi, barwick@gmail.com,
	jchampion@timescale.com, pryzby@telsasoft.com, tgl@sss.pgh.pa.us,
	rjuju123@gmail.com, jakub.wartak@tomtom.com,
	pgsql-hackers@lists.postgresql.org,
	bharath.rupireddyforpostgres@gmail.com
Subject: Re: In-placre persistance change of a relation
Message-ID: <Zl9-K3a0-AW4WZrl@nathan>
References: <20240524.160916.2199777355532445323.horikyota.ntt@gmail.com>
 <CAGECzQRQzpE-EzJszHHvku1JLw+opu+KxE7rBqfyTmmgFwxrRQ@mail.gmail.com>
 <Zl5bKIdOWiHHb-9N@paquier.xyz>
 <20240604.160032.391318120410028809.horikyota.ntt@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240604.160032.391318120410028809.horikyota.ntt@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/Zl9-K3a0-AW4WZrl%40nathan>
Precedence: bulk

+Bharath

On Tue, Jun 04, 2024 at 04:00:32PM +0900, Kyotaro Horiguchi wrote:
> At Tue, 4 Jun 2024 09:09:12 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
>> Another point that Nathan has made is that it may be more appealling
>> to study how this is better than an integration with the multi-INSERT
>> APIs into AMs, so as it is possible to group the inserts in batches
>> rather than process them one-at-a-time, see [1].  I am ready to accept
>> that what this patch does is more efficient as long as everything is
>> block-based in some cases.  Still there is a risk-vs-gain argument
>> here, and I am not sure whether what we have here is a good tradeoff
>> compared to the potential risk of breaking things.  The amount of new
>> infrastructure is large for this code path.  Grouping the inserts in
>> large batches may finish by being more efficient than a WAL stream
>> full of FPWs, as well, even if toast values are deformed?  So perhaps
>> there is an argument for making that optional at query level, instead.
> 
> I agree about the uncertainties. With the switching feature mentioned
> above, it might be sufficient to use the multi-insert stuff in the
> existing path. However, the uncertainties regarding performance would
> still remain.

Bharath, does the multi-INSERT stuff apply when changing a table to be
LOGGED?  If so, I think it would be interesting to compare it with the FPI
approach being discussed here.

-- 
nathan