You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by rahul merwah <ra...@eco-online.com> on 2005/05/09 19:27:20 UTC
TRUNCATE TABLE availability
Hi,
I was wondering on the latest status of TRUNCATE TABLE SQL: command. For the
TODO list on the site I can tell that the code is basically complete but
needs to be exposed – I was just wondering what are the details of the work
items left and, if necessary, what I can help with to get this finished.
Would it help to expose this as a feature request on JIRA so that comments
can be documented there? Our simple tests which require truncating a table
with 32K rows is taking painful minutes to complete (using DELETE FROM
tablename; autocommit off). I’m hoping even a naive TRUNCATE TABLE
implementation will be better than this by orders of magnitude!
- Rahul Merwah
Platform Architect
Ecosystems
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 5/9/2005
Re: TRUNCATE TABLE availability
Posted by "Lance J. Andersen" <La...@Sun.COM>.
i will enter a jira for this puppy
Mamta Satoor wrote:
>Is there a Jira entry for this already? If not, it will be nice to
>enter one so we keep track of it.
>
>Mamta
>
>On 5/10/05, Lance J. Andersen <La...@sun.com> wrote:
>
>
>>truncate table is a SQL extension supported by many database vendors now
>>as an optimization over delete table
>>
>>It is worth adding at somepoint to aid in porting apps from other backends
>>
>>Mike Matrigali wrote:
>>
>>
>>
>>>The following is sort of ugly, but will work with the current derby
>>>release, and the current trunk release.
>>>Look at the using the import system procedure with the replace option
>>>set to true and the source import being empty. I believe this will
>>>run faster than delete, even better would be if your application had
>>>a set of real rows to load when you want to truncate and use the table
>>>again.
>>>
>>>Here is a link to 10.0 documentation for the system procedure:
>>>http://incubator.apache.org/derby/manuals/reference/sqlj120.html#HDRIMPORTPROC
>>>
>>>
>>>I am not sure where truncate table is, I believe the issue is SQL
>>>standards.
>>>
>>>rahul merwah wrote:
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>I was wondering on the latest status of TRUNCATE TABLE SQL: command.
>>>>For the TODO list on the site I can tell that the code is basically
>>>>complete but needs to be exposed – I was just wondering what are the
>>>>details of the work items left and, if necessary, what I can help
>>>>with to get this finished. Would it help to expose this as a feature
>>>>request on JIRA so that comments can be documented there? Our simple
>>>>tests which require truncating a table with 32K rows is taking
>>>>painful minutes to complete (using DELETE FROM tablename; autocommit
>>>>off). I'm hoping even a naive TRUNCATE TABLE implementation will be
>>>>better than this by orders of magnitude!
>>>>
>>>>
>>>>
>>>>- Rahul Merwah
>>>>
>>>>Platform Architect
>>>>
>>>>Ecosystems
>>>>
>>>>
>>>>--
>>>>No virus found in this outgoing message.
>>>>Checked by AVG Anti-Virus.
>>>>Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 5/9/2005
>>>>
>>>>
>>>>
Re: TRUNCATE TABLE availability
Posted by Mamta Satoor <ms...@gmail.com>.
Is there a Jira entry for this already? If not, it will be nice to
enter one so we keep track of it.
Mamta
On 5/10/05, Lance J. Andersen <La...@sun.com> wrote:
> truncate table is a SQL extension supported by many database vendors now
> as an optimization over delete table
>
> It is worth adding at somepoint to aid in porting apps from other backends
>
> Mike Matrigali wrote:
>
> > The following is sort of ugly, but will work with the current derby
> > release, and the current trunk release.
> > Look at the using the import system procedure with the replace option
> > set to true and the source import being empty. I believe this will
> > run faster than delete, even better would be if your application had
> > a set of real rows to load when you want to truncate and use the table
> > again.
> >
> > Here is a link to 10.0 documentation for the system procedure:
> > http://incubator.apache.org/derby/manuals/reference/sqlj120.html#HDRIMPORTPROC
> >
> >
> > I am not sure where truncate table is, I believe the issue is SQL
> > standards.
> >
> > rahul merwah wrote:
> >
> >> Hi,
> >>
> >>
> >>
> >> I was wondering on the latest status of TRUNCATE TABLE SQL: command.
> >> For the TODO list on the site I can tell that the code is basically
> >> complete but needs to be exposed – I was just wondering what are the
> >> details of the work items left and, if necessary, what I can help
> >> with to get this finished. Would it help to expose this as a feature
> >> request on JIRA so that comments can be documented there? Our simple
> >> tests which require truncating a table with 32K rows is taking
> >> painful minutes to complete (using DELETE FROM tablename; autocommit
> >> off). I'm hoping even a naive TRUNCATE TABLE implementation will be
> >> better than this by orders of magnitude!
> >>
> >>
> >>
> >> - Rahul Merwah
> >>
> >> Platform Architect
> >>
> >> Ecosystems
> >>
> >>
> >> --
> >> No virus found in this outgoing message.
> >> Checked by AVG Anti-Virus.
> >> Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 5/9/2005
> >>
> >
>
Re: TRUNCATE TABLE availability
Posted by "Lance J. Andersen" <La...@Sun.COM>.
truncate table is a SQL extension supported by many database vendors now
as an optimization over delete table
It is worth adding at somepoint to aid in porting apps from other backends
Mike Matrigali wrote:
> The following is sort of ugly, but will work with the current derby
> release, and the current trunk release.
> Look at the using the import system procedure with the replace option
> set to true and the source import being empty. I believe this will
> run faster than delete, even better would be if your application had
> a set of real rows to load when you want to truncate and use the table
> again.
>
> Here is a link to 10.0 documentation for the system procedure:
> http://incubator.apache.org/derby/manuals/reference/sqlj120.html#HDRIMPORTPROC
>
>
> I am not sure where truncate table is, I believe the issue is SQL
> standards.
>
> rahul merwah wrote:
>
>> Hi,
>>
>>
>>
>> I was wondering on the latest status of TRUNCATE TABLE SQL: command.
>> For the TODO list on the site I can tell that the code is basically
>> complete but needs to be exposed – I was just wondering what are the
>> details of the work items left and, if necessary, what I can help
>> with to get this finished. Would it help to expose this as a feature
>> request on JIRA so that comments can be documented there? Our simple
>> tests which require truncating a table with 32K rows is taking
>> painful minutes to complete (using DELETE FROM tablename; autocommit
>> off). I’m hoping even a naive TRUNCATE TABLE implementation will be
>> better than this by orders of magnitude!
>>
>>
>>
>> - Rahul Merwah
>>
>> Platform Architect
>>
>> Ecosystems
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 5/9/2005
>>
>
Re: TRUNCATE TABLE availability
Posted by Mike Matrigali <mi...@sbcglobal.net>.
The following is sort of ugly, but will work with the current derby
release, and the current trunk release.
Look at the using the import system procedure with the replace option
set to true and the source import being empty. I believe this will
run faster than delete, even better would be if your application had
a set of real rows to load when you want to truncate and use the table
again.
Here is a link to 10.0 documentation for the system procedure:
http://incubator.apache.org/derby/manuals/reference/sqlj120.html#HDRIMPORTPROC
I am not sure where truncate table is, I believe the issue is SQL standards.
rahul merwah wrote:
> Hi,
>
>
>
> I was wondering on the latest status of TRUNCATE TABLE SQL: command. For
> the TODO list on the site I can tell that the code is basically complete
> but needs to be exposed – I was just wondering what are the details of
> the work items left and, if necessary, what I can help with to get this
> finished. Would it help to expose this as a feature request on JIRA so
> that comments can be documented there? Our simple tests which require
> truncating a table with 32K rows is taking painful minutes to complete
> (using DELETE FROM tablename; autocommit off). I’m hoping even a naive
> TRUNCATE TABLE implementation will be better than this by orders of
> magnitude!
>
>
>
> - Rahul Merwah
>
> Platform Architect
>
> Ecosystems
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 5/9/2005
>