On Tue, 2024-03-26 at 01:28 +0530, Bharath Rupireddy wrote: > I'm thinking > of dropping the COPY FROM patch using the new multi insert API for > the > following reasons: ...
I agree with all of this. We do want COPY ... FROM support, but there are some details to work out and we don't want to make a big code change at this point in the cycle. > The new APIs are more extensible, memory management is taken care of > by AM, and with TableModifyState as the structure name and more > meaningful API names. The callback for triggers/indexes etc. aren't > taken care of as I'm now only focusing on CTAS, CMV, RMV > optimizations. > > Please see the attached v14 patches. * No need for a 'kind' field in TableModifyState. The state should be aware of the kinds of changes that it has received and that may need to be flushed later -- for now, only inserts, but possibly updates/deletes in the future. * If the AM doesn't support the bulk methods, fall back to retail inserts instead of throwing an error. * It seems like this API will eventually replace table_multi_insert and table_finish_bulk_insert completely. Do those APIs have any advantage remaining over the new one proposed here? * Right now I don't any important use of the flush method. It seems that could be accomplished in the finish method, and flush could just be an internal detail when the memory is exhausted. If we find a use for it later, we can always add it, but right now it seems unnecessary. * We need to be careful about cases where the command can be successful but the writes are not flushed. I don't tihnk that's a problem with the current patch, but we will need to do something here when we expand to INSERT INTO ... SELECT. Andres, is this patch overall closer to what you had in mind in the email here: https://www.postgresql.org/message-id/20230603223824.o7iyochli2dww...@alap3.anarazel.de ? Regards, Jeff Davis