summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/dialects/postgresql/psycopg.py
diff options
context:
space:
mode:
authorMike Bayer <mike_mp@zzzcomputing.com>2023-04-02 00:01:47 -0400
committerMike Bayer <mike_mp@zzzcomputing.com>2023-04-02 00:05:17 -0400
commit053b84c56d644551356be72d4615a83dfa96b0f7 (patch)
treea59be28e29d0c766457df37f6d13d182f3015741 /lib/sqlalchemy/dialects/postgresql/psycopg.py
parent15e903d77df78ed2a6e63c05ce7c26f71a4c33c4 (diff)
downloadsqlalchemy-053b84c56d644551356be72d4615a83dfa96b0f7.tar.gz
favor fast_executemany over insertmanyvalues when set
Changed the bulk INSERT strategy used for SQL Server "executemany" with pyodbc when ``fast_executemany`` is set to ``True`` by using ``fast_executemany`` / ``cursor.executemany()`` for bulk INSERT that does not include RETURNING, restoring the same behavior as was used in SQLAlchemy 1.4 when this parameter is set. For INSERT statements that use RETURNING, the "insertmanyvalues" strategy continues to be used as it is the only current strategy that supports RETURNING with bulk INSERT. Previously, SQLAlchemy 2.0 would use "insertmanyvalues" for all INSERT statements when ``use_insertmanyvalues`` was left at its default of ``False``, ignoring if ``fast_executemany`` was set. New performance details from end users have shown that ``fast_executemany`` is still much faster for very large datasets as it uses ODBC commands that can receive all rows in a single round trip, allowing for much larger datasizes than the batches that can be sent by the current "insertmanyvalues" strategy. Fixes: #9586 Change-Id: I85955a10ba77c26cdc0c22e362a827d7aaef2852
Diffstat (limited to 'lib/sqlalchemy/dialects/postgresql/psycopg.py')
0 files changed, 0 insertions, 0 deletions