Have the performance issues been addressed?

[punkpeye]

I read this article https://pganalyze.com/blog/introducing-postgres-plan-statistics-for-amazon-aurora, and it says:

Functionally, at the surface, pg_store_plans seems comparable to what aurora_stat_plans offers. However, we've found one main reason to not use pg_store_plans in production today: It has considerable overhead in how it calculates the planid.

Have those issues been addressed?

I cannot tell if the maintainers were even made aware of.

[lfittl]

Have those issues been addressed?

I cannot tell if the maintainers were even made aware of.

As someone who contributed to that post I can help clarify:

The problem is that the fundamental mechanism that captures the planid in pg_store_plans is expensive, because it runs through Postgres' EXPLAIN logic first and then hashes a rather large text second.

This may have been deliberate (and other extensions that do planid calculations, like pg_stat_monitor do the same), as the alternative is pretty complicated to implement: You'd have to walk the Postgres plan tree (including any expressions referenced) to calculate a planid, and make that specific to each Postgres version. The reason we had not opted to reach out to the maintainers here explicitly are because its unlikely they'd want to take on the maintenance burden of such an alternate approach (and this extension already has issues with not having enough active maintenance unfortunately).

Because of this fundamental issue I've started an upstream conversation to potentially include a planid calculation in core Postgres: https://www.postgresql.org/message-id/flat/CAP53Pkyow59ajFMHGpmb1BK9WHDypaWtUsS_5DoYUEfsa_Hktg@mail.gmail.com

One of the current discussion topics there is whether to expose additional functions for hashing ("jumbling"), so that extensions like this one can implement a simpler version of the tree walk that only looks at plan nodes (and defers to Postgres' own logic for expressions contained within a plan tree). There is a chance we'll see that in Postgres 18, as discussions are ongoing. Note its unlikely that an upstream change that will do the full planid calculation will land in Postgres 18.