Open avm19 opened 1 month ago
The difference is that a bulk ingest runs via COPY, which can't do a fancy upsert, but is instead optimized to just throw data into the database as fast as possible. While a regular insert uses bind parameters, which requires a database roundtrip for every single row. I would say a temporary table is reasonable for your use case.
The difference is that a bulk ingest runs via COPY
Just to clarify, the "COPY" you are referring to, is it the COPY command of Postgres wire protocol or is it something else? And is it called/implemented in adbc_driver_postgres via libpq library?
Yes and yes: we use the COPY statement with binary format, and we use libpq as the underlying client library.
What would you like help with?
executemany()
much slower thanadbc_ingest()
?I want to insert and update records in a table using Python API of adbc_driver_postgres, let's say, I have 10k rows:
I noticed that
executemany()
is much slower thanadbc_ingest()
for ingesting data. Let's say I have 10k rows:as compared to
I don't mind using
adbc_ingest()
to populate my database, but later in its lifecycle I need to upsert records and more. For example, I need to do something like:which is too slow. Apparently
executemany()
is extremely inefficient for this ask. What is the cause of such a poor performance? What is the bottleneck?The same outcome could be achieved much faster by first ingesting data into a temporary table and then making Postgres run a more complex operation from it rather than from input:
This approach gives a reasonable performance, but is this how one supposed to do this? Is there anything that can be easily improved? I do not know much about Postgres's backend operation and what optimisations it does for ingestion, but I suspect that it is not best practice to create temporary tables (which are not even TEMPORARY) when we just want to stream data.