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 по дате отправления: