From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Sabino Mullane <greg(at)turnstep(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: procpid? |
Date: | 2011-06-15 04:19:45 |
Message-ID: | BANLkTin3Fed7dBdQH_qFZskcpC0=fJdP0g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 14, 2011 at 11:04 PM, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
>> For me, the litmus test is whether the change provides enough
>> improvement that it outweighs the disruption when the user runs into
>> it.
>
> For the procpid that started all of this, the clear answer is no. I'm
> surprised people seriously considered making this change. It's a
> historical accident: document and move on.
I agree with you on this one...
>> This is why I suggested a specific, useful, and commonly requested
>> (to me at least) change to pg_stat_activity go along with this.
>
> +1. The procpid change is silly, but fixing the current_query field
> would be very useful. You don't know how many times my fingers
> have typed "WHERE current_query <> '<IDLE>'"
...but I'm not even excited about this. *Maybe* it's worth adding
another column, but the problem with the existing system is *entirely*
cosmetic. The string chosen here is unconfusable with an actual
query, so we are talking here, as with the procpid -> pid proposal,
ONLY about saving a few keystrokes when writing queries. That is a
pretty thin justification for a compatibility break IMV.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2011-06-15 05:03:37 | Avoid index rebuilds for no-rewrite ALTER TABLE ALTER TYPE |
Previous Message | Robert Haas | 2011-06-15 03:43:31 | Re: [WIP] cache estimates, cache access cost |