Re: A thought on Index Organized Tables - Mailing list pgsql-hackers

From Gokulakannan Somasundaram
Subject Re: A thought on Index Organized Tables
Date
Msg-id 9362e74e1002240805m44fe96bak6f162ae6f48a54e7@mail.gmail.com
Whole thread Raw
In response to Re: A thought on Index Organized Tables  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: A thought on Index Organized Tables  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

I think you're a barking up the wrong tree.  AFAIUI, the need for the
visibility map has not very much to do with whether the table has
indices, and everything to do with avoiding unnecessary VACUUMs.  In
any event, you've not shown that the visibility map HAS any overhead,
so talking about skipping it seems entirely premature.  Keep in mind
that the visibility map is quite small.

OK! i am not saying to remove the visibility map, if i am misunderstood. All i am saying here is to remove the index only scan processing of visibility map. If it is being used only for vacuums, you need not make it crash safe and no WAL comes into picture.
 

The point of the visibility map as far as index-only scans are
concerned is that if all the needed column values can be extracted
from the index, we still need to read the heap page to check tuple
visibility - unless, of course, we already know from the visibility
map that all the tuples on that heap page are guaranteed to be visible
to all transactions.  On a read-only or read-mostly table, this will
reduce the cost of checking tuple visibility by several orders of
magnitude.

I understand that. As i suggested above, if you have no indexes for a table, why do you need to spend the extra effort in making it crash safe for that table? Hope i am clear.

Thanks,
Gokul.


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Remove pre-7.4 documentaiton mentions, now that 8.0 is the oldest
Next
From: Bruce Momjian
Date:
Subject: Re: Determining client_encoding from client locale