> I've never used seek_blob so i can oversee a problem here, but can
> we not "simple" decompress it in memory and do the seek. Assuming
> that the compression is done in blocks it wouldn't use much more
> memory than now.

Yes, it is possible, though it would mean decrease in performance
compared to seek in an uncompressed BLOB. Reason is that seek is
specified in an uncompressed stream, but database must do some
computation to jump to the right position. This is no longer
position/page_size. So, either some lookup table containing a byte
start/end for each page, or decreased performance. At least I do not
know the compression with a random seek or even something similar.

> It's done per field/item, so the delta's will be still small and
> possible:
>
> edsNull, edsIntLen5, <data>, edsCompression, edsZip, <data>,
> edsIntLen4, <data>, edsCompression, edsZip, <data>, ...
>
> The <data> inside edsCompression can contain compressed :
> - edsUtf8Count2, <data>
> - edsOpaqueCount3, <data>
> - or whatever other type

Sure, but that would also mean that server has to decompress record
and apply delta each time it is accessed and you cannot move this to
the client. Or I miss something?

Roman