RE: minimizing pg_stat_statements performance overhead

Hi Pascal,
Thanks for your feedback! I like your ideas.

>the part that hurts in terms or performances is:
>
> if (jstate.clocations_count > 0)
> pgss_store(pstate->p_sourcetext,

I agree that this is the typically the most expensive part, but query normalization and hashing can also start becoming expensive with larger queries.

>that writes the query text to disk, when it has at less one parameter ...
>Computing the QueryId should stay very small and can be very usefull when used in conjonction with
>https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.postgresql-archive.org%2FFeature-improvement-can-we-add-queryId-for-pg-catalog-pg-stat-activity-view-td6077275.html%23a6077602&data=02%7C01%7Cramarti%40microsoft.com%7Cfaa866abf1d5478e9a2208d6b2887cc4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636892696615564063&sdata=pWbyVleHceAHoNTMzb5oHGzois5yDaMpEHKmappTIwk%3D&reserved=0
>for wait events sampling.

I also agree that the query id can be very useful! In cases where query id is required, pg_stat_statements can be enabled.
My intent of turning tracking off is to minimize the performance impact of pgss as much as possible and the thread above states: "PGSS jumble query logic is not bullet proof and may take time then impact the perf".

I believe your fix is a great step forward, but checking enabled at the very beginning would lead to better performance. This also follows the paradigm set by the rest of the pg_stat_statements codebase.
In the future, if we want only the query ID to be calculated maybe we can add another option for that?

--
Raymond Martin
ramarti(at)microsoft(dot)com
Azure Database for PostgreSQL