I believe you have made quite a good description of what happens.
Index-building isn't very CPU-intensive for integers (geometrics and
tsearch is another matter, of course), so building all indexes of a large
table in one pass is a possibility that works now, provided you issue all
create index commands in concurrent connections at roughly the same time.
I don't think pgrestore does this, though.
>> So it works right now, except it doesn't have (yet) the infrastructure
>> to
>> keep the scans synchronized
>
> Perhaps you only got one read of the table because the process is
> essentially self-synchronizing. Whenever one process "gets ahead", it
> requires a disk read for the next page, which causes it to block for a
> relatively long time, during which time the other two processes either
> proceed reading rows from cache, or come to the end of the cache and
> block
> waiting for the same page to be read from disk. Obviously not a
> guarantee,
> as indexing a relatively more expensive type COULD cause one process to
> get
> multiple pages behind, and memory usage by other processes COULD cause
> intervening pages to be flushed from cache. But I have a suspicion that
> the
> experiment was not just a happy fluke, that there will be a strong
> tendency
> for multiple simultaneous index operations to stay sufficiently closely
> synch'd that the table will only be read from disk once. (Especially when
> such operations are done while the database is otherwise quiescent, as
> would
> be the typical case during a restore.)
>
