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 rama...@microsoft.com Azure Database for PostgreSQL
