Re: A thought on Index Organized Tables
От | Gokulakannan Somasundaram |
---|---|
Тема | Re: A thought on Index Organized Tables |
Дата | |
Msg-id | 9362e74e1002241052i464b655gb475270dbac3c492@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 |
Yes. The visibility map doesn't need any new WAL records to be written.
We probably will need to add some WAL logging to close the holes with
crash recovery, required for relying on it for index-only-scans, but
AFAICS only for VACUUM and probably only one WAL record for a whole
bunch of heap pages, so it should be pretty insignificant.
Hmmm.... So whenever the update transaction changes a page, it will update the visibility map, but won't enter the WAL record.
So after the crash we have a visibility map, which has false positives. Isn't that wrong?
Let me repeat myself: if you think the overhead of a visibility map is
noticeable or meaningful in any scenario, the onus is on you to show
what that scenario is. I am not aware of such a scenario, which doesn't
mean that it doesn't exist, of course, but hand-waving is not helpful.
Well as a DB Tuner, i am requesting to make it a optional feature. If you and everyone else feel convinced, consider my request.
I'm not sure what you mean with "without any page level locking".
Whenever a visibility map page is read or modified, a lock is taken on
the buffer.
Thanks,
Gokul.
В списке pgsql-hackers по дате отправления: