Re: foreign table batch inserts

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Manuel Kniep <m(dot)kniep(at)web(dot)de>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp
Subject: Re: foreign table batch inserts
Date: 2016-05-19 05:38:48
Message-ID: CAMsr+YHqA4gTPGrjE9WNyF_SJc+JZQud9VXU3fa0wdiCb91YqQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 19 May 2016 at 01:39, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:

> On Wed, May 18, 2016 at 12:27 PM, Craig Ringer <craig(at)2ndquadrant(dot)com>
> wrote:
> > On 18 May 2016 at 06:08, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
> wrote:
> >> > Wouldn’t it make sense to do the insert batch wise e.g. 100 rows ?
> >>
> >> Using a single query string with multiple values, perhaps, but after
> >> that comes into consideration query string limit particularly for
> >> large text values... The query used for the insertion is a prepared
> >> statement since writable queries are supported in 9.3, which makes the
> >> code quite simple actually.
> >
> > This should be done how PgJDBC does batches. It'd require a libpq
> > enhancement, but it's one we IMO need anyway: allow pipelined query
> > execution from libpq.
>
> That's also something that would be useful for the ODBC driver. Since
> it is using libpq as a hard dependency and does not speak the protocol
> directly, it is doing additional round trips to the server for this
> exact reason when preparing a statement.
>

Good to know. It'll hurt especially badly when statement level rollback is
enabled, since psqlODBC does savepoints then and it'd be able to get rid of
an extra pair of round trips.

It looks like there's plenty of use for this. FDWs, psqlODBC, client
applications doing batches, and postgres XL would benefit from it too.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Piotr Stefaniak 2016-05-19 05:48:04 Re: A couple of cosmetic changes around shared memory code
Previous Message Peter Geoghegan 2016-05-18 23:32:31 Re: Reviewing freeze map code