On 7/16/24 18:14, Tomas Vondra wrote:
> I noticed this patch hasn't moved since September 2023, so I wonder
> what's the main blocker / what is needed to move this?
Mainly me finding time I'm afraid.
> As for the feature, I've never done a fleet-wide analysis, so if this is
> one of the main use cases, I'm not really sure I can judge if this is a
> good tool for that. It seems like it might be a convenient way to do
> that, but does that require we add the module to contrib?
I had an offlist chat with Andres about this IIRC and he suggested he
thought it ought to be just built in to the backend as part of the
statistics subsystem. Lately though I have been toying with the idea of
keeping it as an extension and basing it off Michael Paquier's work for
Pluggable cumulative statistics.
> As for the code, I wonder if the instability of line numbers could be a
> problem - these can change (a little bit) between minor releases, so
> after an upgrade we'll read the dump file with line numbers from the old
> release, and then start adding entries with new line numbers. Do we need
> to handle this in some way?
Hmm, yeah, I had been planning to include postgres version as part of
the output, but maybe it would need to be part of the key.
> This might be partially solved by eviction of entries from the old
> release - we apply decay, so after a while their usage will be 0. But
> what if there's no pressure for space, we'll not actually evict them.
> And it'll be confusing to have a mix of old/new line numbers.
Agreed.
I am going to try hard to get back to this sooner rather than later, but
realistically that might be in time for the September commitfest rather
than during this one.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
