Re: [psycopg] speed concerns with executemany() - Mailing list psycopg

From Federico Di Gregorio
Subject Re: [psycopg] speed concerns with executemany()
Date
Msg-id ee810e38-5d98-52b8-dbab-d918438b7f85@dndg.it
Whole thread Raw
In response to Re: [psycopg] speed concerns with executemany()  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Responses Re: [psycopg] speed concerns with executemany()  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
List psycopg
On 02/01/17 17:07, Daniele Varrazzo wrote:
> On Mon, Jan 2, 2017 at 4:35 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>> With NRECS=10000 and page size=100:
>>
>> aklaver@tito:~> python psycopg_executemany.py -p 100
>> classic: 427.618795156 sec
>> joined: 7.55754685402 sec
> Ugh! :D

That's great. Just a minor point: I won't overload executemany() with
this feature but add a new method UNLESS the semantics are exactly the
same especially regarding session isolation. Also, right now psycopg
keeps track of the number of affected rows over executemany() calls: I'd
like to not lose that because it is a breaking change to the API.

federico

--
Federico Di Gregorio                         federico.digregorio@dndg.it
DNDG srl                                                  http://dndg.it
   We should forget about small efficiencies, say about 97% of the
    time: premature optimization is the root of all evil.    -- D.E.Knuth


psycopg by date:

Previous
From: Paul Bryan
Date:
Subject: Re: [psycopg] psycopg2.pool connection recovery/healing
Next
From: Adrian Klaver
Date:
Subject: Re: [psycopg] Solving the SQL composition problem