db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Segel" <mse...@segel.com>
Subject RE: Workarounds for too many open files?
Date Tue, 29 Nov 2005 19:07:01 GMT

-----Original Message-----
From: Lars Clausen [mailto:lc@statsbiblioteket.dk] 
Sent: Tuesday, November 29, 2005 9:29 AM
To: Derby Discussion
Subject: Re: Workarounds for too many open files?

On Mon, 2005-11-28 at 15:17, Michael Segel wrote:
> On Monday 28 November 2005 04:10, Lars Clausen wrote:
> I guess anyone who's going to try and create a 100GB database will also
run in 
> to this problem. (Remember the discussions on scalability?)
> Since I haven't seen the code on how Derby stores data to the disk, why so

> many files per index?
> A possible, but ugly work around is to create the index as you load the
> (Ugly in that you'll take a performance hit. However, this should work.)

That's what I did first, later I split it into two to see why it


Ah. Ok.

So then the issue with the temporary files is going to be an issue
regardless when you're building your index.

Geez, trying to migrate to a tablespace arrangement (either cooked or raw)
seems awfully appealing.

I guess this goes back to an earlier point I had been trying to make.
You have to make some basic design decisions that would impact not only the
small portion of the code you are trying to fix or enhance, but the overall
/ underlying structure of Derby.

I mean on one hand, its very feasible for someone to say that for your
application, Derby is the wrong database because it wasn't designed to
function that way. On the other hand, its quite possible to say "Well, we
want to see Derby to succeed as an all around 100% Java RDBMS" so then you
have to keep that perspective when you make design decisions.

I guess your experience will damper any large database tests. :-(

View raw message