idea as fixed bulk update/insert and mogrify

[vir-mir]

Hey all.

We can implement a bulk insert, but we need to decide what to do with mogrify.

Im test psycopg2.extras.execute_batch in asynchronous style and the result impressed me.
we replace "executemany" with "mogrify and execute"

Recently, the argument was use_batch_mode added to sqlalchemy. psycopg/psycopg2#491 (comment)

use_batch_mode: This flag allows psycopg2.extras.execute_batch for cursor.executemany() calls performed by the Engine. It is currently experimental but may well become True by default as it is critical for executemany performance.

psycopg documentation: http://initd.org/psycopg/docs/extras.html#psycopg2.extras.execute_batch
psycopg implementation: https://github.com/psycopg/psycopg2/blob/master/lib/extras.py#L1185
significant speedup: psycopg/psycopg2#491 (comment)

This allows us to make mass requests using use_batch_mode=True in Engine and will resolve of issues: #112, #546.

however, cursor.mogrify is an asynchronous function.
although is doesn't need #186, #352

I propose to change this behavior in version 1.0.0 without backward compatibility.

[aio-libs-bot]

GitMate.io thinks possibly related issues are #112 (aiopg.sa bulk inserts / executemany), #546 (Bulk update values with SQLAlchemy), #87 (Returning after update), and #352 (Should cursor.mogrify be coroutine?).

[vir-mir]

I propose to discuss @jettify @asvetlov @thehesiod @webknjaz

[webknjaz]

I think mogrify is like this just for interface consistency. Following your logic none of the other coroutine methods in that class need async. But using async def means that there will also be a control flow yield to the event loop while with sync methods it wouldn't happen.

[thehesiod]

leave this up to jettify/asvetlov :]

[vir-mir]

I am ready to wait a week more. but after I collect the new release candidate, removing async before this function

[vir-mir]

preparing release

[vir-mir]

started implementing #632