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
|
Список | 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 по дате отправления: