> 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.