Re: Statement timeout behavior in extended queries

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: Statement timeout behavior in extended queries
Дата
Msg-id 20170404.122658.472182550318329721.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: Statement timeout behavior in extended queries  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Список pgsql-hackers
> Where is the statement_timeout timer stopped when processing Parse and Bind messages?

Actually the statement timer is replaced with new statement timer
value in enable_statement_timeout().

> Do you mean the following sequence of operations are performed in this patch?
> 
> Parse(statement1)
>   start timer
>   stop timer
> Bind(statement1, portal1)
>   start timer
>   stop timer
> Execute(portal1)
>   start timer
>   stop timer
> Sync

Yes.

> It looks like the patch does the following.  I think this is desirable, because starting and stopping the timer for
eachmessage may be costly as Tom said.
 
> Parse(statement1)
>   start timer
> Bind(statement1, portal1)
> Execute(portal1)
>   stop timer
> Sync

This doesn't work in general use cases. Following pattern appears
frequently in applications.

Parse(statement1)
Bind(statement1, portal1)
Execute(portal1)
Bind(statement1, portal1)
Execute(portal1)
:
:
Sync

Also what would happen if client just send a parse message and does
nothing after that?

So I think following is better:

Parse(statement1)
Bind(statement1, portal1)
Execute(portal1) start timer stop timer
Bind(statement1, portal1)
Execute(portal1) start timer stop timer
:
:
Sync

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Documentation improvements for partitioning
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: pg_partman 3.0.0 - real-world usage of nativepartitioning and a case for native default