Есть ли кто-нибудь, кто не только прочитал эти статьи

Finding the Right Page Size for Your Indexes on Informix
и
Configurable Page Size (CPS) and Informix

но и проверил на своих базах? У меня создалось впечатление, что автор неправильно выбрал
размер страницы. Я бы например выбрал размер 12K, так как он по расчетам приводит к более
компактному индексу.

С уважением,
Виктор

svat2составляет около 4% ....
По 4% процента на каждую таблицу в базе, хмм..
в сумме может набежать неплохо.

victor16 svat2составляет около 4% ....
По 4% процента на каждую таблицу в базе, хмм..
в сумме может набежать неплохо.
даже не на таблицу, а на каждый индекс в таблице.

С уважением,
Виктор

Журавлев Денис victor16 svat2составляет около 4% ....
По 4% процента на каждую таблицу в базе, хмм..
в сумме может набежать неплохо.на 10 индексах 40% процентов, а на 100 так и все 400% ?
С математикой у Вас неплохо.
Теперь давайте представим ситуацию, что в план запроса входит поиск по десяти индексам.
На поиск по каждому запросу уходит, допустим 100 единиц времени. Итого 1000 единиц времени.
Сокращая время запроса каждого индекса всего на 4%, получаем общую производительность 960 единиц времени,
а это уже существенно при больших запросах. Если Вы внимательно читали статью, особенно
последний абзац, то, наверняка заметили фразу: "Are you going to be able to do this kind of analysis for every index in your system? Doubtful, but if you focus on the heavily used indexes of your system you can see some real improvement in performance."

С уважением, Виктор

vasilisИ почему вас так волнует полный размер индекса на диске, а не , например, количество индексных страниц ? Тогда уж брать 16К страницу, что приведет к гораздо более заметным результатам при проходе всего индекса (1511185 / 181551 = меньше в 8(!) раз).
Но зато нужен такой же буферный пул с бОльшими затратами ресурсов, больше процесс.времени на обработку каждой страницы и т.п.
Автор статьи так и сделал, но получил, наоборот, меньшую производительность, (см. апрельскую статью). В майской же статье он попытался найти наименьший размер страницы, при котором достигается наименьшее количество нодов в индексном дереве. Это, по его мнению, должно было привести (и привело) к увеличению производительности. Вопрос в том, нельзя ли было еще больше увеличить производительность (см. первый топик)

С уважением,
Виктор

vasilis...
что я тоже, как и многие, через это ("вылизывание" производительности) проходил :).

Мне просто понравилась идея, что простым изменением размера страниц можно попытаться добиться увеличения производительности.
vasilis
Надеюсь, что в целом мысль понятна и никаких обид у вас не возникнет.

Я не в том возрасте, чтобы обижаться.
vasilis
Также надеюсь, что вы и дальше будете представлять свои рассуждения и выводы, результаты экспериментов и сомнения.

Кстати, пока шло обсуждение этого топика, я написал простенькую програму на 4GL, которая по алгоритму из статьи анализирует индексы. В результате получается SQL-скрипт. Если кто заинтересуется, могу выслать.

С уважением,
Виктор

Журавлев ДенисКак вообще индексы работают? Надо спустится к искомому значению по b-дереву, например за 5 шагов (blevel=5), далее мы найдем "rowid" и пойдем за строк(ой)ми таблицы (7-й шаг, если строк несколько то 8, 9-й шаги).
Если ищем несколько значений в индексе, то мы перейдем к след-у значению индекса (10-й шаг), найдем "rowid", и снова пойдем в таблицу (11,12,13).

Выписка из справочника администратора:
Справочник администратора IBM Informix Dynamic Server
В системах, где достаточно пространства для хранения данных, выигрыш в производительности при использовании большего размера страниц может выражаться в следующем:
Уменьшается глубина индексов B-дерева даже при меньшем размере ключей индекса

Вы можете сгруппировать на одной и той же странице длинные строки, которые обычно занимают несколько страниц, размер которых равен размеру страницы по умолчанию

Как правило, при большем размере страниц сокращается время обработки контрольных точек

Можно задать другой размер страниц для временных таблиц, так что у них будет отдельный пул буферов.

Журавлев Денися не вижу нигде объяснения почему производительность вырастет.
Ответ из
Andrew FordIn version 10.0 of Informix Dynamic Server we were given the ability configure the page size of the data stored in a dbspace. For my Linux-based servers this means I have the option to store data and index pages on 2K, 4K, 6K, 8K, 10K, 12K, 14K and 16K pages instead of the previous option of just 2K pages. That's all fine and dandy, but how can we put this to good use?

One way would be to store data pages more efficiently. If I have a wide table that takes up 1007 bytes then I can only store 1 data row on a 2K page.

data rows per page = truncate((page size in bytes - 28) / (row size in bytes + 4))
data rows per 2K page = truncate((2048 - 28) / (1007 + 4)) = truncate(1.998) = 1
If I move this table to a 4K page I can store 4 data rows on a 4K page

data rows per 4K page = truncate((4096 - 28) / (1007 + 4)) = truncate(4.023) = 4
Wow. I can store twice as much data in the same amount of space by simply using a dbspace with a larger page size and I can query the same amount of data in half as many IOs. This benefit is a no brainer and you should check your system for similar situations.

What happens if we put our indexes on larger page sizes, can we get any performance benefit? At first glance the answer would be an easy yes. Under the covers the index structure is a balanced tree of pages. At the very top of the tree you have the root node and at the very bottom of the tree you have the leaf nodes and in between you have levels of nodes that connect the two. When you use an index to get to a data page you start at the root node and traverse the tree down through the levels until you reach the leaf node that has the address of the data page or pages that match your search criteria.

When you increase the page size of the pages your index nodes are stored on you can fit more keys per node, resulting in fewer nodes in your index tree. Fewer nodes can mean fewer levels in your index tree, fewer levels in your tree means fewer hops to get from the root node to your leaf nodes, fewer hops should mean fewer IOs and fewer IOs should mean better performance. This kind of thinking has led some (myself included) to suggest that it would be a good idea to always place indexes in a 16K dbspace because you will reduce the height of your index trees and therefore must increase performance
Журавлев ДенисПри изменении размера страницы производительность изменится, да. Но насколько нанопроцентов у каких пользователей в какое время дня и в какую сторону?
Для этого существуют тесты и обсуждение в форумах. Например, тот же автор пришел к выводу, что для его тестового индекса лучше 6K размер
Журавлев Денис15 лет назад %cached 99% считалось очень плохим и недопустимым уровнем, 8 лет назад я считал что 99% это очень хорошо и туда надо стремится, теперь я ржу над обоими утверждениями.Пройдет еще 15 лет и Вы будете смеяться и над сегодняшними своими утверждениями.

С уважением
Виктор

Журавлев ДенисСейчас напишу этому форду про FILLFACTOR, если его до 100 увеличить, то блевел тоже уменьшится.
Денис, Вашим сообщениям место в другой ветке
Я с Вами серьезно, а Вы ржете.

Журавлев Денис victor16 Журавлев ДенисСейчас напишу этому форду про FILLFACTOR, если его до 100 увеличить, то блевел тоже уменьшится.
Денис, Вашим сообщениям место в другой ветке
Я с Вами серьезно, а Вы ржете.
серьезно вот второй абзац http://www.sql.ru/forum/actualthread.aspx?tid=355411#3323399
не убавить ни прибавить
"- Ипполит, ну какой вы тупой! " (c)Женя Лукашин
Я же не обсуждаю, что должен делать dba, я предлагаю обсудить результаты в статье Форда.
Впрочем, 2 мнения я уже услышал, прогу на 4GL написал, на тестовой базе проверю результаты,
если кому интересно, сообщю.

КозьмаИ что обсуждать? Есть b-level, есть. Можно его уменьшить? Можно.
Дело не в уменьшении b-левела, а в увеличении производительности, так как не всегда можно добиться увеличения производительности простым уменьшением b-левела. Необходимо подобрать соответствующий размер страницы для каждого индекса, а также создать соответствующий пул буферов.