Re: COPY FROM WHEN condition
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Surafel Temesgen <surafel3000@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Adam Berlin <berlin.ab@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-01-29T21:33:30Z
Lists: pgsql-hackers
On Wed, 30 Jan 2019 at 10:12, Andres Freund <andres@anarazel.de> wrote: > > On 2019-01-30 10:05:35 +1300, David Rowley wrote: > > On Wed, 30 Jan 2019 at 04:22, Andres Freund <andres@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
Commits
-
Remove unused struct member, enforce multi_insert callback presence.
- 57a7a3adfe4e 12.0 landed
-
Separate per-batch and per-tuple memory contexts in COPY
- 36a1281f86c0 12.0 landed
-
Fix handling of volatile expressions in COPY FROM ... WHERE
- 4a8283d0ec5a 12.0 landed
-
Allow COPY FROM to filter data using WHERE conditions
- 31f3817402da 12.0 landed
-
Remove obsolete netbsd dynloader code
- b68ff3ea672c 12.0 cited