Re: Porting Guide and Statement made about Char Vs VarChar

Do not confuse predictive [row] read-ahead with access of the row data itself. The row was accessed, and it is being brought into memory without a page fault. It is not merely for performance, it is to limit the amount of work from an I/O perspective; although very interrelated, they are not the same. If the code knows where the data is and can ask for it nicely [i.e. efficiently] then it should do so rather than have the presumed access come about forced [by faulting; i.e. inefficiently].

I can agree on the one segment concern given the Segment1 layout, but there is no reason that the data can not be mapped in the page-aligned data segment, such that it enables most updates to VARCHAR to occur without rewriting the LOB data. I actually would expect that is the design; the goal being, to minimize any data move/copy activity. When LOB data is part of the segment the db can easily reserve some extra room for the VARCHAR data [at an almost invisible cost to storage, as seen by the user; room may already be there just by standard alignment of the data within the segment].

However if the VARCHAR is moved after the LOB data [by an update to increase the amount of data in a VARCHAR field] after initially being placed in front, then the algorithm I suggested as delaying access to the LOB data is a new cost for that row. That would fit with the warning in the documentation; i.e. it can be[come] costly for access to a row that has its data flowed into the varlen segment, when there are also LOB columns defined for that row. To access the VARCHAR data the LOB must [really: would likely] be paged to get there. I suppose it is plain silly for me to even talk about it, because as I had stated, I do not really know for sure how the data is mapped [or updated] in the varlen segment.

Having one segment per LOB column, beyond the one for the VARCHAR, is not always going to be more efficient than one. And the management of the additional segments obviously adds to the complexity, especially given the single-segment implementation for VARCHAR already existed and was functionally tested. The issue is obviously one of trade-offs in terms of both storage and performance, with regard to how the data will be accessed. I would suppose that if the single segment proves not to be a sufficiently good performer across various applications, then dev would investigate separating the VARCHAR from the LOB, and even possibly any /excessively/ large defined LOB to its own separate segment.

Regards, Chuck