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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13979: Strange pg_stat_statements results with PREPARE/EXECUTE
Date: 2016-02-23 15:38:08
Message-ID: 929.1456241888@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2016-02-23 20:37:51 Re: BUG #13980: UNINITIALIZED READ
Previous Message David G. Johnston 2016-02-23 15:32:29 Re: BUG #13979: Strange pg_stat_statements results with PREPARE/EXECUTE