> Claudio Valderrama C. wrote:
>> Hello, I see the request for a bulk loader appearing from time to time in
>> our lists.
>> I understand a bulk loader is a facility able to do a batch insertion with
>> fast data insertion rates.
>> But our normal, single row insertions are -generally speaking- acceptable in
>> speed and faster than other servers.
>>
>> Therefore, to put the horse before the cart:
>> - Why do users need a bulk loader? Aren't we enough fast to insert records?
>> For example, our classic solution is to prepare a parameterized INSERT
>> statement and keep feeding data as parameters.
>> - What features do users expect from a bulk loader? It's mostly a client
>> side thing or a set of improvements in the server side, too?
>
> 1. Traditional approach is not fast and smart enough for real bulk loads
> (millions of records) due to remote protocol overhead.

Agree. But we can implement multy-insert statement allowing to send
array of parameters into prepared statement for execution. We can even
start from gbak and create BLR not for single insert at restore but for
N inserts and execute it at one roundtrip.

> Using external
> tables is *way* faster, but complicated and ext. tables have very
> limited support for data types (especially blobs are a show stopper
> here). Because remote is the bottleneck here, it's pure server side feature.

Yes. But inside the engine we also may shorten some code paths for
repeated routine

> 2. Good bulk load solution should also provide automatic handling of
> deferred index updates (at least for user defined ones) and ability to
> disable triggers on updated tables.

Agree

> 3. For symmetry, bulk load should also provide bulk dump. It would make
> data transfer between databases of the same structure more easy.

Agree

Regards,
Vlad