Re: RFC: replace pg_stat_activity.waiting with something more descriptive
От | Amit Kapila |
---|---|
Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Дата | |
Msg-id | CAA4eK1LfQgehdR90uJ5d4zWS8siv3uS6exxVX3Ra_0fXjz21vA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: RFC: replace pg_stat_activity.waiting with something
more descriptive
Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Список | pgsql-hackers |
On Wed, Feb 3, 2016 at 8:59 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Feb 2, 2016 at 10:27 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > So, let's leave adding any additional column, but Alexander has brought up
> > a good point about storing the wait_type and actual wait_event
> > information into four bytes. Currently I have stored wait_type (aka
> > classId)
> > in first byte and then two bytes for wait_event (eventId) and remaining
> > one-byte can be used in future if required, however Alexandar is proposing
> > to
> > combine both these (classId and eventId) into two-bytes which sounds
> > reasonable to me apart from the fact that it might add operation or two
> > extra
> > in this path. Do you or anyone else have any preference over this point?
>
> I wouldn't bother tinkering with it at this point. The value isn't
> going to be recorded on disk anywhere, so it will be easy to change
> the way it's computed in the future if we ever need to do that.
>
>
> On Tue, Feb 2, 2016 at 10:27 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > So, let's leave adding any additional column, but Alexander has brought up
> > a good point about storing the wait_type and actual wait_event
> > information into four bytes. Currently I have stored wait_type (aka
> > classId)
> > in first byte and then two bytes for wait_event (eventId) and remaining
> > one-byte can be used in future if required, however Alexandar is proposing
> > to
> > combine both these (classId and eventId) into two-bytes which sounds
> > reasonable to me apart from the fact that it might add operation or two
> > extra
> > in this path. Do you or anyone else have any preference over this point?
>
> I wouldn't bother tinkering with it at this point. The value isn't
> going to be recorded on disk anywhere, so it will be easy to change
> the way it's computed in the future if we ever need to do that.
>
Okay. Find the rebased patch attached with this mail. I have moved
this patch to upcoming CF.
Вложения
В списке pgsql-hackers по дате отправления: