> Vlad Khorsun wrote:
>>> If the server knew it was a bulk load, it could lock the table, load the
>>> data, and build the indexes using a sort and fast load / fast merge
>>> algorithm (more or less equivalent to dropping the indexes, loading, and
>>> redefining the indexes but easier). On the other hand, "locking the
>>> table" isn't exactly a classic concept.
>>>
>>
>> Hmm, why do we need to lock the table ?
>>
> If indexes are completely disabled, no. Otherwise the records will
> appear no to be there. If the load is done under a single transaction,
> however, this isn't an issue.

I thought only about singe transaction case. More - about single statement.

>> Some time ago i was thinking about loading records into new set of pages
>> probably not presented in pointer pages until load ends and retaining exclusive
>> lock on current filled page. Then we can assign logical page numbers to this new
>> pages by storing its physical numbers in pointer pages, extract and sort new keys
>> and merge it into existing indexes (or even rebuild indexes if we inserted much
>> more data then it was before).
>>
>> Btw, any links to fast merge algorithm description ?
>>
> IndexRootPage::indexMerge in the Falcon tree.

Thanks, i'll look at it if it will be needed. But i asked about some classic literature
to not reinvent the weel. Of course i can imagine how index merge may be implemented
and of course i can miss something interesting.

Regards,
Vlad