Re: compute_query_id and pg_stat_statements - Mailing list pgsql-hackers

From Tom Lane
Subject Re: compute_query_id and pg_stat_statements
Date
Msg-id 1579535.1620930549@sss.pgh.pa.us
Whole thread Raw
In response to Re: compute_query_id and pg_stat_statements  (Stephen Frost <sfrost@snowman.net>)
Responses Re: compute_query_id and pg_stat_statements
Re: compute_query_id and pg_stat_statements
Re: compute_query_id and pg_stat_statements
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> There's a ridiculously simple option here which is: drop the idea that
> we support an extension redefining the query id and then just make it
> on/off with the default to be 'on'.

I do not think that defaulting it to 'on' is acceptable unless you can
show that the added overhead is negligible.  IIUC the measurements that
have been done show the opposite.

Maybe we should revert this thing pending somebody doing the work to
make a version of queryid labeling that actually is negligibly cheap.
It certainly seems like that could be done; one more traversal of the
parse tree can't be that expensive in itself.  I suspect that the
performance problem is with the particular hashing mechanism that
was used, which looks mighty ad-hoc anyway.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: amvalidate(): cache lookup failed for operator class 123
Next
From: Mark Dilger
Date:
Subject: Re: Granting control of SUSET gucs to non-superusers