Re: In-placre persistance change of a relation

+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