Re: BUG #13979: Strange pg_stat_statements results with PREPARE/EXECUTE

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #13979: Strange pg_stat_statements results with PREPARE/EXECUTE
Дата
Msg-id 929.1456241888@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #13979: Strange pg_stat_statements results with PREPARE/EXECUTE  (Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>)
Ответы Re: BUG #13979: Strange pg_stat_statements results with PREPARE/EXECUTE
Список pgsql-bugs
Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com> writes:
> So I expected following result after performing second time "SELECT *
> FROM tt WHERE c1 = $1" in a  previous e-mail.

> =# SELECT queryid, calls, query FROM pg_stat_statements WHERE query LIKE
> '%tt%';
>   queryid  | calls |                       query
> -----------+-------+----------------------------------------------------
>  575935600 |    1| PREPARE p1(int) AS SELECT * FROM tt WHERE c1 = $1;
>  other-queryid |    10 | SELECT * FROM tt WHERE c1 = $1;
> (2 row)

> But actually SELECT was counted  as PREPARE in pg_stat_statements.
> That's what I thought strange.

What's in the query field is whatever source string the query was created
from.  In the case of a prepared statement, we could potentially show
either the PREPARE or the EXECUTE, but the former was deemed much more
useful.  There's no logic in there to invent a string that was never
actually submitted to the engine.

            regards, tom lane

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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #13979: Strange pg_stat_statements results with PREPARE/EXECUTE
Следующее
От: ranier_gyn@hotmail.com
Дата:
Сообщение: BUG #13982: HANDLE LEAK