powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Опять про varchar(n)
25 сообщений из 173, страница 3 из 7
Опять про varchar(n)
    #38718805
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeЯ просто представляю себе - мне нужно взять из файла строки и
посортировать... зачем мне делать их паддинг?
А ты возьми да напиши программу для их сортировки. Без паддинга. И посмотри насколько она
будет медленнее работать.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718807
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeпри N = 1 он равен 58mb.
при N = 32000 он равен 583mb.
Т.е. одни и те же данные хранятся в БД с разной степенью эффективности. Разница в 10
раз.
И тебя не восхищает, что разница в 10 раз, а не в 32000 раз?.. Ты вообще программист?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718814
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeЯ просто представляю себе - мне нужно взять из файла строки и посортировать..
мнэ....
ну взял ты строки. произвольной длины. Как ты их будешь переставлять местами (сортировать)? Известно же, что или ты будешь сортировать указатели на них, или сами строки. Индекс - это и есть отсортированные указатели на строки переменной длины. А по PLAN SORT один вариант - сортировать строки фиксированной (максимально возможной длины).

я фигею, что объясняю как бы прописные алгоритмические истины :-)
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718815
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee6 гигабайт не хватило на сортировку при N=32000. Хорошо что винт SSD, а то бы это получилось не 36 секунд, а минут 5.
При N=2048 на сортировку ушло 4 GB временных файлов, но фетч не прошёл, т.к. IBExpert-у не хватило памяти (он тоже зачем-то отжирает по максимуму памяти, на все N символов, не знаю уж зачем)

Вообще говоря сортировать по строке длинной 32000 символов глупо и здесь вряд ли что-нибудь поможет..

Другое дело что такая ошибка может возникнуть когда сортируется по другому поля, а резалтсет широкий. У ДЕ есть патчик который реализует сортировку иначе, когда сортируются только ключи и для каждого ключа запоминается RDB$DB_KEY, а потом вытаскивается остальной результат. Я пробовал (2.5) ту сборку в некоторых случаях производительность сортировки выросла, в некоторых упала. Если этот патч будет применён к тройке и оптимизатор будет достаточно умён, чтобы понять какой метод сортировки применять, то всё будет гораздо лучше.

kdvя в курсе, вопрос в том, как это обходит постгрес. Вначале вычисляет макс строку, а только потом сортирует?

вполне возможно он опирается на статистику
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718818
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee,

к слову - иногда бывает полезно покодить нечто низкоуровневое, на тему страничного хранения данных. Мне повезло, я когда осваивал Паскаль, была популярной библиотека Borland Database Toolbox . Там было много всякой интересной фигни. А еще была либа BTreeFiler, и вроде там был модуль bigsort, который позволял сортировать наборы данных адских размеров.
Первое, что я сделал, разобравшись в коде - перехерачил индексы из тулбокса на индексы по строкам произвольной длины.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718821
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvNickDeeЯ просто представляю себе - мне нужно взять из файла строки и посортировать..
мнэ....
ну взял ты строки. произвольной длины. Как ты их будешь переставлять местами (сортировать)? Известно же, что или ты будешь сортировать указатели на них, или сами строки. Индекс - это и есть отсортированные указатели на строки переменной длины. А по PLAN SORT один вариант - сортировать строки фиксированной (максимально возможной длины).

я фигею, что объясняю как бы прописные алгоритмические истины :-)
Я тоже фигею, т.к. сортировать я буду не строки, а создам указатели на строки, длина которых 4 байта или 8 байт, в зависимости от архитектуры, и буду оперировать ими. Переставлять местами записи я бы не додумался.
Так что думаю в коде всё-таки поинтеры местами меняются, как в прописных алгоритмических истинах :)
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718822
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovNickDeeпри N = 1 он равен 58mb.
при N = 32000 он равен 583mb.
Т.е. одни и те же данные хранятся в БД с разной степенью эффективности. Разница в 10
раз.
И тебя не восхищает, что разница в 10 раз, а не в 32000 раз?.. Ты вообще программист?..

Меня восхищает что разница вообще есть. А тебя не восхищает что есть разница в 10 раз? Ты вообще программист?.. :)
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718831
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee,

сортировка в кортежей в памяти это одно. Совсем другое дело когда эти данные в память не умещаются. Если сортировать только ключи, то взамен огребаем рандомные чтения. Тут уже надо оценивать что дешевле.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718834
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovNickDeeЯ просто представляю себе - мне нужно взять из файла строки и
посортировать... зачем мне делать их паддинг?
А ты возьми да напиши программу для их сортировки. Без паддинга. И посмотри насколько она
будет медленнее работать.

За счёт чего медленней? Что, скорость сравнения S1 > S2 зависит от паддинга? Не зависит.
Так для чего делать им паддинг?
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718837
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvТаблоидпри сортировках паддинг данных будет до декларированной длины поля
я в курсе, вопрос в том, как это обходит постгрес. Вначале вычисляет макс строку, а только потом сортирует?я так думкаю, что ничего он не вычисляет, а сразу лезет в DDL за декларированной длинной поля. Но лучше ДЕ никто не скажет :-)
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718838
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисNickDee,

сортировка в кортежей в памяти это одно. Совсем другое дело когда эти данные в память не умещаются. Например не умещаются из-за паддинга :)
Я вот думаю что если у меня есть набор данных из миллиона записей для сортировки, и часть из них не входит в память и сливается во временные файлы, то я уж точно буду сортировать поинтеры, а не менять местами записи этого набора данных в оперативке или на диске. И для этого мне паддинг точно не нужен.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718840
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Дениссортировка в кортежей в памяти это одно. Совсем другое дело когда эти данные в память не умещаются. Если сортировать только ключи, то взамен огребаем рандомные чтения. Тут уже надо оценивать что дешевле.Если данные не умещаются в памяти, то чтения (и записи) будут в любом случае.
Вроде как, при наличии свободного дискового пространства, самым быстрым будет многопутевое слияние со всякими "предсортировками" и балансировками. Дополнение "до максимума" увеличивает и требования к дисковому пространству и ввод-вывод и рабочий набор в памяти. Единственное, что, возможно, имеет смысл - секционирование данных по (байтовой) длине.

P.S. Предоставить рабочий код? Нет, не готов.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718841
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeЗа счёт чего медленней? Что, скорость сравнения S1 > S2 зависит от паддинга?
Не зависит. Так для чего делать им паддинг?
Отсортируй десяток гигабайт - узнаешь.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718845
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee,

ты игнорируешь то что я пишу

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

ну вот ты отсортировал ключи (поинтеры), которые перед этим необходимо было прочитать с диска. Это был шаг 1. А теперь шаг 2, для того чтобы отдать пользователю все запрошенные поля на диск надо слазить ещё раз. Вот здесь чтения будут рандомными.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718862
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeа создам указатели на строки, длина которых 4 байта или 8 байт, в зависимости от архитектуры, и буду оперировать ими. Переставлять местами записи я бы не додумался.
ну и плохо, что не додумался. вот это читал?
http://www.ibaseforum.ru/viewtopic.php?f=4&t=4175

У тебя два варианта
1) отсортировать результат за N секунд, выдать его клиенту.
2) построить индекс по X столбцам за M секунд, получить охрененный random io при выборке результата.

опять я излагаю алгоритмические факты? Типа, код при plan sort дураки делали?
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718868
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718883
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
как хорошо, что я нетрезв... а то бы поразгонял бы тут вас к чертовой матери :-) Жгите дальше, народ просит...
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718886
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr,

я вот с завтра буду нетрезв :-) и в силу различия в часовых поясах, прокомментировать смогу только послезавтра :-)
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718896
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvв силу различия в часовых поясах
это в куда тебя занесло? :-)
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718899
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovNickDeeЗа счёт чего медленней? Что, скорость сравнения S1 > S2 зависит от паддинга?
Не зависит. Так для чего делать им паддинг?
Отсортируй десяток гигабайт - узнаешь.

Хм.
При
Код: sql
1.
select * from T1 order by id

получается вообще сортируются числа, но данные всё-равно паддятся и используются временные файлы. Засада прям :)

Так и не понял зачем паддить. Зафетчили первый блок записей (сколько их там в половину сортировочного кэша входит), создали к записям массив поинтеров, посортировали этот массив. Зафетчили второй блок записей, создали к записям массив поинтеров, посортировали этот массив. Далее создаём на диске файл и, используя информацию из двух массивов поинтеров, сливаем записи из двух блоков в один, как при сортировке слиянием. Получаем на диске файл с отсортированными записями из двух первых отффетченных блоков.
Далее фетчим ещё два блока и проделываем с ними то же самое, т.е. создаём по ним файл с отсортированными записями.
В конце концов получится N файлов, каждый из которых будет содержать отсортированные внутри записи.
И без всякого паддинга.
Дальше попарно сливаем эти файлы, создавая новые (и удаляя при этом те, из которых данные уже были слиты).
В конце останется один большой файл.
Если сортировочный кэш равен 50 мегабайт, а записей на 200 мегабайт, то на первом этапе будет создано 4 файла по 50 мегабайт. Потом 2 по сто (с удалением предудущих четырёх). Потом эти два сольются в один. Хотя тут я не уверен, т.к. зачем нам сливать последние два, когда можно вместо создания последнего файла сразу отдавать записи движку. И даже скажу больше - не факт что будт эффективно даже из четырёх файлов делать два. Возможно проще отдавать записи движку выбирая нужную из 4-х источников, чтобы сэкономить на записи двух файлов по 100 МБ. Хотя возможно это зависит от скорости дисковой системы.
Места паддингу я так и не нашёл :)
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718902
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrэто в куда тебя занесло? :-)
еще не занесло. Завтра в Брюссель, в логово демократии :-)

NickDeeДалее фетчим ещё два блока и проделываем с ними то же самое, т.е. создаём по ним файл с отсортированными записями.
ну ты хоть бы исходники ФБ почитал...
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38718903
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvdimitrэто в куда тебя занесло? :-)
еще не занесло. Завтра в Брюссель, в логово демократии :-)

NickDeeДалее фетчим ещё два блока и проделываем с ними то же самое, т.е. создаём по ним файл с отсортированными записями.
ну ты хоть бы исходники ФБ почитал...
Мне проще достать подходящий алгоритм из коллективного бессознательного :)
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38719049
Фотография S.G.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeТак и не понял зачем паддить. Зафетчили ... создали....Самое время запилить свой собственный сервер. Без паддинга и с безразмерным варчаром.
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38719118
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
S.G.Самое время запилить свой собственный сервер. Без паддинга и с безразмерным
варчаром.
Или прислать патч к уже существующему. Если бы такой топик поднял я, Влад уже давно бы
сказал "ну так сделай, а мы посмотрим"...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Опять про varchar(n)
    #38719128
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

ЕМНИП, ты ведь пытался что там с сортировкой сделать. Как результаты?
...
Рейтинг: 0 / 0
25 сообщений из 173, страница 3 из 7
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Опять про varchar(n)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]