Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Nov 28, 2011 at 2:54 AM, Greg Smith <greg@2ndquadrant.com> wrote:
>> The real problem with this whole area is that we know there are
>> systems floating around where the amount of time taken to grab timestamps
>> like this is just terrible.
> Assuming the feature is off by default (and I can't imagine we'd
> consider anything else), I don't see why that should be cause for
> concern. If the instrumentation creates too much system load, then
> don't use it: simple as that. A more interesting question is "how
> much load does this feature create even when it's turned off?".
Right. I see that the code already has a switch to skip the
gettimeofday calls, so the objection is only problematic if the added
overhead is significant even with the switch off. I would worry mainly
about the added time/space to deal with the extra stats counters.
> The other big problem for a patch of this sort is that it would bloat
> the stats file.
Yes. Which begs the question of why we need to measure this per-table.
I would think per-tablespace would be sufficient.
regards, tom lane
