Re: stored procedure stats in collector

From: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Volkan YAZICI <yazicivo(at)ttmail(dot)com>, pgsql-patches(at)postgresql(dot)org, postgres(at)cybertec(dot)at
Subject: Re: stored procedure stats in collector
Date: 2008-05-14 12:22:47
Message-ID: 482AD997.7070307@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> What I think we should do about that is forget tracking getrusage()'s
> user/system/real time and just track elapsed time. We have the
> technology to get that in a portable fashion (cf the well-proven
> instrument.c code). Such a decision would also alleviate two of the
> biggest negatives of this patch, which are the runtime overhead and
> the extent to which it's going to bloat the pgstats file.
>

I find the utime/stime quite useful, compared with the actual time it
enables us to distinguish waiters (remote calls, sleeps, etc) from the
actual CPU hogs. The difference is also very visible for IO bound
functions. At least in our case it is a very useful tool for diagnosing
performance issues and the overhead is not really visible.

Perhaps the track_functions should just be set to none, or enabled selectively
(session, function guc, user guc) for the environments where getrusage()
is particularly expensive? Maybe a note in the docs that tracking is
potentially expensive, and should be used carefully in production env.

Regards,
Martin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Luis Vargas 2008-05-14 13:50:58 Re: Execution Plan Cost
Previous Message Andrew Dunstan 2008-05-14 12:18:30 Re: libpq object hooks

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-05-14 14:22:02 Re: [PATCHES] stored procedure stats in collector
Previous Message Andrew Dunstan 2008-05-14 12:18:30 Re: libpq object hooks