Subject: Consecutive Inserts Freeze Execution of Psycopg3

From: "Michael P. McDonnell" <[email-masked]>
Date: Sun, 23 Apr 2023 15:45:56 -0500

Python 3.10.6
psycopg library 3.1.8

Running consecutive inserts sourced in files.
All inserts are of the same format:

INSERT INTO _____ (field1, field2, field3)
SELECT field1, field2, field3 FROM ____, Join ___, join ___ etc...

The code I've written is this:

for qi in range(qlen):
            query = queries[qi]
            qparams = params[qi]
            with self.connection.cursor() as conn:
                conn.execute(query, qparams)

When I run the queries in dbeaver - the first query takes 120s (it's 1.9M
rows), the second query takes 2s (7000 rows).
When I run the queries in python - it freezes on the second query.

Any guidance on how to attack this would be awesome as I have re-written my
code a dozen times and am just slinging mud to see what sticks.

---

From: Adrian Klaver <[email-masked]>
Date: Sun, 23 Apr 2023 14:25:25 -0700

>                  conn.execute(query, qparams)

In above you are running the context manager(with) over the cursor not 
the connection. This will not automatically commit the transaction. You 
will need to either explicitly do connection.commit() or use the with 
over the connection per:

https://www.psycopg.org/psycopg3/docs/basic/transactions.html

> 
> When I run the queries in dbeaver - the first query takes 120s (it's 
> 1.9M rows), the second query takes 2s (7000 rows).
> Any guidance on how to attack this would be awesome as I have re-written 
> my code a dozen times and am just slinging mud to see what sticks.

-- 
Adrian Klaver
[email-masked]

---

From: "Michael P. McDonnell" <[email-masked]>
Date: Sun, 23 Apr 2023 16:55:34 -0500

That helped a ton, I don't understand why I've had to rewrite the crap out
of all of this to get it to work (dropping SqlAlchemy, upgrading from
psycopg2 to psycopg, etc...) but it's working now and I can work around it.
Thank you.

---

From: Adrian Klaver <[email-masked]>
Date: Sun, 23 Apr 2023 17:15:32 -0700

On 4/23/23 14:55, Michael P. McDonnell wrote:
> That helped a ton, I don't understand why I've had to rewrite the crap 
> out of all of this to get it to work (dropping SqlAlchemy, upgrading 
> from psycopg2 to psycopg, etc...) but it's working now and I can work 
> around it. Thank you.

Well:

1) SQLAlchemy is an ORM that tries to make all databases look the same.

2) psycopg2 != psycopg. For details see:

https://www.psycopg.org/psycopg3/docs/basic/from_pg2.html

3) It would have been more of a surprise if you did not have to change 
anything.

4) And this

was just plain wrong. You where trying to make a cursor be a connection 
and that is not going to work.

> 
> 
> On Sun, Apr 23, 2023 at 4:25 PM Adrian Klaver <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     <https://www.psycopg.org/psycopg3/docs/basic/transactions.html>
> 
>      >
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Michael P. McDonnell" <[email-masked]>
Date: Sun, 23 Apr 2023 19:26:37 -0500

Thanks Adrian -
I appreciate it; and I've been pouring through documentation to try and get
to this point.
I can't help but feel I'm doing it "wrong" but no website I can find
recently seems to have a "right" way of doing things that's reasonably kept
up.
It would be nice if "wrong" had a way of shooting me in the foot with
verbose errors or warnings.

-Mike

---

From: Adrian Klaver <[email-masked]>
Date: Sun, 23 Apr 2023 17:59:38 -0700

On 4/23/23 17:26, Michael P. McDonnell wrote:
> Thanks Adrian -
> I appreciate it; and I've been pouring through documentation to try and 
> get to this point.
> recently seems to have a "right" way of doing things that's reasonably 
> kept up.

Start here:

https://www.psycopg.org/psycopg3/docs/basic/index.html

and work through the sections in order.

