[ forgot to respond to this bit ] Robert Haas <robertmh...@gmail.com> writes: > Another thought is: if we simply treated these as nested queries for > all purposes, would that really be so bad?
That was actually what I suggested first, and now that I look at the code, that's exactly what's happening right now. However, Peter pointed out --- I think rightly --- that this fails to satisfy the principle of least astonishment, because the user doesn't think of these statements as being utility statements with other statements wrapped inside. Users are going to expect these cases to be treated as single statements. The issue existed before this patch, BTW, but was partially masked by the fact that we grouped pg_stat_statements view entries strictly by query text, so that both the utility statement and the contained optimizable statement got matched to the same table entry. The execution costs were getting double-counted, but apparently nobody noticed that. As things now stand, the utility statement and contained statement show up as distinct table entries (if you have nested-statement tracking enabled) because of the different hashing methods used. And it's those multiple table entries that seem confusing, especially since they are counting mostly the same costs. [ time passes ... ] Hm ... I just had a different idea. I need to go look at the code again, but I believe that in the problematic cases, the post-analyze hook does not compute a queryId for the optimizable statement. This means that it will arrive at the executor with queryId zero. What if we simply made the executor hooks do nothing when queryId is zero? (Note that this also means that in the problematic cases, the behavior is already pretty wrong because executor costs for *all* statements of this sort are getting merged into one hashtable entry for hash zero.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers