+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 <mich...@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