Дано : informix 11.5, таблица dps_cdocument с кучей полезных полей, dps_id типа SERIAL и одним полем xml_source типа TEXT, которое один раз заполняется и один раз используется. Остальные поля используются достаточно активно, апдейты статусов и все такое. Таблица доросла до 70GB из-за этого поля. При работе с ней буфера активно закакиваются xml, сильно снижая процент попаданий.
Менять код приложений, работающих с таблицей, не хочется.

Логично напрашивается сплитнуть таблицу на 2 и использовать view.
Требуется : придумать, как делать INSERT в новой схеме. С учетом того что sqlca.sqlerrd[1] в триггерах на view НЕ возвращает нового значения SERIAL, а TEXT нельзя передавать в хранимую процедуру как параметр.

Я подкинул товарисчу идею, опубликую позже. Жду ваших предложений :-)

В таком вот аксепте

Журавлев Дениса если бы поле было text in dbs..... то мимо буферов пролетало бы

Если бы я был такой умный до, как моя жена после... :)
Таблица досталась в наследство от индусов.

AndronМожно сделать отдельный dbspace и буферный пул для этой таблицы, и перенести ее туда с помощью alter table ... init in. Тогда конкуренции с остальными таблицами за один буферный пул не будет.
А можно ли менять расположение поля через alter table? Посмотрел в документации, нашел только для полей smart объектов.

Это не решает проблемы излишнего IO. xml один раз пишется и один раз читается, все остальные действия - работа со статусом. Кроме того, с таблицей работают в "пакетном" режиме, реально - несколько часов в день, а буферный пул отберет доступную память насовсем.

Журавлев Дениси вообще



The REFERENCES keyword lets you use BYTE and TEXT variables. These do not contain the actual data but are pointers to the data. The REFERENCES keyword indicates that the SPL variable is just a pointer. You can use BYTE and TEXT variables exactly as you would use any other variable in SPL.

О как. Век живи, век учись...