Subject | Re[4]: [Firebird-Architect] blobs causes table fragmentation. |
---|---|
Author | Dmitry Kuzmenko |
Post date | 2004-10-05T05:08:25Z |
Hello, Sean!
Tuesday, October 5, 2004, 1:46:17 AM, you wrote:
LS> You can appreciate that "gut intuition" is not enough to have a feature
LS> added to the engine, proof/analysis is required.
Ok.
LS> physically stored in the database file?
If it reads only record data, not blob, read will be longer if
blobs are stored at data page.
LS> Based on this observation, I would argue that the current approach of
LS> fitting data into the row data page would be preferred, since the blob
LS> would resolved without needing an additional disk read.
Good (IMHO) application never read lot of blobs with select * from table.
It read blobs only on application (user) demand, for example with
select * from table
where pk_field = :x.
In this case it is not sufficient where blob is stored.
--
Dmitri Kouzmenko
Tuesday, October 5, 2004, 1:46:17 AM, you wrote:
LS> You can appreciate that "gut intuition" is not enough to have a feature
LS> added to the engine, proof/analysis is required.
Ok.
>> So, it depends on client components/driver - it load all blobsLS> But what does the client operation have to do with how the data is
>> into cache or doesn't load any blobs at all.
LS> physically stored in the database file?
If it reads only record data, not blob, read will be longer if
blobs are stored at data page.
LS> Based on this observation, I would argue that the current approach of
LS> fitting data into the row data page would be preferred, since the blob
LS> would resolved without needing an additional disk read.
Good (IMHO) application never read lot of blobs with select * from table.
It read blobs only on application (user) demand, for example with
select * from table
where pk_field = :x.
In this case it is not sufficient where blob is stored.
--
Dmitri Kouzmenko