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  (Robert Haas <robertmhaas@gmail.com>)
Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Peter Eisentraut <peter_e@gmx.net>)
Список 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.
>

Okay. Find the rebased patch attached with this mail.  I have moved
this patch to upcoming CF.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: How are CREATE EXTENSION ... VERSION or ALTER EXTENSION ... UPDATE TO ... intended to work?
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Handling changes to default type transformations in PLs