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
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 |