You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
2023-01-18 00:02:40.006 CET [94971] LOG: execute <unnamed>: BEGIN
2023-01-18 00:02:40.007 CET [94971] LOG: execute <unnamed>: INSERT INTO users(name, surname) VALUES ($1, $2)
2023-01-18 00:02:40.007 CET [94971] DETAIL: parameters: $1 = 'NAME', $2 = 'SURNAME'
2023-01-18 00:02:40.010 CET [94971] LOG: execute S_1: COMMIT
I tried to educate myself on unnamed prepared statements, but didn't find any useful information apart from that it's only support on the wire protocol. Can you tell me what gains does it provide? Can a database still remove planning a query part event though at a first glance it's not possible to distinguish one unnamed prepared statement from the other?
The text was updated successfully, but these errors were encountered:
Keen to see some benchmarks though if anyone wants to compare plain doobie vs reusing the same PreparedStatement object. (The linked docs do say that reusing the PreparedStatment object is more efficient, but I'm not sure by how much)
Hello,
going into database logs I was surprised to see that all queries are run as
unnamed
prepared statements.E.g for a postgres database with a table:
and a statement:
I can see in logs:
I tried to educate myself on
unnamed
prepared statements, but didn't find any useful information apart from that it's only support on the wire protocol. Can you tell me what gains does it provide? Can a database still remove planning a query part event though at a first glance it's not possible to distinguish oneunnamed
prepared statement from the other?The text was updated successfully, but these errors were encountered: