Re: New wal format distorts pg_xlogdump --stats
От | Heikki Linnakangas |
---|---|
Тема | Re: New wal format distorts pg_xlogdump --stats |
Дата | |
Msg-id | 54806EFA.2030908@vmware.com обсуждение исходный текст |
Ответ на | New wal format distorts pg_xlogdump --stats (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: New wal format distorts pg_xlogdump --stats
|
Список | pgsql-hackers |
On 11/25/2014 05:36 AM, Andres Freund wrote: > Hi, > > The new WAL format calculates FPI vs plain record data like: > rec_len = XLogRecGetDataLen(record) + SizeOfXLogRecord; > fpi_len = record->decoded_record->xl_tot_len - rec_len; > > Due to the amount of data now handled outside the main data portion , > that doesn't seem correct to me. As an example, a couple thousand > inserts with full_page_writes=off now yields: > > Type N (%) Record size (%) FPI size (%) Combined size (%) > ---- - --- ----------- --- -------- --- ------------- --- > Heap/INSERT 30167 ( 99.53) 814509 ( 99.50) 965856 ( 99.54) 1780365 ( 99.52) > > I think fpi_len now needs to only count the sum of the of the actual > length of block images, and all the rest needs to be rec_len. Yeah, that's broken. I propose the attached. Or does anyone want to argue for adding an XLogRecGetFPILen() accessor macro for the hole_length in xlogreader.h. It's not something a redo routine would need, nor most XLOG-reading applications, so I thought it's better to just have pg_xlogdump peek into the DecodedBkpBlock struct directly. - Heikki
Вложения
В списке pgsql-hackers по дате отправления: