Gregory Stark wrote:For the bloat, as opposed to corruption, case -
REINDEX scans the table
precisely once and sorts it.
what information is needed from the table that
is not in the old index? Why would a sequential
read of the old index alone (then some processing)
not suffice?
In Postgres, an index does not hold the livliness information of the rows it is pointing it; that is, there may be a thousand row-pointers in the index, but not all the rows pointed to by those pointers are known to be live. This is an implication of MVCC in Postgres.
So every index lookup has to look at the corresponding heap (aka table) row and decide if that row should be visible to the querying session.
Best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
Mail sent from my BlackLaptop device