Hello,
I like pg_store_plan, especially because it is based on hashing sql query and sql plan texts,
that makes its queryid and planid stable after a table drop / recreate, a database restore, or between my different environments (test/prod) !
Why are you using pg_stat_statements to store sql query,
(its queryid is different and doesn't always map to yours) ?
Wouldn't it be simpler to store your normalized query text inside the extension
(and be able to retreive it without joint to pgss) ?
This would save the double calculation of counters and queryid in pgss + pgsp ...
but maybe normalizing queries and plans is consuming too much resources (I didn't mesure it)
and should be limited to bigger ones ?
nb: a normalized query based with constants ? seems enough for me (no need of $1,$2,...)
Hello, I like pg_store_plan, especially because it is based on hashing sql query and sql plan texts, that makes its queryid and planid stable after a table drop / recreate, a database restore, or between my different environments (test/prod) !
Why are you using pg_stat_statements to store sql query, (its queryid is different and doesn't always map to yours) ? Wouldn't it be simpler to store your normalized query text inside the extension (and be able to retreive it without joint to pgss) ?
This would save the double calculation of counters and queryid in pgss + pgsp ... but maybe normalizing queries and plans is consuming too much resources (I didn't mesure it) and should be limited to bigger ones ?
nb: a normalized query based with constants ? seems enough for me (no need of $1,$2,...)
Thanks in advance Regards PAscal