"Ann W. Harrison" <aharrison@...> wrote:

>
> Let's be sure we have a problem before rushing
> to solutions.

Isn't that pretty obvious? If a table contains lots of small blobs (or a
mixture of small and big ones), only N percents of every data page will be
occupied by the records and the rest will contain blob data. So every
statement reading this table (without touching blobs) will require 100/N - 1
more page reads than in the case of plain table without blobs. We just have
very fragmented data pages (from the records POV).

If we fetch blobs often, the current design is okay and allows to get blobs
from the same (already cached) page which is damn fast. But if we fetch
records without blobs often, then the current design is a bottleneck, as it
requires more I/O. The actual effect depends on data usage patterns in the
given application.

We have the very similar problem with "reserve" option in DPM. The engine
reserves up to 50% of the data page space for the subsequent updates to
preferrably place the back versions on the same page. But for every big
table which tends to be stable we have up to 2x page I/O which is also an
obvious bottleneck.

Nobody says the current design/implementation is bad. What Dmitry K. is
asking for is to be able to tune databases which have performance problems
with this design. The only workaround for the blobs issue is to store blobs
in different table when you don't fetch them often. Personally, I'd prefer
to have an explicit storage control over blobs for every table, but that's
just me, so this workaround is perhaps acceptable. As for the page space
reservation issue, it seems we have no workarounds at all.

Anyone still thinks we don't have any problems?


Dmitry