Re: idle_in_transaction_timeout
От | Andres Freund |
---|---|
Тема | Re: idle_in_transaction_timeout |
Дата | |
Msg-id | 20140629211947.GD26930@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: idle_in_transaction_timeout (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: idle_in_transaction_timeout
|
Список | pgsql-hackers |
On 2014-06-29 15:48:15 -0400, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner <kgrittn@ymail.com> wrote: > >> I propose to push this as it stands except for the postgres_fdw > >> part. The default is easy enough to change if we reach consensus, > >> and expanding the scope can be a new patch in a new CF. > >> Objections? > > > 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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: