Re: Statement timeout behavior in extended queries

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема Re: Statement timeout behavior in extended queries
Дата
Msg-id 0A3221C70F24FB45833433255569204D1F6C076F@G01JPEXMBYT05
обсуждение исходный текст
Ответ на Re: Statement timeout behavior in extended queries  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Список pgsql-hackers
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tatsuo Ishii
> Hmm. IMO, that could happen even with the current statement timeout
> implementation as well.
> 
> Or we could start/stop the timeout in exec_execute_message() only. This
> could avoid the problem above. Also this is more consistent with
> log_duration/log_min_duration_statement behavior than now.

I think it's better to include Parse and Bind as now.  Parse or Bind could take long time when the table has many
partitions,the query is complex and/or very long, some DDL statement is running against a target table, or the system
loadis high.
 

Firing statement timeout during or after many Parses is not a problem, because the first Parse started running some
statementand it's not finished.  Plus, Andres confirmed that major client drivers don't use such a pattern.  There may
bean odd behavior purely from the perspective of E.Q.P, that's a compromise, which Andres meant by "not perfect but."
 

Regards
Takayuki Tsunakawa




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Statement timeout behavior in extended queries
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: Patch: Write Amplification Reduction Method (WARM)