Philip Warner wrote:
> Andrew Dunstan wrote:
>
>> Unfortunately, it quite possibly would. You would not be able to build
>> two indexes on the same table in parallel, even though they wouldn't
>> have conflicting locks.
>>
> I suppose so, but:
>
> 1. By the same logic it might speed things up; it might build two
> completely separate indexes and thereby avoid (some kind of) contention.
> In any case, it would most likely do *something* else. It should only
> reduce performance if (a) it can do nothing or (b) there is a benefit in
> building multiple indexes on the same table at the same time.
>
> 2. Perhaps if there are a limited number of items that share
> dependencies but which are known to be OK (ie. indexes), maybe list them
> in the inner loop as exceptions and allow them to run parallel. This
> would mean a failure to list a new TOC item type would result in worse
> performance rather than a crash.
>
>
>
I will look at it in due course. Right now my concern is simply to get
something that works that we can do some testing with. I think that's
what we have now (fingers crossed). Some parts of it are jury rigged.
BTW, though, building indexes for the same table together is likely to
be a win AIUI, especially given the recent work on synchronised scans.
cheers
andrew
