From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | William Morgan <william(at)introhq(dot)com> |
Cc: | Steve Crawford <scrawford(at)pinpointresearch(dot)com>, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: setting query timeout as part of the query |
Date: | 2014-09-30 21:39:17 |
Message-ID: | 21688.1412113157@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
William Morgan <william(at)introhq(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | William Morgan | 2014-09-30 21:58:20 | Re: setting query timeout as part of the query |
Previous Message | William Morgan | 2014-09-30 21:36:17 | Re: setting query timeout as part of the query |