> 
> -Mike
> 
> On Sun, Apr 23, 2023 at 7:15 PM Adrian Klaver <[email-masked] 
>     <https://www.psycopg.org/psycopg3/docs/basic/from_pg2.html>
> 
>      > On Sun, Apr 23, 2023 at 4:25 PM Adrian Klaver
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >      > Python 3.10.6
>      >      > psycopg library 3.1.8
>      >      >
>      >      > Running consecutive inserts sourced in files.
>      >      > All inserts are of the same format:
>      >      >
>      >      > INSERT INTO _____ (field1, field2, field3)
>      >      > SELECT field1, field2, field3 FROM ____, Join ___, join
>     ___ etc...
>      >      >
>      >      > The code I've written is this:
>      >      >
>      >      > for qi in range(qlen):
>      >      >              query = queries[qi]
>      >      >              qparams = params[qi]
>      >      >              with self.connection.cursor() as conn:
>      >      >                  conn.execute(query, qparams)
>      >
>       <https://www.psycopg.org/psycopg3/docs/basic/transactions.html
>     <https://www.psycopg.org/psycopg3/docs/basic/transactions.html>>
>      >
>      >      >
>      >      > When I run the queries in dbeaver - the first query takes
>     120s (it's
>      >      > 1.9M rows), the second query takes 2s (7000 rows).
>      >      > When I run the queries in python - it freezes on the
>     second query.
>      >      >
>      >      > Any guidance on how to attack this would be awesome as I have
>      >     re-written
>      >      > my code a dozen times and am just slinging mud to see what
>     sticks.
>      >
>      >     --
>      >     Adrian Klaver
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >
> 
>     -- 
>     Adrian Klaver

---

From: "Michael P. McDonnell" <[email-masked]>
Date: Sun, 23 Apr 2023 20:06:20 -0500

So I appreciate you're trying to point to the official source of the
documentation; but one place where FastAPI might be a place of inspiration
is the consistent building of a single use case example to show how one
might do something more complex. Given the docs available - I have no idea
how I might take a dict and generate an UPDATE statement using the sql.SQL
API you have.

And I'm genuinely not trying to nitpick here, I'm relatively new to Python
and am more or less winging it and the documentation immediately available
doesn't exactly spell out *all the things*; So again - thank you for your
help in getting me over the original hump; I appreciate it.

On Sun, Apr 23, 2023 at 7:59 PM Adrian Klaver <[email-masked]>
wrote:

> >      >      > Any guidance on how to attack this would be awesome as I
> have
> >      >     re-written
> >     <mailto:[email-masked] <mailto:[email-masked]
> >>
> >      >
> >
> >     --
> >     Adrian Klaver

---

From: Adrian Klaver <[email-masked]>
Date: Sun, 23 Apr 2023 18:20:48 -0700

On 4/23/23 18:06, Michael P. McDonnell wrote:
> documentation; but one place where FastAPI might be a place of 

This is the first mention of using FastAPI.

> inspiration is the consistent building of a single use case example to 
> show how one might do something more complex. Given the docs available - 
> I have no idea how I might take a dict and generate an UPDATE statement 
> using the sql.SQL API you have.

Some pseudo-code showing what you are trying to achieve would be useful.

> 
> And I'm genuinely not trying to nitpick here, I'm relatively new to 
> Python and am more or less winging it and the documentation immediately 
> available doesn't exactly spell out *all the things*; So again - thank 
> you for your help in getting me over the original hump; I appreciate it.

It is tough for documentation to cover all possible user cases. I have 
found  the best way for me is to write a flow chart of what I want to do 
and then search for the commands/code that gets me there.

