Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-06-29 15:48:15 -0400, Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> Yeah, I think someone should do some analysis of whether this is
>>> adding gettimeofday() calls, and how many, and what the performance
>>> implications are.
>> I believe that as the patch stands, we'd incur one new gettimeofday()
>> per query-inside-a-transaction, inside the enable_timeout_after() call.
>> (I think the disable_timeout() call would not result in a gettimeofday
>> call, since there would be no remaining live timeout events.)
>>
>> We could possibly refactor enough to share the clock reading with the call
>> done in pgstat_report_activity. Not sure how ugly that would be or
>> whether it's worth the trouble. Note that in the not-a-transaction-block
>> case, we already have got two gettimeofday calls in this sequence, one in
>> pgstat_report_stat and one in pgstat_report_activity :-(
> I've seen several high throughput production servers where code around
> gettimeofday is in the top three profile entries - so I'd be hesitant to
> add more there. Especially as the majority of people here seems to think
> we should enable this by default.
Note that we'd presumably also be adding two kernel calls associated
with setting/killing the SIGALRM timer. I'm not sure how much those
cost, but it likely wouldn't be negligible compared to the gettimeofday
cost.
OTOH, one should not forget that there's also going to be a client
round trip involved here, so it's possible this is all down in the
noise compared to that. But we ought to try to quantify it rather
than just hope for the best.
A thought that comes to mind in connection with that is whether we
shouldn't be doing the ReadyForQuery call (which I believe includes
fflush'ing the previous query response out to the client) before
rather than after all this statistics housekeeping. Then at least
we'd have a shot at spending these cycles in parallel with the
network I/O and client think-time, rather than serializing it all.
regards, tom lane
