Simon>It seems strange to me that we put this work onto the pooler, forcing
Simon>poolers to repeatedly issue the same command
What if poolers learn to manage connections and prepared statements better?
Then poolers won't have to reset the session every time, and everyone wins.
Simon>This has an additional side benefit: if we know we will clean up at
Simon>the end of the transaction, then all temp tables become effectively ON
Simon>COMMIT DROP
The ability to use the temporary tables sounds cool, however, server-prepared statements
allow improve performance significantly (both at frontend and backend), so I would not treat
"server_reset_query=discard all" as a best practice.
That is why transaction_cleanup=on (discard everything at transaction finish) seems to be a workaround
rather than a best practice for the future.
Just to clarify: the patch seems to be small, so it looks harmless, however, I would not be that
enthusiastic with tying new features with transaction_cleanup=on.
---
What do you mean by "session cleanup"?
Does that always have to be the same as "discard all"?
What if the user wants "deallocate all" behavior?
Should transaction_cleanup be an enum rather than on/off?
Vladimir
