"Dmitri Kuzmenko" <[EMAIL PROTECTED]> сообщил/сообщила в
новостях следующее: news:[EMAIL PROTECTED]
Hello, Dmitry!
Dmitry Voroshin wrote:
А ты знаешь - это первый "баг", который я обнаружил в FB буквально сразу
как с ним познакомился. :)))
Так что не надо про "никто" :|_|
и что у тебя в блобах было? пресловутые "примечания"?
я до сих пор, кстати, так и не услышал разумной аргументации
по поводу сортировки текстовых блобов.
только не надо сюда приплетать "это может понадобиться".
Эксперимент Выбегалло с кадавром, наверное помнишь, чем закончился. :-)
Не помню. Выбегалло помню... Кадавра помню... Эксперимент?.. Нет, не
помню... :(
Ты читай о чём там речь. Об экономии букавок при определении varchar. Это
просто пример. Могу заменить на order by - ничего не изменится.
правильно. хрен-ли думать. сортировка выполняется на диске, ну и слегка
в памяти. так? Сортировка выполняется сортировкой фиксированных блоков.
Соответственно, когда было vchar(1000) были "записи" в файле сортировки
примерно под 1200 байт, а когда стало vchar(2000) - в два раза больше.
Чему удивляться? Разница в 11 секунд и 3 минуты - не показатель, т.к.
тест не чистый. Может, 11 секунд сортировало в памяти, а когда 3 -минуты,
то в память не поместилось и полезло на диск.
Да ничего я не тестировал. Просто пример, что загибать размер варчара с
запасом тоже чревато.
Теперь, берем "текстовый блоб с примечанием". Размер блоба можно
определить только обратившись к нему. Значит, чтобы создать файл
сортировки с записями фиксированного размера, надо проехаться
по всем блобам в таблице и определить макс. размер блоба (это займет
время, считай как select count(*)).
Улавливаешь, чем это может кончиться? В одной из записей
блоб может оказаться не 500 байт, а 5000 байт. И тогда
ВСЕ записи в файле сортировки будут по 5000 байт.
Нормально?
Нет, так как таким образом сортирвать блобы нельзя. Это было бы точно
глупостью. Я не предлагаю АЛГОРИТМ сортировки - это дело разработчиков, если
они решатся такое сделать. Думаю что придумают что-нибудь получше.
