Re: [HACKERS] Full page writes improvement, code update
От | Koichi Suzuki |
---|---|
Тема | Re: [HACKERS] Full page writes improvement, code update |
Дата | |
Msg-id | 461ECA4E.9010101@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Full page writes improvement, code update ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>) |
Ответы |
Re: [HACKERS] Full page writes improvement, code update
|
Список | pgsql-patches |
Hi, Sorry, inline reply. Zeugswetter Andreas ADI SD wrote: > > Yup, this is a good summary. > > You say you need to remove the optimization that avoids > the logging of a new tuple because the full page image exists. > I think we must already have the info in WAL which tuple inside the full > page image > is new (the one for which we avoided the WAL entry for). > > How about this: > Leave current WAL as it is and only add the not removeable flag to full > pages. > pg_compresslog then replaces the full page image with a record for the > one tuple that is changed. > I tend to think it is not worth the increased complexity only to save > bytes in the uncompressed WAL though. It is essentially what my patch proposes. My patch includes flag to full page writes which "can be" removed. > Another point about pg_decompresslog: > > Why do you need a pg_decompresslog ? Imho pg_compresslog should already > do the replacing of the > full_page with the dummy entry. Then pg_decompresslog could be a simple > gunzip, or whatever compression was used, > but no logic. Just removing full page writes does not work. If we shift the rest of the WAL, then LSN becomes inconsistent in compressed archive logs which pg_compresslog produces. For recovery, we have to restore LSN as the original WAL. Pg_decompresslog restores removed full page writes as a dumm records so that recovery redo functions won't be confused. Regards; > > Andreas > -- ------------- Koichi Suzuki
В списке pgsql-patches по дате отправления: