Re: Transaction commits VS Transaction commits (with parallel) VSquery mean time

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: Transaction commits VS Transaction commits (with parallel) VSquery mean time
Дата
Msg-id CAJrrPGdc7mresMAKGT6Ud2fbL_pYwyizED8YidLwhy2cOc8+NQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Transaction commits VS Transaction commits (with parallel) VSquery mean time  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Transaction commits VS Transaction commits (with parallel) VSquery mean time
Список pgsql-hackers

On Sat, Mar 23, 2019 at 11:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Sat, Mar 23, 2019 at 9:50 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> On 2019-Mar-23, Amit Kapila wrote:
>
> > I think some users might also be interested in the write transactions
> > happened in the system, basically, those have consumed xid.
>
> Well, do they really want to *count* these transactions, or is it enough
> to keep an eye on the "age" of some XID column?  Other than for XID
> freezing purposes, I don't see such internal transactions as very
> interesting.
>

That's what I also had in mind.  I think doing anything more than just
fixing the count for the parallel cooperating transaction by parallel
workers doesn't seem intuitive to me. I mean if we want we can commit
the fix such that all supporting transactions by parallel worker
shouldn't be counted, but I am not able to convince myself that that
is the good fix.  Instead, I think rather than fixing that one case we
should think more broadly about all the supportive transactions
happening in the various operations.  Also, as that is a kind of
behavior change, we should discuss that as a separate topic.

Thanks to everyone for their opinions and suggestions to improve.

Without parallel workers, there aren't many internal implementation
logic code that causes the stats to bloat. Parallel worker stats are not
just the transactions, it update other stats also, for eg; seqscan stats
of a relation. I also eagree that just fixing it for transactions may not
be a proper solution.

Using of XID data may not give proper TPS of the instance as it doesn't
involve the read only transactions information.

How about adding additional two columns that provides all the internal
and background worker transactions into that column?

Regards,
Haribabu Kommi
Fujitsu Australia

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

Предыдущее
От: Lucas Viecelli
Дата:
Сообщение: Re: warning to publication created and wal_level is not set to logical
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Protect syscache from bloating with negative cache entries