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