Re: Resetting spilled txn statistics in pg_stat_replication

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Resetting spilled txn statistics in pg_stat_replication
Дата
Msg-id CAA4eK1KhBsskgL2M1xqokABvYZu0BRThMdoC3YO6Qoxn85einQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Resetting spilled txn statistics in pg_stat_replication  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Resetting spilled txn statistics in pg_stat_replication  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Jul 7, 2020 at 2:20 PM Magnus Hagander <magnus@hagander.net> wrote:
>
> On Tue, Jul 7, 2020 at 5:10 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> > > I think it depends on the final patch. My initial thought was that we
>> > > should do this for PG14 but if you are suggesting removing the changes
>> > > done by commit 9290ad198b1 then we need to think over it.  I could
>> > > think of below options:
>> > > a. Revert 9290ad198b1 and introduce stats for spilling in PG14.  We
>> > > were anyway having spilling without any work in PG13 but didn’t have
>> > > stats.
>> > > b. Try to get your patch in PG13 if we can, otherwise, revert the
>> > > feature 9290ad198b1.
>> > > c. Get whatever we have in commit 9290ad198b1 for PG13 and
>> > > additionally have what we are discussing here for PG14.  This means
>> > > that spilled stats at slot level will be available in PG14 via
>> > > pg_stat_replication_slots and for individual WAL senders it will be
>> > > available via pg_stat_replication both in PG13 and PG14.  Even if we
>> > > can get your patch in PG13, we can still keep those in
>> > > pg_stat_replication.
>> > > d. Get whatever we have in commit 9290ad198b1 for PG13 and change it
>> > > for PG14.  I don't think this will be a popular approach.
>> >
>> > I was thinking option (a) or (b). I'm inclined to option (a) since the
>> > PoC patch added a certain amount of new codes. I agree with you that
>> > it depends on the final patch.
>> >
>>
>> Magnus, Tomas, others, do you have any suggestions on the above
>> options or let us know if you have any other option in mind?
>>
>
> I have a feeling it's far too late for (b) at this time. Regardless of the size of the patch, it feels that this can
endup being a rushed and not thought-through-all-the-way one, in which case we may end up in an even worse position. 
>
> Much as I would like to have these stats earlier, I'm also leaning towards (a).
>

Fair enough.  The attached patch reverts the commits related to these
stats.  Sawada-San, can you please once see if I have missed anything
apart from catversion bump which I will do before commit?



--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Вложения

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

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Postgres is not able to handle more than 4k tables!?
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Stale external URL in doc?