Support named prepared statements #69
Description
No pooler currently supports named prepared statements. Lots of SQL clients which use their own pool do e.g. Elixir's Ecto uses named prepared statements by default and ships with it's own pooling logic.
It seems reasonable for a pooler to be able to support them. Named prepared statements can increase throughput significantly because the query plan is cached.
Unnamed prepared statements do not use a cached query plan because it is deallocated with the next unnamed prepared statement.
If successfully created, a named prepared-statement object lasts till the end of the current session, unless explicitly destroyed. An unnamed prepared statement lasts only until the next Parse statement specifying the unnamed statement as destination is issued. ref
Questions
What if two different clients linked to one pg connection make two different prepared statements with the same name?
Because it's an async protocol can we add metadata to messages that Postgres will include coming back? Then we can use that to route the right messages to the right clients.
Can we use pipelining to multiplex?
Ideas
- Another pool mode
- Pin a client connection to a db conn such that each client would always get the same db conn from the pool
There would be some contention here probably because clients would have to wait on a specific conn but it would work. Question is does the contention negate the perf from the prepared statement. With another mode transaction pooling would work as expected but you could use this new mode if it works for your workload and provides perf gains.