Basically i am requesting for an implementation similar to what you
mentioned in the second case. I think that implementing the second
option will have some performance benefit, if large amount of data is
moved or copied from one table to one or more tables in the same schema,
in addition to the benefits of first case.
now about the questions related to LOB updates it's some thing that
probably needs more discussions but in my view if a LOB is updated it
can be treated as a different LOB with different locator.
-rahul
Øystein Grøvlen wrote:
Rahul Dwivedi wrote:
Are there any plans for implementing such a feature where lob
locators are stored in tables and LOB are stored some where else, or
such similar functionality to enhance performance with multiple lobs
in single table.
I do not think that anyone has so far indicated that they have any
plans for this. However, I would very much like to understand better
what you are requesting.
If I understand you correctly, your main objective is that if LOBs are
stored outside the table, a table scan will be much quicker. Is that
what you are thinking of?
Others have asked for locators in order to save space if two columns
are referring the same LOB. That raises the question of what should
happen if a LOB is updated (e.g., through JDBC by Blob.setBytes).
Should that update be reflected by all columns referring the Blob, or
just the column being updated.
--
Øystein
