Here's a still-WIP patch that's a better candidate for inclusion. Inthis patch, I have created an executor node for indirect index scans.This node is created whenever an indexscan path is chosen for anindirect index. The planner treats indirect indexes just like regularindexes, except that they are explicitly excluded from index-only scansand bitmap scans.

Indirect indexes are more costly to scan than regular indexes, becauseof the need to scan the primary key index. However, the fact that theycan be ignored for HOT considerations make them worthwhile inupdate-heavy cases.

This patch only implements btree indirect indexes, but it is possible toimplement them with other index types too. The btree case is probablynot terribly interesting in conjuncttion with Pavan's WARM, but on theother hand it is expected that GIN indirect to remain useful. I havenot implemented GIN indirect indexes yet, to keep the patch small; oncewe have btree indirect indexes we can implement GIN, which should beeasy.

There are a few broken things yet, such as "REINDEX TABLE pg_class" andsome other operations specifically on pg_class. This one in particularbreaks the regression tests, but that shouldn't be terribly difficult tofix. Other things I know about that need further work:

* The killtuple implementation is bogus: it may delete entries that arevisible to scans other than our own (in particular it may delete entriesthat are being concurrently created, I think).

* We still pass PK values in scan->xs_ctup.t_self. Shouldn't bedifficult to fix, if a bit invasive.

* Only one primary key column is supported. Should be an easy fix ifthe above is fixed.

* Fill in the UNIQUE_CHECK_INSERT_SINGLETON bits, to avoid duplicateentries in the indirect index