Симонов Денис1. На фига индекс по длинной предлинной строке
Миллион коротких строк, и одна длинная.
Симонов Денис2. На фига сортировать по длинной предлинной строке
Я не сортирую по длинной. Я сортирую миллион строк по 20-30 символов, и только одна строка там 2000. Не возникает вопроса, нафига движок выделяет по 2000 на все строки? Это между прочим 2GB памяти вместо 30MB. Я, глядя на эти цифры, отнёс бы это к категории "фатальный недостаток" :)

kdvNickDeeНе возникает вопроса, нафига движок выделяет по 2000 на все строки?
я ведь тебе уже объяснял. ты не читаешь, или не врубаешься алгоритмически?
16433843 и 16434091
хотя бы второе прочитай.я ведь уже объяснял это. ты не читаешь, или не врубаешься алгоритмически?
16434256
хотя бы почитай, уже :)

kdvя вот пару раз перечитал, и не понял (может, из-за ночного времени), зачем сортировать пойнтеры, а потом переливать записи в их порядке, если в блоке записи и так можно отсортировать.
Про поинтеры просто. Процессору быстрей поменять местами два четырех-байтных значения(поинтера), чем поменять местами два буфера. Причём разница в скорости пропорциональна размеру буфера, т.е. поменять местами два поинтера будет в ~1000 раз быстрей чем поменять два буфера размером по 4000. Поэтому буфера не перемещают. А раз мы перемещаем только ссылки, тогда допускается разный размер буферов под каждую запись.
Влад говорит что сортируются указатели:
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=668484&msg=7253772 Сортировка в FB сделана не совсем так, как описал КДВ. Те, кто в курсе про внешнюю сортировку с многопутевым слиянием на диске, дальше может не читать.

Итак, как оно там внутри (на пальцах) :

Есть буфер сортировки в памяти. В него поступают записи для сортировки. Длина ключа (то, что сравнивается) меньше длины записи сортировки. И длина ключа, и длина записи всегда фиксированного размера. Как только буфер заполнен, его содержимое сортируется quick sort'ом. Перемещаются только указатели на записи.

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

Когда все данные из потока выбраны, мы имеем N упорядоченных блоков во временном файле. Берём из него 8 блоков и сортируем их сортировкой слиянием. Упорядоченный результат пишем в тот-же временный файл. И т.д. В конце получаем тот же файл с N1 = N / 8 блоков бОльшего (в 8 раз) размера. Повторяем до тех пор, пока Ni > 8. После этого можно выдавать записи из оставшихся Ni блоков "наружу", есс-но сортируя их слиянием.


Теперь, куда тут можно попробовать прикрутить компрессию.

Блоки на диске образованы из записей сортировки фиксированной длины. Поэтому работа с такими блоками весьма проста. Я думаю, что вполне можно сжимать эти записи каким-нибудь лёгким алгоритмом, конечно добавив заголовок с длиной записи. При длине записи сортировки в несколько раз превышающей длину ключа вполне можно получить выигрыш в IO, несколько потеряв в CPU.
Из заболденного делаю вывод что внутри блока перемещаются НЕ записи, и таким образом фиксированные буфера нам для сортировки не нужны.

Таблоидkdvзначит, сортировка в ФБ работает именно так, как ты и хотел.Как это ? А вот же, дальше:hvladКогда все данные из потока выбраны, мы имеем N упорядоченных блоков во временном файле. Берём из него 8 блоков и сортируем их сортировкой слиянием. Упорядоченный результат пишем в тот-же временный файл. И т.д. В конце получаем тот же файл с N1 = N / 8 блоков бОльшего (в 8 раз) размера. Повторяем до тех пор, пока Ni > 8. После этого можно выдавать записи из оставшихся Ni блоков "наружу", есс-но сортируя их слиянием.
Это не требует фиксированных буферов. Я хотел именно этого.

