Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4C7E55ED.2070408@oracle.com>
Date: Wed, 01 Sep 2010 06:32:29 -0700
From: Rick Hillegas <rick.hillegas@oracle.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: is there some way to support bulk insert without new syntax,
 in a zero admin way?
References: <4C77E25F.7040100@oracle.com> <4C7D49DF.8030308@sbcglobal.net>
 <4C7D5C24.7040504@oracle.com> <4C7D787E.8060904@sbcglobal.net>
 <4C7DA921.8060709@gmail.com>
In-Reply-To: <4C7DA921.8060709@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks to everyone for the additional discussion. I have logged two 
issues based on our consensus:

DERBY-4788 - Master issue for automatically applying the bulk-insert 
optimization when inserting large data sets into empty tables.
DERBY-4789 - Always apply the bulk-insert optimization when the source 
stream involves a table function.

Thanks,
-Rick

Bryan Pendleton wrote:
>>> I think that I would be satisfied with something less ambitious: If
>>> the source stream for the INSERT involves a table function, then
>>> always attempt a bulk insert--naturally, the bulk insert optimization
>>> would be applied only if the target table was empty. This wouldn't
>
> +1 to improved performance with no non-standard language changes!
>
> +1 also to the suggestion of Knut Anders to enable a standards-compliant
> TRUNCATE TABLE and then gain import speed that way.
>
> The entire discussion has been interesting and instructive, thank you
> for helping us understand the issues, even though the rest of us aren't
> commenting :)
>
> thanks,
>
> bryan
>