Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.
От | Fujii Masao |
---|---|
Тема | Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump. |
Дата | |
Msg-id | 790571f2-7068-3717-6223-85683db74542@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump. (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
RE: Wrong statistics for size of XLOG_SWITCH during pg_waldump.
|
Список | pgsql-hackers |
On 2021/03/19 18:27, Fujii Masao wrote: > > > On 2021/03/19 15:06, Shinya11.Kato@nttdata.com wrote: >>>>> But 0 value maybe looks strange, so in current version I show it like >below: >>>>> Type N (%) Record size (%) FPI size (%) Combined size (%) >>>>> ---- - --- ----------- --- -------- --- ------------- --- ... >>>>> XLOG/SWITCH_JUNK - ( -) 11006248 ( 72.26) - ( -) 11006248 ( 65.78) >>>>> Transaction/COMMIT 10 ( 0.03) 340 ( 0.00) 0 ( 0.00) 340 ( 0.00) >>>> >>>> I just wanted to know why the "count" and "fpi_len" fields 0 are. >>>> So, it would be nice to have 0 values. Sorry for confusing you. >>> >>> Kato, it's not clear to me if you were asking for - to be changed back to 0? >>> >>> You marked the patch as Ready for Committer so I assume not, but it would be >>> better to say clearly that you think this patch is ready for a committer to look at. >> >> Yes, I don't think it needs to be changed back to 0. >> I think this patch is ready for a committer to look at. > > What's the use case of this feature? I read through this thread briefly, > but I'm still not sure how useful this feature is. > > Horiguchi-san reported one issue upthread; --stats=record shows > two lines for Transaction/COMMIT record. Probably this should be > fixed separately. > > Horiguchi-san, > Do you have updated version of that bug-fix patch? > Or you started another thread for that issue? I confirmed that only XACT records need to be processed differently. So the patch that Horiguchi-san posted upthread looks good and enough to me. I added a bit more detail information into the comment in the patch. Attached is the updated version of the patch. Since this issue looks like a bug, I'm thinking to back-patch that. Thought? Barring any objection, I will commit this. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Вложения
В списке pgsql-hackers по дате отправления: