On 2014-07-20 17:01:50 +0200, Fabien COELHO wrote:
>
> >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.
Ick. You have a point.
> 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.
Well, EXECUTE isn't actually ignored, but tracked via the execution
time. But that doesn't diminish your point with PREPARE. If we do
something we should go for the && !IsA(parsetree, DeallocateStmt), not
the normalization. The latter is pretty darn bogus.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
