|
|
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeЯ просто представляю себе - мне нужно взять из файла строки и посортировать... зачем мне делать их паддинг? А ты возьми да напиши программу для их сортировки. Без паддинга. И посмотри насколько она будет медленнее работать. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 21:47 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeпри N = 1 он равен 58mb. при N = 32000 он равен 583mb. Т.е. одни и те же данные хранятся в БД с разной степенью эффективности. Разница в 10 раз. И тебя не восхищает, что разница в 10 раз, а не в 32000 раз?.. Ты вообще программист?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 21:49 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeЯ просто представляю себе - мне нужно взять из файла строки и посортировать.. мнэ.... ну взял ты строки. произвольной длины. Как ты их будешь переставлять местами (сортировать)? Известно же, что или ты будешь сортировать указатели на них, или сами строки. Индекс - это и есть отсортированные указатели на строки переменной длины. А по PLAN SORT один вариант - сортировать строки фиксированной (максимально возможной длины). я фигею, что объясняю как бы прописные алгоритмические истины :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:11 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee6 гигабайт не хватило на сортировку при N=32000. Хорошо что винт SSD, а то бы это получилось не 36 секунд, а минут 5. При N=2048 на сортировку ушло 4 GB временных файлов, но фетч не прошёл, т.к. IBExpert-у не хватило памяти (он тоже зачем-то отжирает по максимуму памяти, на все N символов, не знаю уж зачем) Вообще говоря сортировать по строке длинной 32000 символов глупо и здесь вряд ли что-нибудь поможет.. Другое дело что такая ошибка может возникнуть когда сортируется по другому поля, а резалтсет широкий. У ДЕ есть патчик который реализует сортировку иначе, когда сортируются только ключи и для каждого ключа запоминается RDB$DB_KEY, а потом вытаскивается остальной результат. Я пробовал (2.5) ту сборку в некоторых случаях производительность сортировки выросла, в некоторых упала. Если этот патч будет применён к тройке и оптимизатор будет достаточно умён, чтобы понять какой метод сортировки применять, то всё будет гораздо лучше. kdvя в курсе, вопрос в том, как это обходит постгрес. Вначале вычисляет макс строку, а только потом сортирует? вполне возможно он опирается на статистику ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:12 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, к слову - иногда бывает полезно покодить нечто низкоуровневое, на тему страничного хранения данных. Мне повезло, я когда осваивал Паскаль, была популярной библиотека Borland Database Toolbox . Там было много всякой интересной фигни. А еще была либа BTreeFiler, и вроде там был модуль bigsort, который позволял сортировать наборы данных адских размеров. Первое, что я сделал, разобравшись в коде - перехерачил индексы из тулбокса на индексы по строкам произвольной длины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:20 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
kdvNickDeeЯ просто представляю себе - мне нужно взять из файла строки и посортировать.. мнэ.... ну взял ты строки. произвольной длины. Как ты их будешь переставлять местами (сортировать)? Известно же, что или ты будешь сортировать указатели на них, или сами строки. Индекс - это и есть отсортированные указатели на строки переменной длины. А по PLAN SORT один вариант - сортировать строки фиксированной (максимально возможной длины). я фигею, что объясняю как бы прописные алгоритмические истины :-) Я тоже фигею, т.к. сортировать я буду не строки, а создам указатели на строки, длина которых 4 байта или 8 байт, в зависимости от архитектуры, и буду оперировать ими. Переставлять местами записи я бы не додумался. Так что думаю в коде всё-таки поинтеры местами меняются, как в прописных алгоритмических истинах :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:26 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovNickDeeпри N = 1 он равен 58mb. при N = 32000 он равен 583mb. Т.е. одни и те же данные хранятся в БД с разной степенью эффективности. Разница в 10 раз. И тебя не восхищает, что разница в 10 раз, а не в 32000 раз?.. Ты вообще программист?.. Меня восхищает что разница вообще есть. А тебя не восхищает что есть разница в 10 раз? Ты вообще программист?.. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:27 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, сортировка в кортежей в памяти это одно. Совсем другое дело когда эти данные в память не умещаются. Если сортировать только ключи, то взамен огребаем рандомные чтения. Тут уже надо оценивать что дешевле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:38 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovNickDeeЯ просто представляю себе - мне нужно взять из файла строки и посортировать... зачем мне делать их паддинг? А ты возьми да напиши программу для их сортировки. Без паддинга. И посмотри насколько она будет медленнее работать. За счёт чего медленней? Что, скорость сравнения S1 > S2 зависит от паддинга? Не зависит. Так для чего делать им паддинг? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:39 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
kdvТаблоидпри сортировках паддинг данных будет до декларированной длины поля я в курсе, вопрос в том, как это обходит постгрес. Вначале вычисляет макс строку, а только потом сортирует?я так думкаю, что ничего он не вычисляет, а сразу лезет в DDL за декларированной длинной поля. Но лучше ДЕ никто не скажет :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:47 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисNickDee, сортировка в кортежей в памяти это одно. Совсем другое дело когда эти данные в память не умещаются. Например не умещаются из-за паддинга :) Я вот думаю что если у меня есть набор данных из миллиона записей для сортировки, и часть из них не входит в память и сливается во временные файлы, то я уж точно буду сортировать поинтеры, а не менять местами записи этого набора данных в оперативке или на диске. И для этого мне паддинг точно не нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:48 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Симонов Дениссортировка в кортежей в памяти это одно. Совсем другое дело когда эти данные в память не умещаются. Если сортировать только ключи, то взамен огребаем рандомные чтения. Тут уже надо оценивать что дешевле.Если данные не умещаются в памяти, то чтения (и записи) будут в любом случае. Вроде как, при наличии свободного дискового пространства, самым быстрым будет многопутевое слияние со всякими "предсортировками" и балансировками. Дополнение "до максимума" увеличивает и требования к дисковому пространству и ввод-вывод и рабочий набор в памяти. Единственное, что, возможно, имеет смысл - секционирование данных по (байтовой) длине. P.S. Предоставить рабочий код? Нет, не готов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:50 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeЗа счёт чего медленней? Что, скорость сравнения S1 > S2 зависит от паддинга? Не зависит. Так для чего делать им паддинг? Отсортируй десяток гигабайт - узнаешь. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:50 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, ты игнорируешь то что я пишу NickDeeЯ вот думаю что если у меня есть набор данных из миллиона записей для сортировки, и часть из них не входит в память и сливается во временные файлы, то я уж точно буду сортировать поинтеры, а не менять местами записи этого набора данных в оперативке или на диске. ну вот ты отсортировал ключи (поинтеры), которые перед этим необходимо было прочитать с диска. Это был шаг 1. А теперь шаг 2, для того чтобы отдать пользователю все запрошенные поля на диск надо слазить ещё раз. Вот здесь чтения будут рандомными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 22:55 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeа создам указатели на строки, длина которых 4 байта или 8 байт, в зависимости от архитектуры, и буду оперировать ими. Переставлять местами записи я бы не додумался. ну и плохо, что не додумался. вот это читал? http://www.ibaseforum.ru/viewtopic.php?f=4&t=4175 У тебя два варианта 1) отсортировать результат за N секунд, выдать его клиенту. 2) построить индекс по X столбцам за M секунд, получить охрененный random io при выборке результата. опять я излагаю алгоритмические факты? Типа, код при plan sort дураки делали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 23:17 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, к слову http://www.boag.net.nz/backups/tp/BTF541/BIGSORT.PAS http://sourceforge.net/projects/tpbtreefiler/files/tpbtreefiler/5.57a/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2014, 23:24 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
как хорошо, что я нетрезв... а то бы поразгонял бы тут вас к чертовой матери :-) Жгите дальше, народ просит... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 00:04 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
dimitr, я вот с завтра буду нетрезв :-) и в силу различия в часовых поясах, прокомментировать смогу только послезавтра :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 00:10 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
kdvв силу различия в часовых поясах это в куда тебя занесло? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 00:39 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovNickDeeЗа счёт чего медленней? Что, скорость сравнения S1 > S2 зависит от паддинга? Не зависит. Так для чего делать им паддинг? Отсортируй десяток гигабайт - узнаешь. Хм. При Код: sql 1. получается вообще сортируются числа, но данные всё-равно паддятся и используются временные файлы. Засада прям :) Так и не понял зачем паддить. Зафетчили первый блок записей (сколько их там в половину сортировочного кэша входит), создали к записям массив поинтеров, посортировали этот массив. Зафетчили второй блок записей, создали к записям массив поинтеров, посортировали этот массив. Далее создаём на диске файл и, используя информацию из двух массивов поинтеров, сливаем записи из двух блоков в один, как при сортировке слиянием. Получаем на диске файл с отсортированными записями из двух первых отффетченных блоков. Далее фетчим ещё два блока и проделываем с ними то же самое, т.е. создаём по ним файл с отсортированными записями. В конце концов получится N файлов, каждый из которых будет содержать отсортированные внутри записи. И без всякого паддинга. Дальше попарно сливаем эти файлы, создавая новые (и удаляя при этом те, из которых данные уже были слиты). В конце останется один большой файл. Если сортировочный кэш равен 50 мегабайт, а записей на 200 мегабайт, то на первом этапе будет создано 4 файла по 50 мегабайт. Потом 2 по сто (с удалением предудущих четырёх). Потом эти два сольются в один. Хотя тут я не уверен, т.к. зачем нам сливать последние два, когда можно вместо создания последнего файла сразу отдавать записи движку. И даже скажу больше - не факт что будт эффективно даже из четырёх файлов делать два. Возможно проще отдавать записи движку выбирая нужную из 4-х источников, чтобы сэкономить на записи двух файлов по 100 МБ. Хотя возможно это зависит от скорости дисковой системы. Места паддингу я так и не нашёл :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 00:50 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
dimitrэто в куда тебя занесло? :-) еще не занесло. Завтра в Брюссель, в логово демократии :-) NickDeeДалее фетчим ещё два блока и проделываем с ними то же самое, т.е. создаём по ним файл с отсортированными записями. ну ты хоть бы исходники ФБ почитал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 00:53 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
kdvdimitrэто в куда тебя занесло? :-) еще не занесло. Завтра в Брюссель, в логово демократии :-) NickDeeДалее фетчим ещё два блока и проделываем с ними то же самое, т.е. создаём по ним файл с отсортированными записями. ну ты хоть бы исходники ФБ почитал... Мне проще достать подходящий алгоритм из коллективного бессознательного :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 00:56 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeТак и не понял зачем паддить. Зафетчили ... создали....Самое время запилить свой собственный сервер. Без паддинга и с безразмерным варчаром. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 10:35 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
S.G.Самое время запилить свой собственный сервер. Без паддинга и с безразмерным варчаром. Или прислать патч к уже существующему. Если бы такой топик поднял я, Влад уже давно бы сказал "ну так сделай, а мы посмотрим"... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 11:19 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38718815&tid=1563372]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
177ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 196ms |
| total: | 483ms |

| 0 / 0 |
