db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: drop column functionality
Date Wed, 23 Aug 2006 15:46:33 GMT
I don't think performance should stop you from checking in this
functionality.  As you say, for a number of users it won't
matter at all, the big thing will be whether the functionality
is there or not.  Worry about performance later.

I know with a number of the alter column changes, the current
store support is going to require all the rows to be touched.

I am a little surprised as I thought the current system did not
require this for drop.  Is it possible the test is measuring
the time to both add and drop a column?

Tim Dudgeon wrote:
> Bryan Pendleton wrote:
>>> 1. Dropping the column seems very slow for large tables. 
>> This is good to know. I don't think anybody has really experimented with
>> this yet. Can you quantify "very slow" with some real measurements
>> you've taken? Do you think it would be reasonable to treat this as
>> a follow-on improvement to the DERBY-1489 changes, or do you feel that
>> the performance is so bad that DERBY-1489 is unusable as is?
>> I guess my assumption was that DROP COLUMN usage in large database
>> scenarios would be rare, and that it would be more common for people
>> to want to use DROP COLUMN during their initial application development,
>> when tables are typically smaller. But perhaps this is a bad assumption?
>> If you think this would be reasonable to treat as a follow-on
>> improvement, then please open a new JIRA issue for it, describe
>> it as well as you can with the data you can provide, and link
>> the new issue to DERBY-1489 so that we know they're related.
> I added some performance comparisons with Oracle to the JIRA issue.
> http://issues.apache.org/jira/browse/DERBY-1489
> This shows that Derby appears to be approx 3-4x slower at dropping a 
> column in large tables.
> I don't think this is a show stopper, but obviously any improvements 
> would be of benefit.
> Tim

View raw message