Re: [h2] Re: some performance numbers

2013-10-10 Thread Brian Craft
Yes, doing a copy with PAGE_SIZE of 2k reduced the average query time even a bit more, to under 100ms. So this is mostly about the order of the data on disk. On Wednesday, October 9, 2013 10:48:14 PM UTC-7, Noel Grandin wrote: > > > It's quite likely that a dump and restore improved the locali

Re: [h2] Re: some performance numbers

2013-10-09 Thread Noel Grandin
It's quite likely that a dump and restore improved the locality of reference because all of the data belonging to a single table is now packed tightly together. On 2013-10-10 06:04, Brian Craft wrote: Copying the db to a new db with PAGE_SIZE of 8k lowered the average query time by a facto

[h2] Re: some performance numbers

2013-10-09 Thread Brian Craft
Continued posting in my own thread, in case it's useful to anyone. ;) Copying the db to a new db with PAGE_SIZE of 8k lowered the average query time by a factor of 20: from 10 sec to 0.5 sec. I should copy it to a db with the original PAGE_SIZE to see if insert order affects anything (since the

[h2] Re: some performance numbers

2013-10-09 Thread Brian Craft
After more investigation I strongly suspect that IO is my bottleneck, but the disk read rate is low because there are very many seeks being generated by h2. I expect PAGE_SIZE is the best way to address this. Is that correct? Does row insert order affect this much? For example, would alternate