>> > > Storing 2Gb LO in table is not good thing.
at least vacuum and sequential scan will need to read it,
so I agree storing a large LO in the row is a no-no.
>> Well, now consider update of 2Gb row!
>> I worry not due to non-overwriting but about writing
>> 2Gb log record to WAL - we'll not be able to do it, sure.
This is imho no different than with an external LO, since
for a rollforward we need the new value one way or another.
I don't see a special problem other than performance.
Informix has many ways to configure LO storage, 2 of which are:
1. store LO in the Tablespace (then all changes are written
to the Transaction log directly, and all LO IO is buffered)
LO's are always stored on separate pages in this tablespace,
and not with the row.
2. store LO in a separate blobspace
What Informix then does is to not write LO changes to the log,
only a reference, and the process that backs up the logs
then also reads the new LO's and writes them to tape.
In this setup all LO IO bypasses the bufferpool and is
synchronous.
>
>Can't we write just some kind of diff (only changed pages) in WAL,
>either starting at some thresold or just based the seek/write logic of
>LOs?
>
>It will add complexity, but having some arbitrary limits seems very
>wrong.
The same holds true for the whole row. Only the changed columns
would need to go to the log. Consider a refcount and a large text column.
We would not want to log the text column with 4k if only the 4 byte refcount
changed.
Andreas