Olivier Mascia wrote:

> Dear,
>
> On Wed, 14 Jan 2004 10:54:12 +0100,
> Marco Wobben wrote :
>
> > I've tried running RC8 (still CS architecture) and the failure is at
> the
> > exact same point in the gbak procedure with the exact same failure.
> I'll
> > try a different machine in the next few days and make sure it isn't the
> > hardware.
>
> Speaking of hardware, does the DB or the overall volume on which it
> resides during the test, goes over the ~130 GB ? Could a filesystem or
> other OS I/O limitation barrier be hit ?
> <...snip...>

There's only one way to tell for sure off course, but I'm confident that
the os or filesystem has no such limit. Simply because the file just
slowly grows up to 80G en there's no other issue at hand. The database
is completely empty until I start pumping data and do nothing but
inserts, inserts, inserts... Again a regular commit (every 2000 rows) or
one huge transaction with only one commit make no difference.

> Anyway, Nicholai seems confident that according to his computations, a
> table occupying more than about 70/80 GB of compressed data is the
> limit.

Can anybody confirm this, because if it's a fact, I will need to look
into another DBMS, which I would hate. Measuring physical compressed
data per table as a limit instead of some maximum row count would be
difficult to prevent (application wise).

>
> --
> Best Regards,
> Olivier Mascia