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. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services