[...]
> 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