Re: speed concerns with executemany()

From: mike bayer <mike_mp(at)zzzcomputing(dot)com>
To: Christophe Pettus <xof(at)thebuild(dot)com>, Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
Cc: Dorian Hoxha <dorian(dot)hoxha(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "psycopg(at)postgresql(dot)org" <psycopg(at)postgresql(dot)org>
Subject: Re: speed concerns with executemany()
Date: 2017-01-01 19:12:06
Message-ID: fd1f1a56-b424-c0ce-6608-69abf6ef0728@zzzcomputing.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: psycopg

On 12/30/2016 06:42 PM, Christophe Pettus wrote:
>
>> On Dec 30, 2016, at 14:24, Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> wrote:
>>
>> The implementation of executemany as described by me a few days ago is
>> available in this gist, not heavily tested:
>>
>> https://gist.github.com/dvarrazzo/4204cca5d1cd7c9c95bc814d81e6b83e
>>
>> I would like to know if anyone sees any shortcoming in this new implementation.
>
> Seems fine to me! I wish there was a way of feeding the queries down the pipe asynchronously, rather than having to build a gigantic string, but that's probably more trouble than the feature is worth.

you'd need to be careful with that as a series of multiple parameter
sets may have dependencies on each other, not to mention people might
find it surprising that sequences / defaults / SERIAL etc. aren't firing
off in the order in which parameter sets were given.

>
> --
> -- Christophe Pettus
> xof(at)thebuild(dot)com
>

In response to

Responses

Browse psycopg by date

  From Date Subject
Next Message mike bayer 2017-01-01 19:14:17 Re: speed concerns with executemany()
Previous Message Karsten Hilbert 2017-01-01 19:03:57 Re: Solving the SQL composition problem