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
>
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 |