Re: A thought on Index Organized Tables
От | Gokulakannan Somasundaram |
---|---|
Тема | Re: A thought on Index Organized Tables |
Дата | |
Msg-id | 9362e74e1002242319w18d0524di21fd13ba5dabfc4f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: A thought on Index Organized Tables (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: A thought on Index Organized Tables
|
Список | pgsql-hackers |
<br /><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin:0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The WAL record of the heap insert/update/delete contains a flag<br /> indicatingthat the visibility map needs to be updated too. Thus no need<br /> for a separate WAL record.<br /><div class="im"><br/></div></blockquote></div><br />Heikki,<br /> Have you considered these cases?<br />a) The currentWAL architecture makes sure that the WAL Log is written before the actual page flush( i believe ). But you are changingthat architecture for Visibility maps. Visibility map might get flushed out before the corresponding WAL gets written.I think you would then suggest full page writes here<br /> b) Say for a large table, you have multiple buffers ofvisibility map, then there is a chance that one buffer gets flushed to the disk and the other doesn't. If the WAL recordsare not in place, then this leads to a time inconsistent visibility map.<br /> c) If you are going to track all theWAL linked with a buffer of visibility map, then you need to introduce another synchronization in the critical path.<br/><br />May be i am missing something? I am asking these questions only out of curiosity. <br /><br />Thanks,<br/>Gokul.<br />
В списке pgsql-hackers по дате отправления: