At this moment virtually all databases can only use single table indexing (except Oracle (composite indexes) and SQL Server (indexes on views)). A multi table join index however is a very efficient index for use in many applications with almost static query paths. They virtually eliminate the need for materialized views or jobs creating "temporary" tables which are refreshed on a regular basis.

The workings:
The JOIN index is limited to simple JOIN operators on single columns from 2 tables (most common JOIN case).

The Join is described in the create index statement: Proposed syntax:
CREATE INDEX idx_nn_1 ON TABLE_A

ON TABLE_A.COL=TABLE_B.COL

The index is limited in the optimizer to work only in the condition when the exact criteria for the index are met. For example:
A multi table index on table A, column A1 and table B, column B1, is only accessed when a join or where touches at minimum those 2 columns. Other indexes can still be merged with this index for faster results (same as current index merging).

The index is updated (real time) when an insert/update/delete operation occurs in one of the underlying tables. Since the impact of this update can be larger then the update of an index on a single table, the following requirement for performance of the index comes in view: The multi table join index has to contain partially empty nodes:
If a value is inserted in Table A, but on the predefined join it is not present in table B, the value for Table A is still inserted in the multi table index. This to prevent later lookups in Table A when the value is inserted in table B. This can occur in separate transactions (no foreign key definition is defined or required here (this could become a requirement depending on general perception of this idea)).