Thread: Columns of pg_stat_activity
Since we are wacking around pg_stat_activity for 9.2, what do people think about these column names? backend_start | timestamp with time zone | xact_start | timestamp with time zone | query_start | timestampwith time zone | Arguably: backend_start -> session_startquery_start -> statment_start Should we make any of these changes? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 11 April 2012 21:46, Bruce Momjian <bruce@momjian.us> wrote: > Since we are wacking around pg_stat_activity for 9.2, what do people > think about these column names? > > backend_start | timestamp with time zone | > xact_start | timestamp with time zone | > query_start | timestamp with time zone | > > Arguably: > > backend_start -> session_start > query_start -> statment_start > > Should we make any of these changes? Sounds like a lot of potential breakage to solve something I don't think is a problem. Besides, isn't the door for 9.2 changes now closed and bolted? -- Thom
On Wed, Apr 11, 2012 at 09:50:43PM +0100, Thom Brown wrote: > On 11 April 2012 21:46, Bruce Momjian <bruce@momjian.us> wrote: > > Since we are wacking around pg_stat_activity for 9.2, what do people > > think about these column names? > > > > backend_start | timestamp with time zone | > > xact_start | timestamp with time zone | > > query_start | timestamp with time zone | > > > > Arguably: > > > > backend_start -> session_start > > query_start -> statment_start > > > > Should we make any of these changes? > > Sounds like a lot of potential breakage to solve something I don't > think is a problem. Besides, isn't the door for 9.2 changes now > closed and bolted? Well, we renamed procpid -> pid and I noticed these others. Not sure if it is a win or not, but just asking. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Wed, Apr 11, 2012 at 23:04, Bruce Momjian <bruce@momjian.us> wrote: > On Wed, Apr 11, 2012 at 09:50:43PM +0100, Thom Brown wrote: >> On 11 April 2012 21:46, Bruce Momjian <bruce@momjian.us> wrote: >> > Since we are wacking around pg_stat_activity for 9.2, what do people >> > think about these column names? >> > >> > backend_start | timestamp with time zone | >> > xact_start | timestamp with time zone | >> > query_start | timestamp with time zone | >> > >> > Arguably: >> > >> > backend_start -> session_start >> > query_start -> statment_start >> > >> > Should we make any of these changes? >> >> Sounds like a lot of potential breakage to solve something I don't >> think is a problem. Besides, isn't the door for 9.2 changes now >> closed and bolted? > > Well, we renamed procpid -> pid and I noticed these others. Not sure if > it is a win or not, but just asking. We also renamed current_query -> query, but that was mainly because it actually changed meaning. But. Since we already whacked around procpid->pid, yes, if we're ever going to change those, now is the time, really. I think at least backend_start -> session_start would make sense. Not sure about the other one - what's wrong with query_start? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Bruce Momjian <bruce@momjian.us> writes:
> On Wed, Apr 11, 2012 at 09:50:43PM +0100, Thom Brown wrote:
>> On 11 April 2012 21:46, Bruce Momjian <bruce@momjian.us> wrote:
>>> Arguably:
>>> backend_start -> session_start
>>> query_start -> statment_start
>> Sounds like a lot of potential breakage to solve something I don't
>> think is a problem. Besides, isn't the door for 9.2 changes now
>> closed and bolted?
We do still have open issues that include such proposed changes,
so I'd say that "too late" isn't a good argument. However ...
> Well, we renamed procpid -> pid and I noticed these others. Not sure if
> it is a win or not, but just asking.
We were talking about renaming columns if we changed their semantics.
I don't think renaming for the sake of a slightly cleaner name will
win us any friends.
regards, tom lane
On Wed, Apr 11, 2012 at 11:11:18PM +0200, Magnus Hagander wrote: > >> > Should we make any of these changes? > >> > >> Sounds like a lot of potential breakage to solve something I don't > >> think is a problem. Besides, isn't the door for 9.2 changes now > >> closed and bolted? > > > > Well, we renamed procpid -> pid and I noticed these others. Not sure if > > it is a win or not, but just asking. > > We also renamed current_query -> query, but that was mainly because it > actually changed meaning. > > But. Since we already whacked around procpid->pid, yes, if we're ever > going to change those, now is the time, really. > > I think at least backend_start -> session_start would make sense. > > Not sure about the other one - what's wrong with query_start? We consistently use "statement" for commands, not "queries", because some feel query means SELECT. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Wed, Apr 11, 2012 at 05:14:51PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > On Wed, Apr 11, 2012 at 09:50:43PM +0100, Thom Brown wrote: > >> On 11 April 2012 21:46, Bruce Momjian <bruce@momjian.us> wrote: > >>> Arguably: > >>> backend_start -> session_start > >>> query_start -> statment_start > > >> Sounds like a lot of potential breakage to solve something I don't > >> think is a problem. Besides, isn't the door for 9.2 changes now > >> closed and bolted? > > We do still have open issues that include such proposed changes, > so I'd say that "too late" isn't a good argument. However ... > > > Well, we renamed procpid -> pid and I noticed these others. Not sure if > > it is a win or not, but just asking. > > We were talking about renaming columns if we changed their semantics. > I don't think renaming for the sake of a slightly cleaner name will > win us any friends. The "procpid" change was for accuracy, I guess. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +