E
Что это? Аналог тоастов пг? Физическое перемещение данных при обновлении?
Size: a a a
2021 September 30
ИК
Насколько я помню, не помещающаяся часть записи помещается в другой блок, на который ставится указатель
E
И что делать если потом запись обновилась и уменьшилась?
E
(приходим в то же самое место, где есть мертвые блоки, которые надо периодически освобождать)
ИК
Если стала помещаться в блок, хорошо. Если дальше не помещается, переносим снова и снова
ИК
Shrink для этого придуман
E
О чем и говорим. Вакуум-элайк операции неизбежны.
D
мы говорим что это ерунда. только если запись после обновления перестала влазить такое произойдет
D
пошел почитал, действительно. давненько в доку не лазил
E
Я про то что она наоборот уменьшилась и освободила блоки.
Но в принципе любое изменение длины записи с констрейнтом на ширину приведет к этому.
Но в принципе любое изменение длины записи с констрейнтом на ширину приведет к этому.
D
нет
ИК
Не совсем так. Будем объективны, если запись состоит из полей фиксированной размера и записи не удаляются, мы никогда не столкнётся с необходимостью shrink в оракле. А в постгре она будет
E
Вы опровергаете не тот тейк
D
прости, но ты несешь полную пургу. оракл оперирует блоками, причем тут размер строки ? дальше, часть блока резервируется, именно на случай апдейта требующего больше места
D
т.е. одна строка стала короче, другая длинее, третья удалилась, блок запишется на тоже место. PCTFREE резервирует на случай если чуток больше понадобится
А
все же pctfree можно превысить и строка будет перенесена в другой блок
А
в старом блоке будет указатель
А
это тоже одна из причин замедления select, когда многоблочные чтения скатываются в одноблочные
D
да, может. но это большая редкость в моей практики, тестах tpc-c, sap-sd и многих других.
А
это довольно часто бывает, если нагородят в таблицах несколько сот колонок