Re: RFC: replace pg_stat_activity.waiting with something more descriptive

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date: 2015-07-14 14:25:10
Message-ID: 5285.1436883910@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I really think we should do the simple thing first. If we make this
> complicated and add lots of bells and whistles, it is going to be much
> harder to get anything committed, because there will be more things
> for somebody to object to. If we start with something simple, we can
> always improve it later, if we are confident that the design for
> improving it is good. The hardest thing about a proposal like this is
> going to be getting down the overhead to a level that is acceptable,
> and every expansion of the basic design that has been proposed -
> gathering more than one byte of information, or gathering times, or
> having the backend update a tracking hash - adds *significant*
> overhead to the design I proposed.

FWIW, I entirely share Robert's opinion that adding gettimeofday()
overhead in routinely-taken paths is likely not to be acceptable.
But there's no need to base this solely on opinions. I suggest somebody
try instrumenting just one hotspot in the various ways that are being
proposed, and then we can actually measure what it costs, instead
of guessing about that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-07-14 14:32:07 Re: TABLESAMPLE patch is really in pretty sad shape
Previous Message Tomas Vondra 2015-07-14 14:21:36 Re: multivariate statistics / patch v7