Кстати в PostgreSQL есть ещё резиновый NUMERIC:
http://www.postgresql.org/docs/9.3/interactive/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL Both the maximum precision and the maximum scale of a numeric column can be configured. To declare a column of type numeric use the syntax:
NUMERIC(precision, scale)
The precision must be positive, the scale zero or positive. Alternatively:
NUMERIC(precision)
selects a scale of 0. Specifying:
NUMERIC
without any precision or scale creates a column in which numeric values of any precision and scale can be stored, up to the implementation limit on precision. A column of this kind will not coerce input values to any particular scale, whereas numeric columns with a declared scale will coerce input values to that scale. (The SQL standard requires a default scale of 0, i.e., coercion to integer precision. We find this a bit useless. If you're concerned about portability, always specify the precision and scale explicitly.)
Note: The maximum allowed precision when explicitly specified in the type declaration is 1000; NUMERIC without a specified precision is subject to the limits described in Table 8-2 .
В Table 8-2 написано:
range for NUMERIC without a specified precision = up to 131072 digits before the decimal point; up to 16383 digits after the decimal point .Зачем им такие длинные числа? Им наверное они не нужны. Но могут пригодиться некоторым пользователям :)
Нужно ли говорить что для этих чисел доступны все математические операции? Наверняка.
Можно ли говорить что это работает медленней чем у нас? Не факт:


Но нам нельзя резиновый NUMERIC, т.к. мы не умеем эффективно хранить и обрабатывать резиновые типы.

ТаблоидNickDee,

Alexander A. SakКак постепенно уходящий от FB в Postgres...А чего уходите? Не комфортно стало?

Симонов ДенисИХМО, самый главный недостаток PG в том что в нём функции могут стать инвалидными после изменения метаданных и он никак это не сообщит. Т.е. без труда позволяется такой DDL который делает функции не работоспособными, и в отличии от ORA статусов инвалид/не инвалид нету.
Там наверняка есть недостатки, но мы смотрим на других не за тем чтобы тыкать пальцами на их недостатки, а чтобы отмечать явные достоинства и примерять их на себя. Нам ведь именно это нужно, правда? :)

Dimitry SibiryakovNickDeeНам ведь именно это нужно, правда?
Нет, маниловщина нам ни к чему. Нам нужны кодеры, которые смогут влить эти чужие
достоинства в наш код.

Сколько кодеров прошло по этому пути за последние 7 лет?
И где они все сейчас?

Симонов ДенисNickDeeТам наверняка есть недостатки, но мы смотрим на других не за тем чтобы тыкать пальцами на их недостатки, а чтобы отмечать явные достоинства и примерять их на себя. Нам ведь именно это нужно, правда? :)

ИХМО, из всех достоинств PG ты выбрал самые не значимые.
Я выбрал те, где у нас слабости в реализации, в результате чего идёт неоправданный расход ресурсов компа.

NickDeeСимонов Дениспропущено...


ИХМО, из всех достоинств PG ты выбрал самые не значимые.
Я выбрал те, где у нас слабости в реализации, в результате чего идёт неоправданный расход ресурсов компа.
Но ещё увидел резиновый numeric, увидел timestamp в utc, увидел многообразие типов индексов, партиции, возможность подключения своих языков, наследование. Наследование - прикольная штука :)

Симонов ДенисNickDee,

я чего то тебя не пойму. Ну увидел ты где то фичу новую, ну захотел её - так создай тикет и жди пока реализуют (если конечно реализуют) или сделай сам. Или ты нас пытаешься сейчас убедить, что это архиважные штуки и разработчикам FB надо срочно всё бросить и заниматься этой фигнёй?
Ты наверное не заметил, но проблема не в том, что нет времени реализовать. А в том, чтобы видеть косяки.
Когда есть проблема реализовать, то говорится что фича хорошая, но нет времени. А у нас это звучит так: "фича пользователям не нужна", и предлагаются пути для обхода. А должно быть так: фича пользователям нужна, но пока нет ресурсов, и вот вам, пользователи, пути для обхода... И без пены у рта. Нефиг в сообществе лукавость разводить и считать пользователей дебилами.