William Morgan <william@introhq.com> writes:
> If I understand you both correctly, wrapping every statement in a
> transaction will have no appreciable difference in speed or level of
> concurrency, since that wrapping would otherwise already happen under the
> hood. Since the Go pooler respects transactions, that seems like the answer
> to me.
Right.
> And if the execution of the set command itself turns out to be costly
> (though that sounds unlikely) there is a backup plan involving a series of
> user accounts with different timeouts that will at least allow me to
> approximate the limits that I want.
It shouldn't be terribly costly. One thing you might consider, if you're
wrapping the statements in transactions anyway, is to use SET LOCAL whose
effects won't last beyond the transaction. I don't think this will make
any notable difference speed-wise, but it just seems a tad cleaner if the
timeouts don't persist.
regards, tom lane