> 
> On Sun, Apr 23, 2023 at 7:59 PM Adrian Klaver <[email-masked] 
>     <https://www.psycopg.org/psycopg3/docs/basic/index.html>
> 
>      > On Sun, Apr 23, 2023 at 7:15 PM Adrian Klaver
>      >      > That helped a ton, I don't understand why I've had to
>     rewrite the
>      >     crap
>      >      > out of all of this to get it to work (dropping SqlAlchemy,
>     upgrading
>      >      > from psycopg2 to psycopg, etc...) but it's working now and
>     I can
>      >     work
>      >      > around it. Thank you.
>      >
>      >     Well:
>      >
>      >     <https://www.psycopg.org/psycopg3/docs/basic/from_pg2.html
>     <https://www.psycopg.org/psycopg3/docs/basic/from_pg2.html>>
>      >
>      >      > On Sun, Apr 23, 2023 at 4:25 PM Adrian Klaver
>      >      > <mailto:[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     On 4/23/23 13:45, Michael P. McDonnell wrote:
>      >      >      > Python 3.10.6
>      >      >      > psycopg library 3.1.8
>      >      >      >
>      >      >      > Running consecutive inserts sourced in files.
>      >      >      > All inserts are of the same format:
>      >      >      >
>      >      >      > INSERT INTO _____ (field1, field2, field3)
>      >      >      > SELECT field1, field2, field3 FROM ____, Join ___, join
>      >     ___ etc...
>      >      >      >
>      >      >      > The code I've written is this:
>      >      >      >
>      >      >      > for qi in range(qlen):
>      >      >      >              query = queries[qi]
>      >      >      >              qparams = params[qi]
>      >      >      >              with self.connection.cursor() as conn:
>      >      >      >                  conn.execute(query, qparams)
>      >      >
>      >      >     In above you are running the context manager(with)
>     over the
>      >     cursor not
>      >      >     the connection. This will not automatically commit the
>      >     transaction. You
>      >      >     will need to either explicitly do connection.commit()
>     or use
>      >     the with
>      >      >     over the connection per:
>      >      >
>      >      >
>     <https://www.psycopg.org/psycopg3/docs/basic/transactions.html>>>
>      >      >
>      >      >      >
>      >      >      > When I run the queries in dbeaver - the first query
>     takes
>      >     120s (it's
>      >      >      > 1.9M rows), the second query takes 2s (7000 rows).
>      >      >      > When I run the queries in python - it freezes on the
>      >     second query.
>      >      >      >
>      >      >      > Any guidance on how to attack this would be awesome
>     as I have
>      >      >     re-written
>      >      >      > my code a dozen times and am just slinging mud to
>     see what
>      >     sticks.
>      >      >
>      >      >     --
>      >      >     Adrian Klaver
>      >      > [email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >      >
>      >
>      >     --
>      >     Adrian Klaver

---

From: "Michael P. McDonnell" <[email-masked]>
Date: Mon, 24 Apr 2023 16:16:42 -0500

Hey Adrian -
Just wanted to say thank you again for helping me with getting the
session stuff structured appropriately. I actually found my issue and it
turns out that while my code is suboptimal in a lot of ways - it was
actually a separate database issue as a whole that I'm just now tracking
down.
Just thought you'd like to know that it was not a psycopg(3 or 2) issue,
not a sqlalchemy issue, and it has something to do with how the queries
seem to work.

And the technical info (not an ask, just an inform)
The queries are just an ETL from one table to another based on how the data
needs to be accessed. If I trunc all the tables, and load the originating
table - the first ETL works fine (table1 -> table2).
However - when I then call the 2nd ETL from table2 to table3 - the query
"freezes". I'm still looking into what that means and how to find what's
going on.
If I cancel the execution of that query and re-run the 2nd ETL (table2 to
table3) - it runs in the amount of time I expected (2-3 seconds).

So this fundamentally was never about a session, or commits, or anything
else; those were working as expected - the query itself was just hung up in
the server doing its "thing".

Anywho - hopefully someone is googling and this pops up and helps them look
at the problem differently. Have a great day.
-Mike

On Sun, Apr 23, 2023 at 8:20 PM Adrian Klaver <[email-masked]>
wrote:

> >      >      > That helped a ton, I don't understand why I've had to
> >     rewrite the
> >      >     crap
> >      >      > from psycopg2 to psycopg, etc...) but it's working now and
> >     I can
> >      >     work
> >      >      > around it. Thank you.
> >      >
> >      >     Well:
> >      >
> >      >      >      > SELECT field1, field2, field3 FROM ____, Join ___,
> join
> >      >     ___ etc...
> >      >      >      >
> >      >      >     In above you are running the context manager(with)
> >     over the
> >      >     cursor not
> >      >      >     will need to either explicitly do connection.commit()
> >     or use
> >      >     the with
> >      >      >     over the connection per:
> >      >      >
> >      >      >
> >      >      >      > When I run the queries in dbeaver - the first query
> >     takes
> >      >     120s (it's
> >      >      >      > Any guidance on how to attack this would be awesome
> >     as I have
> >      >      >     re-written
> >      >      >      > my code a dozen times and am just slinging mud to
> >     see what
> >      >     sticks.
> >      >      >
> >      >      >     --
> >      >      >     Adrian Klaver

---

From: Adrian Klaver <[email-masked]>
Date: Mon, 24 Apr 2023 14:22:06 -0700

On 4/24/23 14:16, Michael P. McDonnell wrote:
> The queries are just an ETL from one table to another based on how the 
> data needs to be accessed. If I trunc all the tables, and load the 
> originating table - the first ETL works fine (table1 -> table2).

Look at:

https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW

and

https://www.postgresql.org/docs/current/view-pg-locks.html

> If I cancel the execution of that query and re-run the 2nd ETL (table2 
> to table3) - it runs in the amount of time I expected (2-3 seconds).
> 
> else; those were working as expected - the query itself was just hung up 
> in the server doing its "thing".
> 
> Anywho - hopefully someone is googling and this pops up and helps them 
> look at the problem differently. Have a great day.
> -Mike
>