Hi Noel, I've produced two test cases from this issue:
1. Computed columns (including computed SELECT) *are* evaluated and stored during ADD COLUMN. This happens rapidly and I'm pleased with the performance in my real-life scenario. So there is 'no reason' for bulk INSERT to be slow. create table test1 (a1 identity, b1 int); insert into test1 values(1, -1); create table test2 (a2 identity); insert into test2 values(1); alter table test2 add column b2 int as select b1 from test1 where a1=a2; truncate table test1; -- erase b1 to test if b2 has already been stored... select * from test2; -- ...yes it has A2 <http://localhost:8082/query.do?jsessionid=ae2a32873bf9cc7e6b2122619f1bd492#> B2 <http://localhost:8082/query.do?jsessionid=ae2a32873bf9cc7e6b2122619f1bd492#> 1-1 2. I can reproduce slow INSERT *without* computed column, if the table contains an indexed column. In my real-life scenario, the computed column was a red herring because it simply changed the number of indexed columns in my destination table. Although 'obviously' INSERT is slower than INSERT SORTED, the problem on my test machines (H2 1.3.166) is that INSERT for 30 000 rows is 20-80 times slower than INSERT SORTED. In my real-life scenario, although I was using INSERT SORTED, the destination table includes an addition indexed column that is not part of the sort. http://code.google.com/p/h2database/issues/detail?id=391 James -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To view this discussion on the web visit https://groups.google.com/d/msg/h2-database/-/tGgWEXirgB8J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
