Firebird, group by и временные файлы

[metaclass]

Покопался в исходниках Firebird (2.5.2) на тему размеров временных файлов.
В итоге, там картина примерно такая:
* Запрос с условием и group by, входной датасет - десятки миллионов записей, результатирующий датасет - 150000 записей, размер записи порядка 150 байт (varchar расширены до максимального размера).
* Для выполнения запроса, подпадающие под условие записи (десятки миллионов) пишутся в сортировщик, затем досортировываются и выгребаются из него в правильном порядке с вычислением аггрегатов.
* Сортировщик реализован поверх временного хранилища данных, которое в свою очередь представляет последовательность блоков размером 1 мб, поначалу находящихся в памяти, а по мере превышения порога (8 МБ по умолчанию для классик-сервера) - записываемых во временные файлы. По виду это все крайне напоминает самодельную реализацию pagefile.
* Временные файлы расширяются кусками по 64 мб, с записью 262144 байтных буферов с нулями в эти куски.

Что здесь очень мне не нравится - это то, что обмен с временными файлами в принципе не выровнен по границам блоков диска, а является кратным размеру записи. Вот, например, из отладочного лога TempSpace::write: 2898976500 1048500

Второе - по-моему, конкретно для данного случая положить готовый результат group by в памяти в виде какого-нибудь дерева поиска и считать аггрегаты на ходу в него было бы гораздо эффективнее, чем долбится в i/o. Фактически мы при запросе читаем всю таблицу, пишем часть прочитанного в временный файл, потом сортируем, потом читаем обратно.
Но, возможно, нету эффективных способов отличить небольшой размер результата от большого размера, который эффективнее делать через сортировку.

Comments

[nicka-startcev.livejournal.com]

ммап() и 64 бита заметно упростят эту проблему, по идее.

[avnik.livejournal.com]

А в каком нибудь хипстерском риаке эта задача не решается?
(или хотя бы в более приличном sql)

[mipa.livejournal.com]

Что, прямо вот так и написано: 8Мб? Или все-таки настройка есть, типа TempCacheLimit?

[fd979.livejournal.com]

сортировщик везде реализован через темп-файлы. но причем тут сортировщик? или ячего-то не понял в четвертом часу ночи? :)

[worm-ii.livejournal.com]

> обмен с временными файлами в принципе не выровнен по границам блоков диска

По моим представлениям, это не критично, оверхед минимален. Главное, чтобы размер однократно читаемого куска был побольше, а число чтений соответственно — поменьше.

[zamotivator.livejournal.com]

* Для выполнения запроса, подпадающие под условие записи (десятки миллионов) пишутся в сортировщик, затем досортировываются и выгребаются из него в правильном порядке с вычислением аггрегатов.

Это называется Sort-based group by.

* Сортировщик реализован поверх временного хранилища данных, которое в свою очередь представляет последовательность блоков размером 1 мб, поначалу находящихся в памяти, а по мере превышения порога (8 МБ по умолчанию для классик-сервера) - записываемых во временные файлы.

Это есть в любой СУБД

> По виду это все крайне напоминает самодельную реализацию pagefile.

Именно так, и только так и можно работать.

> Временные файлы расширяются кусками по 64 мб, с записью 262144 байтных буферов с нулями в эти куски.

Угу

[zamotivator.livejournal.com]

> Второе - по-моему, конкретно для данного случая положить готовый результат group by в памяти в виде какого-нибудь дерева поиска и считать аггрегаты на ходу в него было бы гораздо эффективнее, чем долбится в i/o

это называется Hash Group By. Для него нужно, чтобы ключи влезли в память, и нифига не факт, что они лезут.
Впрочем, это уже фундаментальная проблема любой СУБД - сделать правильный estimate для row count, и на основе этой информации выбрать между sort, hash и index алгоритмами

[zamotivator.livejournal.com]

> Но, возможно, нету эффективных способов отличить небольшой размер результата от большого размера, который эффективнее делать через сортировку.


Ребе, вы сами всё поняли! В данном случае нужно знать unique cardinality по некоторому ключу.
Если у вас по этому ключи есть B-Tree индекс - estimate сделать легко, а вот если нету - сосите хуй. СУБД в такой ситуции работает по пессимистичному сценарию, и это правильно.

Другой вопрос в том, что можно научить её обучаться по итогам выполнения запросов.