When indices are partitioned on different columns, indices
pertaining to a single row can be located on different nodes. In
special situations, for example when exploiting co-location of keys
from different tables, one may wish to insert a things index by
index. This happens with the use of partitioned functions with
DAQ's. Inserting some indices and not inserting others will make an
inconsistent database, thus even if keys are inserted separately,
all keys should be inserted within the same transaction or have
some other guarantee of getting all inserted. Also, application
code will have to change if the indices change. This is not
considered good practice.
Consider a partition account table and a history table both
partitioned on the same key.
We could make a procedure updating the balance of the account
and recording the event.
create table acct (id int, balance numeric);
alter index acct on acct partition (a_id int);
create table hist (h_id int, ts timestamp, note varchar, primary key (h_id, ts);
alter index hist on hist partition (h_id int);
create procedure evt (in a_id int, in delta numeric, in note varchar)
update acct table option (no cluster) set balance = balance + delta where id = a_id;
insert into hist key hist option (no cluster) (h_id, note) values (a_id, note);
Such a procedure would be called on a particular partition using
a DAQ In practice, the RDF store uses single key operations for
atomically reserving ID's for IRI's, for example..