That's because PREPARE isn't executed as it's own statement, but done on
the protocol level (which will need noticeably fewer messages). There's
no builtin logic to ignore actual PREPARE statements.
ISTM that there is indeed a special handling in function
pgss_ProcessUtility for PREPARE and EXECUTE:
/*
* If it's an EXECUTE statement, we don't track it and don't
increment the
* nesting level. This allows the cycles to be charged to the
underlying
* PREPARE instead (by the Executor hooks), which is much more
useful.
*
* We also don't track execution of PREPARE. If we did, we would
get one
* hash table entry for the PREPARE (with hash calculated from the
query
* string), and then a different one with the same query string
(but hash
* calculated from the query tree) would be used to accumulate
costs of
* ensuing EXECUTEs. This would be confusing, and inconsistent
with other
* cases where planning time is not included at all.
*/
if (pgss_track_utility && pgss_enabled() &&
!IsA(parsetree, ExecuteStmt) &&
!IsA(parsetree, PrepareStmt))
... standard handling ...
else
... special "no" handling ...
So I don't think your consistency argument counts as much here.
I think that given the above code, my argument stands reasonably.
If you do not like my normalization hack (I do not like it much either:-),
I have suggested to add "&& !IsA(parsetree, DeallocateStmt)" to the
condition above, which would ignore DEALLOCATE as PREPARE and EXECUTE are
currently and rightfully ignored.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
