Jim,

> You got the part about conceptually wrong correct. If the blob is
> small, it's on the the same page. If the blob is big, it's stored on
> separate pages, increasing the density of the root records, increasing
> the number of record fetched per data page fetch reducing linear scan
> time. If you always fetch the record by index and always fetch all
> blobs and your blobs are exactly the size declared in the record
> definition, you point would have some validity, but you would also
> have a most unique application.

I think we talk about different things - you about physical page/disk
access, I'm talking about the network.

What I'm saying is that if I use blob, any access to the blob requires
me to send three more messages over the wire. If you use Internet
connection each message round to server and back will take, let's say,
200 ms due to delays. Not nice.

Also if my data are stored in VARCHAR column, they will be transferred
over the wire together with other parts of the record. If I do not use
positioned updates (SELECT FOR UPDATE), server will batch records so
they fit a network packet size. In case of using blobs this is not
possible and performance of the application will decrease.

So, I still think that with current _implementation_ of our wire
protocol it makes sense to put small binary data into VARCHAR columns
and not into the blobs.

Roman