Re: Explain analyze getrusage tracking

On Tue, Nov 16, 2010 at 11:38 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I think we should have a project policy of always printing memory and
>> disk usage in kB, MB, GB etc unless they're functions returning an
>> integer intended for machine use.
>
> rhaas=# set work_mem to '1048577kB';

Interesting. Though in this case I'll mention the raw data is in 512
byte increments so that would imply having to print .5 sometimes.

> We could decide that for text-format EXPLAIN output, an inexact
> conversion is OK, but it's still not OK to do it for the new fields
> you're adding and not for the existing fields (see the sort and hash
> instrumentation).  Personally, I'm not really convinced that making
> such a change has a lot of value, and I think it should be submitted
> as a separate patch and discussed separately, rather than being rolled
> in here.  But if we are going to change it then we at least need to be
> consistent.

Well I proposed that as a separate patch back pre-9.0 and it was
problematic. Having a policy of doing x doesn't mean we have to switch
everything to x or do nothing. We can have a policy that it's better
to do x and then go around fixing things as we find them.

But fine, I'll separate that into a separate patch.

> I suspect that the ru_maxrss, ru_ixrss, ru_idrss, and ru_isrss values
> are useless to us for EXPLAIN purposes because it sounds like they
> don't increment over time.  The others presumably do, so it makes
> sense to show 'em if the system is collecting them.

I'm not sure, the "integral" part might mean it is ok to sum. I've
never seen it explained anywhere exactly what these represent. But the
other question is whether they have anything to do with the plan
nodes. If Postgres is taking lots of memory or receiving signals or
receiving sysv messages (we don't even use sysv messages so that would
be very strange) it doesn't necessarily have anything to do with the
executor algorithm. They're probably just not very interesting stats
to present to the user.

> Yeah, VERBOSE is kind of a catch-all for things that we don't have
> individual flags for.  But I think it's better for each piece of data
> to depend on one setting, rather than a combination of two or more
> settings.  Otherwise you end up being forced to use VERBOSE and then
> you get this deluge of output.  I'd actually sort of like to remove
> some things from VERBOSE and give them their own settings, rather than
> adding more.  The fact that VERBOSE turns on "Output:" is particularly
> annoying.

I tend to think it's "don't be clever about showing me just the useful
stuff, include whatever you've got even if you think it's not useful".
I would consider it a bug if there's anything that requires VERBOSE
and a user finds is relevant to a fixing a user problem (as opposed to
debugging a postgres bug).

I'm concerned about the converse problem. The "I why do I have to
include two dozen flags to get postgres to actually include
everything?". Along with the "try turning on this flag and resending
the plan. Hm, oops forgot a flag resend it again with this too. Oh
that's still not including something we need try it a third time with
this flag" etc.

--
greg