From: | Federico Di Gregorio <fog(at)dndg(dot)it> |
---|---|
To: | psycopg(at)postgresql(dot)org |
Subject: | Re: speed concerns with executemany() |
Date: | 2017-01-05 17:32:18 |
Message-ID: | ee810e38-5d98-52b8-dbab-d918438b7f85@dndg.it |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On 02/01/17 17:07, Daniele Varrazzo wrote:
> On Mon, Jan 2, 2017 at 4:35 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>> With NRECS=10000 and page size=100:
>>
>> aklaver(at)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(dot)digregorio(at)dndg(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2017-01-05 18:59:54 | Re: Solving the SQL composition problem |
Previous Message | Paul Bryan | 2017-01-05 16:51:04 | Re: psycopg2.pool connection recovery/healing |