Did it help? Sure helped me.
On Mon, Sep 12, 2011 at 12:26 AM, Mark Addleman wrote:
> Thanks!
>
--
C. Schanck
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to h2-database@googlegroups.com.
To unsubscribe
Try increasing the PAGE_SIZE parm in the connection properties; the
default is (I think) 4k, and I have found PAGE_SIZE=16384 to be vastly
more useful. Must be applied when the db is created. FWIW.
Chris
On Fri, Sep 9, 2011 at 7:55 PM, Mark Addleman wrote:
> Just a clarification: Is the doublin
message.
>
> On a sidenote, as the indexes will only be used to access the data
> directly (where id2= , and not where id>...), I'l trying to create a
> hash index to check if the performance is any better.
>
> Steph.
>
> On Jun 23, 4:14 pm, Chris Schanck wrote:
>
An embedded database storage engine with 100 million rows? That's ...
bigger than what I would think is the sweet spot for an embedded db.
Either way, I would look into changing the page size and the cache
size; both can be specified in the connection url, I think, and the
page size can't be chang
It really was an eye-opener for me. Glad to help.
On Tue, Apr 26, 2011 at 6:53 AM, Anthony wrote:
> Many Many Thanks chris that was very useful.
>
> Did as you suggest and wow
>
> Thanks for that
>
> Menkaura
>
> On Apr 25, 10:04 pm, Chris Schanck wrote:
> > Re
Resurrecting a thread from the dead is always fun...
We use H2 in our product as a small JDBC backend suitable for development
before deployment over larger, enterprise servers.
In times past, H2 was always *lots* faster than Postgres, for example, at
least on smaller (<1million row) datasets.
W
Axel,
Do you have a schema/data set to test against? From the look of your
numbers, it doesn't take a lot of data to show the performance issue.
Anecdotally, the page-store series of releases seems to be slower at ingest
than the old version, at least to me. "lots of indices" is a case we have as
Yowza! There'd be something to do one weekend for fun.
On Wed, Sep 1, 2010 at 4:22 AM, B M wrote:
> On Wed, Sep 1, 2010 at 2:04 PM, Philippe Marschall
> wrote:
> > Hi
> >
> > I just wanted to say thank you for Oracle sequence support:
> > SELECT foo.nextval FROM dual
> >
> > It's a big help to
I'll also mention that we use H2 exclusively as an embedded database.
On Wed, Apr 21, 2010 at 4:49 PM, Chris Schanck wrote:
> That's exactly what happens, a single complicated result set may touch off
> hundreds of smaller queries, spread across a thread pool of worker-bees.
t the
transaction visibility is correct.
Chris
On Wed, Apr 21, 2010 at 3:17 AM, James Gregurich wrote:
>
> So what do you do? Run a query on a connection, get a result set and then
> process that result set on multiple threads?
>
>
> On Apr 20, 2010, at 11:53 PM, Chris Schanck wr
afe. But H2's
> > Connection (http://www.h2database.com/javadoc/org/h2/jdbc/
> > JdbcConnection.html) is thread-safe. So yes, it's a kind of weird: as
> > long as you use H2, you'll be fine, but since you're doing it "wrong",
> > you'll lose intercha
The product I work on happily makes use of 100+ threads over 1 connection in
certain situations where multiple threads are evaluating different data
points which need to have the same transaction visibility. So far, H2 is
decent at this.
Chris
On Mon, Apr 19, 2010 at 8:23 PM, James Gregurich wrot
We just cut the next release of out product; H2 is one of the supported
RDBMSs. I chose to ship with 1.1.117, mainly because of various bugs in the
1.2 series. Actually, as of 132 the bugs appear to be fixed, but we have
hundreds of hours of testing with 117, and we are shipping this week, so
timin
Thomas, I am also seeing this problem.
It happens in a particular sequence of events. Our app creates a mid-sized
database (around 162M when I zip it up).
It creates around 2000 tables, 2-3 indexes per table.
Drops most of the indexes.
Loads the data
Recreates the indexes.
Things continue to
Having extensive evaluated both, and shipping a product which uses H2 in one
of it's flavors, I suspect you will end up running from Derby in a hurry.
Chris
On Wed, Feb 10, 2010 at 11:38 PM, Erin Drummond wrote:
> Actually, nevermind, I figured out this is possible with a BINARY(16)
> column. C
te:
> Did you get an answer?
> We increased the cache size from it default value (20MB?) to 128MB and
> the effect on performance has been positive, at least not
> negative. :-)
>
> Thomas
>
>
> On Jan 26, 10:23 am, Chris Schanck wrote:
> > I've had this sa
I've had this same question? I wondered if H2 even allocates the cahce if
you running in-memory?
Chris
On Tue, Jan 26, 2010 at 9:40 AM, Thomas Floracks
wrote:
> Hi,
>
> we are running an all in memory database with H2. I wanted to know if
> you recommend using an additional cache in memory or sh
My broken record answer for H2 performance problems: SET CACHE=
Chris
On Wed, Aug 26, 2009 at 2:17 PM, Caesar1985 wrote:
>
>
> In hsqldb, in my app the size of db file is nearly 36Mb, directly
> convert it into h2 db, the size of data and index file is 56Mb and
> 37Mb separately.
>
> I use jdbc
This is interesting. The query befoer the insert gives this plan:
SELECT PE.DISP, P1.SID, P1.LANG_DE AS TYPE, P2.LANG_DE AS RIGHT
FROM PUBLIC.KONT KO /* PUBLIC.KONT_TABLE_SCAN */ /* WHERE KO.KID = '_4038'
*/
INNER JOIN PUBLIC.PERS PE /* PUBLIC.PERS_TABLE_SCAN */ ON 1=1 /* WHERE
KO.PERS_ID = PE.PE_
Suresh, can you post a simple piece of example code? Things can usually be
solved fast with an example...
C
On Wed, Aug 12, 2009 at 9:12 AM, Suresh wrote:
>
> Hello Friends,
>
> I am getting problem while using h2 database with hibernate in my
> application. I have created some view in these dat
Yeah, that's why I didn't go that route. The space considerations are a big
deal when you have billions of rows (Oracle and Postgres for our app) and
the time is large.
What was useful for me to learn was that in nearly every DB, I can ask for
thousands of sequence numbers in a single SQL command,
Just to give a different perspective ...
Out app has to this a lot, where we conditionally add 100k items to a table,
adding the ones that are missing and returning their ids, or just returning
the ids if they exist. Kind of a combined insert/select problem.
I've found 2 approaches that work well
On Wed, Aug 5, 2009 at 5:20 AM, vips wrote:
>
> Hi Thomas,
>
> [ .. deletia ...]
>
> > In theory that should help, however for H2 currently it could be
> > better to create the indexes before inserting data
That's not my experience...
>
>
> If we are creating indexes before the inserts, th
On Wed, Jul 22, 2009 at 5:57 AM, vips wrote:
>
> Is there a way to speed up insert creation?
> Can I force parallelism while creating indexes?
>
Cool results.
As far as I know, index creation in H2 is a weak spot as far as performance.
Not so much because it is slow as such, but because it does
Actually, for primarily read situations, I've found H2 to be fine for
concurrent use with the default configuration. The table-level locking only
really becomes an issue when you have mixed updates and queries.
Be sure to give it lots of cache though.
Chris
On Mon, Jul 20, 2009 at 12:49 PM, Dina
Regarding caching, I use this:
Statement s = conn.createStatement();
int max = (int) (Runtime.getRuntime().maxMemory() / 1024); // max mem in K
int cacheSize = (max / H2_CACHE_DIVISOR) * 1024; // use 1/h...@_cache_divisor
of mem for cache
s.executeUpdate("SET CACHE_SIZE " + cacheSize);
s.commit();
One thing that is not always understood is how low the default cache size is
for most applications that are beyond toy size.
At least that was true a year ago. Our app dedicates 1/5 of available memory
to H2 cache; this is larger than most people need but we have a server app
and can afford it. Bu
On Thu, May 7, 2009 at 2:23 PM, Brish wrote:
>
> On May 7, 5:14 am, beaTunes Support wrote:
> > On May 6, 2009, at 23:35 , Brish wrote:
> > Yes, Brish, for moving back and forth that would be good.
> > But unfortunately the initial query still takes a very long time with
> > h2.
>
> Most databas
I can't answer your question, but I got rid of the Unexpectred Code Path
error by not using LOG=2. FWIW.
On Thu, Apr 16, 2009 at 9:27 AM, hendrik wrote:
>
> Hi,
>
> a customer of mine had some random crash which left the h2 1.0.79
> database corrupted.
> Recovery works, but a lot of data is mis
Ah Brish, good to see you're still here, still pushing your durability
concerns. Enjoy! True durability is for Angels.
sleepycat, Here's a version that seems to work fine for me; I trimmed your
connection urls a bit for clarity, but the main thing is you can't use LOG=0
and expect any durability;
sing
> it directly would not be 1.5 compatible.
> So you still need some adapter glue to use the backport or 1.5
> concurrent in the same program depending on the environment.
>
> On Mar 5, 1:04 pm, Chris Schanck wrote:
> > I would agree on NIO, but feel compelled to point out
I would agree on NIO, but feel compelled to point out there is a well
maintained backport of the concurrent stuff whichis tested back to 1.3 at
http://backport-jsr166.sourceforge.net/ . And the speedup from
ConcurrentHashMap in some situations is considerable (multi-reader case).
Likewise for expli
part of the query that's failing? (Understandable if the query is too
> much to post or you don't know exactly what part is breaking)
>
> -Evan
>
> P.S. No, I'm not an official H2 developer, just some guy who's started
> writing patches for H2 a few weeks ag
Note that this was against the latest build, 1.1.107. I am going to
change to the latest stable and start the test servers again and see
what that changes.
On Fri, Feb 20, 2009 at 4:03 PM, ch...@schanck.net wrote:
>
> Thomas,
>
> All of a sudden, we are seeing this error:
>
> org.h2.jdbc.JdbcB
On Tue, Nov 11, 2008 at 4:03 PM, edwardsk <[EMAIL PROTECTED]> wrote:
>
> ...
>
> ---QUESTION---
> Is there a way to "encourage/request" the database tables/indexes to
> update their statistics more frequently than its done by default?
> Are the indexes/ table statistics only recalculated when the
Thomas,
I just wanted to reiterate, optimizing the OR case is very important.
Our product uses 7 different RDBMS, and for large OR statements, I had
to do the H2 code significantly differently (select (...) union all
...) in order to get reasonable performance. And this approach has its
own probl
36 matches
Mail list logo
