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 по дате отправления: