Re: [HACKERS] Full page writes improvement, code update
От | Zeugswetter Andreas ADI SD |
---|---|
Тема | Re: [HACKERS] Full page writes improvement, code update |
Дата | |
Msg-id | E1539E0ED7043848906A8FF995BDA57901F40143@m0143.s-mxs.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Full page writes improvement, code update (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: [HACKERS] Full page writes improvement, code update
Re: [HACKERS] Full page writes improvement, code update |
Список | pgsql-patches |
> > 1) To deal with partial/inconsisitent write to the data file at crash > > recovery, we need full page writes at the first modification to pages > > after each checkpoint. It consumes much of WAL space. > > We need to find a way around this someday. Other DBs don't > do this; it may be becuase they're less durable, or because > they fixed the problem. They eighter can only detect a failure later (this may be a very long time depending on access and verify runs) or they also write page images. Those that write page images usually write "before images" to a different area that is cleared periodically (e.g. during checkpoint). Writing to a different area was considered in pg, but there were more negative issues than positive. So imho pg_compresslog is the correct path forward. The current discussion is only about whether we want a more complex pg_compresslog and no change to current WAL, or an increased WAL size for a less complex implementation. Both would be able to compress the WAL to the same "archive log" size. Andreas
В списке pgsql-patches по дате отправления: