| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
| Cc: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, mike bayer <mike_mp(at)zzzcomputing(dot)com>, "psycopg(at)postgresql(dot)org" <psycopg(at)postgresql(dot)org> |
| Subject: | Re: speed concerns with executemany() |
| Date: | 2016-12-24 02:57:21 |
| Message-ID: | 81565B0C-A1A1-4EC9-A733-3D252C9E98C2@thebuild.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | psycopg |
> On Dec 23, 2016, at 18:55, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
> Alright that I get. Still the practical outcome is each INSERT is being done in a transaction (an implicit one) so the transaction overhead comes into play. Or am I missing something?
Nope, not missing a thing. The theory (and it is only that) is that when they do the .executemany(), each of those INSERTs pays the transaction overhead, while if they do one big INSERT, just that one statement does.
--
-- Christophe Pettus
xof(at)thebuild(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2016-12-24 04:20:57 | Re: speed concerns with executemany() |
| Previous Message | Adrian Klaver | 2016-12-24 02:55:40 | Re: speed concerns with executemany() |