Applied; catalog version bumped.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Kevin Grittner" writes:
> > > Tom Lane wrote:
> > >> The current column ordering can be rationalized to some extent as
> > >>
> > >> 1. ide
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> The current column ordering can be rationalized to some extent as
> >>
> >> 1. identity info (user id, db id, application name)
> >> 2. current query info
> >> 3. session info (backend start time, client addr/port)
>
> > OK.
Tom Lane wrote:
> Well, the current ordering is definitely historical rather than
> designed, but I'm hesitant to do more than minor tweaking. Even if we
> think/hope it won't break applications, people are probably used to
> seeing a particular ordering.
>
> I'm not necessarily dead set against
On Wed, Mar 17, 2010 at 05:47:49PM -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> The current column ordering can be rationalized to some extent as
> >>
> >> 1. identity info (user id, db id, application name)
> >> 2. current query info
> >> 3. session info (backend s
"Kevin Grittner" writes:
> Tom Lane wrote:
>> The current column ordering can be rationalized to some extent as
>>
>> 1. identity info (user id, db id, application name)
>> 2. current query info
>> 3. session info (backend start time, client addr/port)
> OK. I guess that trumps my idea, altho
Tom Lane wrote:
> The current column ordering can be rationalized to some extent as
>
> 1. identity info (user id, db id, application name)
> 2. current query info
> 3. session info (backend start time, client addr/port)
OK. I guess that trumps my idea, although it would su
Bruce Momjian wrote:
> Kevin Grittner wrote:
>> It would scan better, to my mind, if we moved backend_start ahead
>> of xact_start.
>
> Yes, that is another idea that would work, though Tom's idea that
> the query start should be near the query makes sense.
Well, in an ideal world, I would pu
"Kevin Grittner" writes:
> It would scan better, to my mind, if we moved backend_start ahead of
> xact_start.
The current column ordering can be rationalized to some extent as
1. identity info (user id, db id, application name)
2. current query info
3. session info (backe
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > xact_start | timestamp with time zone |
> > query_start | timestamp with time zone |
> > backend_start| timestamp with time zone |
>
> > Should we move query_start?
>
> It would scan better, to my mind, if we moved backend_
Bruce Momjian wrote:
> xact_start | timestamp with time zone |
> query_start | timestamp with time zone |
> backend_start| timestamp with time zone |
> Should we move query_start?
It would scan better, to my mind, if we moved backend_start ahead of
xact_start.
And paint i
Bruce Momjian writes:
> That's a possibility, but we obviously have been adding columns
> out-of-order for several releases now and no one has complained.
On balance I'm for rationalizing this. The query_start time is
logically associated with current_query and waiting, so it ought
to be next to
Magnus Hagander wrote:
> On Wed, Mar 17, 2010 at 21:42, Bruce Momjian wrote:
> > Has anyone ever noticed that the order of pg_stat_activity timestamp
> > columns is illogical:
> >
> > ?xact_start ? ? ? | timestamp with time zone |
> > ?query_start ? ? ?| timestamp with time zone |
> > ?backend_sta
On Wed, Mar 17, 2010 at 21:42, Bruce Momjian wrote:
> Has anyone ever noticed that the order of pg_stat_activity timestamp
> columns is illogical:
>
> xact_start | timestamp with time zone |
> query_start | timestamp with time zone |
> backend_start | timestamp with time zone |
W
Has anyone ever noticed that the order of pg_stat_activity timestamp
columns is illogical:
xact_start | timestamp with time zone |
query_start | timestamp with time zone |
backend_start| timestamp with time zone |
query_start is always between the other two timestamps. Moving
q
14 matches
Mail list logo
