On Tue, 2 Apr 2019 at 14:11, Andres Freund <and...@anarazel.de> wrote: > Why do we need that list membership check? If you append the > ResultRelInfo to the list when creating the ResultRelInfo's slots array, > you don't need to touch the list after a partition lookup - you know > it's a member if the ResultRelInfo has a slot array. Then you only need > to iterate the list when you want to drop slots to avoid using too much > memory - and that's also a sequential scan of the hash table in your > approach, right?
Okay, you're right, we could just determine if we've got a new ResultRelInfo by the lack of any bulk insert slots being set in it. However, I've ended up not doing it that way as the patch requires more than just an array of TupleTableSlots to be stored in the ResultRelInfo, it'll pretty much need all of what I have in CopyMultiInsertBuffer, which includes line numbers for error reporting, a BulkInsertState and a counter to track how many of the slots are used. I had thoughts that we could just tag the whole CopyMultiInsertBuffer in ResultRelInfo, but that requires moving it somewhere a bit more generic. Another thought would be that we have something like "void *extra;" in ResultRelInfo that we can just borrow for copy.c. It may be interesting to try this out to see if it saves much in the way of performance. I've got the patch into a working state now and wrote a bunch of comments. I've not really done a thorough read back of the code again. I normally wait until the light is coming from a different angle before doing that, but there does not seem to be much time to wait for that in this case, so here's v2. Performance seems to be about the same as what I reported yesterday. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
david_tableam_copy_v2.patch
Description: Binary data