Expand warnings around the implications of transaction pooling #1180
Expand warnings around the implications of transaction pooling #1180cosgroveb wants to merge 2 commits into
Conversation
…e plan cache gotcha
Co-authored-by: Brian Cosgrove <bcosgrove@paypal.com>
cosgroveb
changed the title
| Note: Using `DISCARD ALL` also works around the very non-obvious potential performance land-mine | ||
| that can happen to query plan caching with the server-side `plan_cache_mode` default of `auto`. | ||
| Clients can be stuck with a cached plan that was efficient for a previous client that is | ||
| no longer because the dataset being queried has changed. With transaction pooling it may | ||
| be worth considering setting `plan_cache_mode` to `custom`. When using transaction pooling it | ||
| is at a minimum [strongly adised to review the Postgres docs][postgres-plan-cache-mode-docs]. | ||
|
|
||
| [postgres-plan-cache-mode-docs]: https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-PLAN-CACHE-MODE |
There was a problem hiding this comment.
I think this note should maybe be part of the max_prepared_statements config, since that is enabling prepared statements in the first place. At minimum we should link there from here.
There was a problem hiding this comment.
Ah maybe I didn't outline this gotcha very well because you don't need to use prepared statements to get a backend conn with a suboptimal cached plan
There was a problem hiding this comment.
Rather implicit prepared statements being the surprising culprit
There was a problem hiding this comment.
Ah but yes that warning may be better fit if moved per your suggestion
| unintentional breakage in an application or its' dependencies (for instance ActivRecord | ||
| uses session features out of the box). |
There was a problem hiding this comment.
I think it would be good to clarify exactly what the session level features are unsupported? Because a bunch of session features actually are supported these days, see max_prepared_statements and track_extra_parameters. So I think it would be good to call out what is and what isn't supported. And it might be useful to say what exactly ActiveRecord is doing that is unsupported.
There was a problem hiding this comment.
Do we really need to mention tools here? These tools might eventually change and this information is obsolete. I prefer the other way, open a PR for the referred product saying that it doesn't work with PgBouncer if you are using feature X. Once they fix this issue, their documentation is updated accordingly saying that PgBouncer is supported.
3 participants
The motivation for this PR is to better-educate users who, reasonably, may want to use transaction pooling but may also be running one of the world's most popular web frameworks which would be, cryptically, considered a "broken setup" by the current docs since it manipulates the session extensively out of the box with no levers that I am aware of to prevent that! 😄