Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
От | Fabien COELHO |
---|---|
Тема | Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*" |
Дата | |
Msg-id | alpine.DEB.2.10.1407202002280.16752@sto обсуждение исходный текст |
Ответ на | Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*" (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
>>> 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. > > Agreed. I think basically the reasoning here is "since we don't track > PREPARE or EXECUTE, we shouldn't track DEALLOCATE either". Yes. It is not just because it is nicely symmetric, it is also annoying to have hundreds of useless DEALLOCATE stats in the table. > However, this is certainly a behavioral change. Perhaps squeeze it > into 9.4, That would be nice, and the one-liner looks safe enough. > but not the back braches? Yep. I doubt that pg_stat_statements users rely on statistics about DEALLOCATE, so back patching the would be quite safe as well, but I would not advocate it. -- Fabien.
В списке pgsql-hackers по дате отправления: