Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Mph --- the proposal was very poorly titled then. In any case, it still
>>> sounds like a one-off hack that would be equally well served by a local
>>> patch.
>
>> It's certainly not intended as a one-off hack, but as a way of analysing
>> the behaviour of existing and new applications. It would certainly be
>> useful for us in the future, and most likely others as well once a
>> plugin or two has been released.
>
> I'd be more interested if I saw a believable spec for a plugin using
> this. So far it sounds terribly badly designed --- for starters,
> apparently it's intending to ignore the stats aggregation/reporting
> infrastructure and reinvent that wheel in some unspecified way, for
> unspecified reasons. If you think you can improve on that mechanism
> (which I'm prepared to believe, though I'd like to see some details)
> why wouldn't the proposed hook include a way to turn off the overhead
> of the regular stats collector? If that's not the point, then what
> is the point?
For any kind of design we'll need to wait for Simon, but the initial
application we were discussing was to allow an unknown/closed source
user app to be traced to reveal it's usage patterns for each relation
in the database. By monitoring at that point we can look at data for
that specific backend (on which we are appropriately exercising the
app), and iirc Simon also said we could see the activity on a
per-transaction basis.
As a disclaimer, I reserve the right to have misremembered some of that
- someone (<cough>Magnus</cough>) kept distracting me on IM during the
conversation :-)
Regards, Dave.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
