Re: HEAD seems to generate larger WAL regarding GIN index
От | Tom Lane |
---|---|
Тема | Re: HEAD seems to generate larger WAL regarding GIN index |
Дата | |
Msg-id | 7544.1395066797@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: HEAD seems to generate larger WAL regarding GIN index (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: HEAD seems to generate larger WAL regarding GIN index
|
Список | pgsql-hackers |
Heikki Linnakangas <hlinnakangas@vmware.com> writes: > 2. Instead of storing the new compressed posting list in the WAL record, > store only the new item pointers added to the page. WAL replay would > then have to duplicate the work done in the main insertion code path: > find the right posting lists to insert to, decode them, add the new > items, and re-encode. That sounds fairly dangerous ... is any user-defined code involved in those decisions? > This record format would be higher-level, in the sense that we would not > store the physical copy of the compressed posting list as it was formed > originally. The same work would be done at WAL replay. As the code > stands, it will produce exactly the same result, but that's not > guaranteed if we make bugfixes to the code later, and a master and > standby are running different minor version. There's not necessarily > anything wrong with that, but it's something to keep in mind. Version skew would be a hazard too, all right. I think it's important that WAL replay be a pretty mechanical, predictable process. regards, tom lane
В списке pgsql-hackers по дате отправления: