pgsql: Improve contrib/pg_stat_statements' handling of PREPARE/EXECUTE

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Improve contrib/pg_stat_statements' handling of PREPARE/EXECUTE
Дата
Msg-id E1SDMB0-0002vV-FY@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Improve contrib/pg_stat_statements' handling of PREPARE/EXECUTE statements.

It's actually more useful for the module to ignore these.  Ignoring
EXECUTE (and not incrementing the nesting level) allows the executor
hooks to charge the time to the underlying prepared query, which
shows up as a stats entry with the original PREPARE as query string
(possibly modified by suppression of constants, which might not be
terribly useful here but it's not worth avoiding).  This is much more
useful than cluttering the stats table with a distinct entry for each
textually distinct EXECUTE.

Experimentation with this idea shows that it's also preferable to ignore
PREPARE.  If we don't, we get two stats table entries, one with the query
string hash and one with the jumble-derived hash, but with the same visible
query string (modulo those constants).  This is confusing and not very
helpful, since the first entry will only receive costs associated with
initial planning of the query, which is not something counted at all
normally by pg_stat_statements.  (And if we do start tracking planning
costs, we'd want them blamed on the other hash table entry anyway.)

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/566a1d43cf6bfcc7f9385b581d98e07eab282cdd

Modified Files
--------------
contrib/pg_stat_statements/pg_stat_statements.c |   19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pgsql: Improve handling of utility statements containing plannable stat
Следующее
От: Tom Lane
Дата:
Сообщение: pgsql: Fix dblink's failure to report correct connection name in error