Gregory Stark <stark@enterprisedb.com> writes:
> Sure, but I think Tom's question is how do you get from the plugin to wherever
> you want this data to be? There's not much you can do with the data at that
> point. You would end up having to reconstruct the entire stats collector
> infrastructure to ship the data you want out via some communication channel
> and then aggregate it somewhere else.
Right, and I don't see any reasonable way for a plug-in to establish
such an infrastructure --- how's it going to cause the postmaster to
shepherd a second stats collector process, for instance?
The proposal seems to be in the very early handwaving stage, because
issues like this obviously haven't been thought about. I would suggest
building a working prototype plugin, and then you'll really know what
hooks you need. (Comparison point: we'd never have invented the correct
hooks for the index advisor if we'd tried to define them in advance of
having rough working code to look at.)
> Perhaps your plugin entry point is most useful *alongside* my stats-domain
> idea. If you wanted to you could write a plugin which set the stats domain
> based on whatever criteria you want whether that's time-of-day, userid, load
> on the system, etc.
+1. I'm also thinking that hooks inside the stats collector process
itself might be needed, though I have no idea exactly what.
regards, tom lane
