Subject | RE: [ib-support] RC1 database growing *much* faster than it shoul d |
---|---|
Author | Bill Morrison |
Post date | 2001-12-07T15:07:59Z |
The testing I used was to do an insert of 13000 records with the same blob
being sent to each one, disconnect, shutdown FB, then manually check the
file size on the disk. Both gdb's were at 217 megs of size.
The reason the blob is being "inserted" in the first place is that I need it
there to hand off to a UDF for external storage. This is so I can beat the
180 gig limit that appears to limit NT FB databases. I know I could use a
sproc to do this, but I'm trying to impact the client software as much as
possible.
If it's a case of FB automatically allocating the pages before firing the
before insert trigger, then wasting that space when the data is changed in
the trigger, then fine, I'll use sprocs instead. However, for some reason it
seems unreasonable to me for this behavior to exist.
Regards,
Bill M
-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Thursday, December 06, 2001 3:28 PM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] RC1 database growing *much* faster than it
should
At 01:51 PM 06-12-01 -0800, you wrote:
null!
But are you doing any byte-counting to see whether the .gdb file's growth is
unreasonably high? IOW, are you certain there *is* an issue? I recall Ann
posting some metrics one time, showing an estimate of expected
page-saturation in bulk inserts...
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
being sent to each one, disconnect, shutdown FB, then manually check the
file size on the disk. Both gdb's were at 217 megs of size.
The reason the blob is being "inserted" in the first place is that I need it
there to hand off to a UDF for external storage. This is so I can beat the
180 gig limit that appears to limit NT FB databases. I know I could use a
sproc to do this, but I'm trying to impact the client software as much as
possible.
If it's a case of FB automatically allocating the pages before firing the
before insert trigger, then wasting that space when the data is changed in
the trigger, then fine, I'll use sprocs instead. However, for some reason it
seems unreasonable to me for this behavior to exist.
Regards,
Bill M
-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Thursday, December 06, 2001 3:28 PM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] RC1 database growing *much* faster than it
should
At 01:51 PM 06-12-01 -0800, you wrote:
>I have just noticed the following phenomenon, and am curious if it'santicipated
>expected behavior, or if it can (or has been) fixed for the much
>RC2.rate
>
>I have a table with a blob field that I insert millions of records into. I
>have modified it's Before Insert trigger to do :
>
> new.blob=null;
>
>This works fine. The problem is that FB is still allocating space in the
>database for the new.blob, so my .gdb file is growing at the exact same
>as if I didn't have the trigger there in the first place.Don't include the blob column in your insert statement if you want it to be
>
>Is there anything that can be done to solve this issue?
null!
But are you doing any byte-counting to see whether the .gdb file's growth is
unreasonably high? IOW, are you certain there *is* an issue? I recall Ann
posting some metrics one time, showing an estimate of expected
page-saturation in bulk inserts...
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/