Hi, On 2019-01-30 10:33:30 +1300, David Rowley wrote: > On Wed, 30 Jan 2019 at 10:12, Andres Freund <and...@anarazel.de> wrote: > > > > On 2019-01-30 10:05:35 +1300, David Rowley wrote: > > > On Wed, 30 Jan 2019 at 04:22, Andres Freund <and...@anarazel.de> wrote: > > > > I think I might have a patch addressing the problem incidentally. For > > > > pluggable storage I slotified copy.c, which also removes the first > > > > heap_form_tuple. Quite possible that nothing more is needed. I've > > > > removed the batch context altogether in yesterday's rebase, there was > > > > no need anymore. > > > > > > In your patch, where do the batched tuples get stored before the heap > > > insert is done? > > > > There's one slot for each batched tuple (they are reused). Before > > materialization the tuples solely exist in tts_isnull/values into which > > NextCopyFrom() directly parses the values. Tuples never get extracted > > from the slot in copy.c itself anymore, table_multi_insert() accepts > > slots. Not quite sure whether I've answered your question? > > I think so. I imagine that should also speed up COPY WHERE too as > it'll no longer form a tuple before possibly discarding it.
Right. I found some issues in my patch (stupid implementation of copying from one slot to the other), but after fixing that I get: master: Time: 16013.509 ms (00:16.014) Time: 16836.110 ms (00:16.836) Time: 16636.796 ms (00:16.637) pluggable storage: Time: 15974.243 ms (00:15.974) Time: 16183.442 ms (00:16.183) Time: 16055.192 ms (00:16.055) (with a truncate between each run) So that seems a bit better. Albeit at the cost of having a few, on demand creatd, empty slots for each encountered partition. I'm pretty sure we can optimize that further... Greetings, Andres Freund