Re: [PATCH] Optionally record Plan IDs to track plan changes for a query - Mailing list pgsql-hackers

From Lukas Fittl
Subject Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
Date
Msg-id CAP53Pkyq8xsouqY=G7+gWovnOde=pRPorRFOe5i6u0YELowoHA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Optionally record Plan IDs to track plan changes for a query  (Artem Gavrilov <artem.gavrilov@percona.com>)
List pgsql-hackers
On Tue, Jan 21, 2025 at 10:47 AM Artem Gavrilov <artem.gavrilov@percona.com> wrote:
We have another extension that does plan ID tracking: pg_stat_monitor. So I think it would be great to have this functionality in core.

Thanks! I had forgotten that pg_stat_monitor can optionally track plan statistics. Its actually another data point for why the plan ID calculation should be in core:

Like pg_store_plans, pg_stat_monitor is hashing the plan text to calculate the plan ID [0], which can have measurable overhead (judging from our benchmarks of pg_store_plans). It also utilizes EXPLAIN (COSTS OFF) for getting the plan text [1], which tracks with my thinking as to what should be considered significant for the plan ID jumbling.

I tested your patch set on top of 86749ea3b76 PG revision on MacOS. All tests successfully passed. However, pgident shows that some files are not properly formatted.

Thanks, appreciate the test and note re: pgident, taking care of that in the next patch refresh.

Thanks,
Lukas


--
Lukas Fittl

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pure parsers and reentrant scanners
Next
From: Jim Jones
Date:
Subject: Re: XMLDocument (SQL/XML X030)