По каким алгоритмам информикс (9.4) рассчитывает размер следующего очередного экстента для таблицы ?

Как объяснить тогда вот такую картину в выделении экстентов:

Extents
Logical Page Physical Page Size
0 5:136670 4
4 5:136706 12
16 5:354062 4
20 5:354070 4
24 5:354082 8
32 5:354106 4
36 5:354114 8
44 5:354126 8
.............................

860124 93:161406 72
860196 97:196521 72
860268 97:258926 72
860340 98:412838 72
860412 72:34303 68
860480 72:483669 68
860548 78:398393 68
860616 83:177511 68
860684 101:122883 401403 !!!!!!!!!

Добавлю что последний большой выделенный экстент свободен почти на 90%,
впрочем есть такое подозрение, связанное с бизнес-логикой работы приложения, при которой таблица заполняется данными вначале, а потом они переносятся в другую таблицу и поскольку место выделяемое мелкими экстентами объединяется в один большой (если мелкие укладываются непрерывно) то его (большой экстент) и имеем в результате. Все в шоке. Меня сбило с толку именно свободное место в новом экстенте.

Нет, все таки дело не в приложении и не в маленьких экстентах объединяющихся в один большой - сегодня была ошибка в невозможности создать новый экстент для таблицы, посмотрел размер следующего экстента для нее

Next extent size 16777215
Number of pages allocated 276514
Number of pages used 276479
Number of data pages 276444
Number of rows 16033749
Partition partnum 5291288
Partition lockid 5291288

Extents
Logical Page Physical Page Size
0 59:121136 4
4 72:174077 4
8 72:174085 4
12 72:174105 4
16 72:174129 4
20 72:174161 4
24 72:174169 4
28 72:174193 4
32 72:174217 4
36 72:174241 4
...........................................................
276118 97:216726 36
276154 97:256685 36
276190 97:257581 36
276226 97:349841 36
276262 97:494371 36
276298 97:523368 36
276334 98:201340 36
276370 98:207682 36
276406 98:273175 36
276442 98:364872 36
276478 98:454946 36

Как посмотреть не используя oncheck (c помощью SQL) размер следующего выделяемого экстента для таблиц ?

А неплохая такая беседа с самим собой

Вот согласно документации:

If a permanent tables or user-defined temporary table already has 16 extents
allocated, the database server automatically doubles the size for subsequent
allocations. This doubling occurs every 16 extents. For example, if you create
a table with NEXT SIZE equal to 20 kilobytes, the database server allocates the
first 16 extents at a size of 20 kilobytes each. The database server allocates
extents 17 to 32 at 40 kilobytes each, extents 33 to 48 at 80 kilobytes each, and
so on.

Но в моем случае почему то информикс решил так не делать :(

Да, спасибо, уже разобрался с запросом :)
set isolation to dirty read;
select tabname[1,18] table_name
,ti_fextsiz fextent_pg
,ti_nextsiz nsize_pg
,count(*) num_ext
,sum(pe_size) total_size_pg
from systabnames, systabinfo,sysptnext
where partnum = ti_partnum and partnum = pe_partnum
and dbsname = 'baan'
and ti_nextsiz >=10000
--'db name or *'
group by 1,2,3
order by 5 desc,4 desc,1

Теперь осталос сделать для найденных таблиц alter table ... modify next size. Но еще есть и индексы, а для них вроде как modify next size делать нельзя ?