[...] > I've taken a look at your patch. I agree that having a plan identifier > would be great, but I'm not a big fan of the jumbling. That's a lot of > hashing that needs to be done to decide wether two plans are > essentially equivalent or not.
As there is no planid available yet in core, I reused jumbling from pg_stat_plans, and I agree : it seems quite complicated (its not even sure that it is compatible with all the new partitioning stuff) and I won't be able to maintain it. > Maybe, in the future, in a different patch, we could add functionality > that would allow us to compare two plan trees. There is even a remark > in the header of src/backend/nodes/equalfuncs.c regarding this: > * Currently, in fact, equal() doesn't know how to compare Plan trees > * either. This might need to be fixed someday. It would be so helpfull if a planid was included in core Query / plan tree, it could be reused here in equal(), in explain commands, in pg_stat_activity, in pg_stat_statements ... >> May be your view pg_stat_statements_plans could be transformed : >> same key as pgss: dbid,userid,queryid,planid >> and THE plan column to store explain result (no more need for >> plan_time nor >> tz that >> are already available in modified pgss). > The documentation [of pg_stat_statements] gives no clear indication > which fields qualify as primary keys, mainly because the hashing that > generates the queryid isn't guaranteed to produce unique results... > So I'm not sure which columns should be used to create associations > between pg_stat_statements and pg_stat_statements_plans. Yes I understand, to choose between dbid,userid,queryid,planid and dbid,userid,planid (planid alone seems not acceptable regarding privacy policies). Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
