+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
