powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Еще раз о ramdisk
22 сообщений из 47, страница 2 из 2
Еще раз о ramdisk
    #38562915
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrВыкинет твой волшебный инсерт все конкурентные сортировки в своп и придут по твою душу злые клиенты и/или админы. Будешь им рассказывать про новые времена и свой подход к дешевым гигабайтам.Они и так придут, если я не выставлю адекватный TempCacheLimit, а не эти нищебродские 64 Мб :-)
И, кстати: а ведь можно ввести такой параметр, как максимальная квота использования TempSpace одним аттачем ? Тогда ко мне в комнату точно никто не придёт с б/битой. Кажеццо...
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38562922
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидhvladЗа контроль уникальности я даже не заикаюсь.Я вёл речь только об insert'ахА их что - не надо контролировать ? А что делать параллельным коннектам, которые тоже что-то вставляют ?

ТаблоидЕсли же прога написана так, что делает insert'ы недопустимых дубликатов - разраб ССЗБ, пусть переписывает на merge.Так и сделаем - введём новый код ошибки isc_app_dev_is_a_fool и будем её возвращать. Всегда.

ТаблоидРезультат теста предсказуем и не интересен, но пусть будет как аргумент.С этим у тебя всегда проблемы. Твой тест не отражает реальности. Ибо при построении индекса применяется совсем не дакой алгоритм, как при добавлении ключей в индекс (пусти и пачки).


И вернёмся к начальному вопросу:
ТаблоидhvladА что такое "входной поток" ? Где он начинается и где заканчивается ?эммм... ну вот когда движок начинает делать вот такое:
Код: sql
1.
insert into t select ... from s;


- то разве он не "чувствует", когда заканчиваются данные из источника ?А теперь найди этот вот
Код: sql
1.
insert into t select ... from s;

в своём предсказуемом и не интересном (полностью согласен!) тесте
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38562954
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,
отложенные индексы - бред. Я ещё понимаю если бы ты отложенных FK требовал. И чего ты так к этим GTT доматался? Если ты их используешь только для оптимизации выборок, то может лучше просить фич оптимизатора?
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38562992
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидпропущено...Я вёл речь только об insert'ахА их что - не надо контролировать ? А что делать параллельным коннектам, которые тоже что-то вставляют ?куда, в GTT ? (разговор только о времянках!)

hvladТвой тест не отражает реальности. Ибо при построении индекса применяется совсем не дакой алгоритм, как при добавлении ключей в индекс (пусти и пачки).я знаю, что там всё по-другому; но сравнить, хотя бы с точностью два лаптя, - как еще ?

hvladА теперь найди этот вот
Код: sql
1.
insert into t select ... from s;

в своём предсказуемом и не интересном (полностью согласен!) тестекогда insert-команда содержит values(), то ясен пень, что тут нет окончания "входного потока". Этот пример был просто скопипастен с другого, с минимальными изменениями.
Речь идёт именно о случае, когда есть многострочный "источник" данных.
3.2 млн строк, deferred index rebuild: 96 + 21 = 117 сек
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
$ /opt/fb30trnk/bin/isql localhost/3333:/var/db/fb30/perfins.fdb -i perfins_deferred_index_rebuild.sql
insert into gtt
select gen_id(g,1),uuid_to_char(gen_uuid()),uuid_to_char(gen_uuid()),uuid_to_char(gen_uuid())
from rdb$types,rdb$types,rdb$relations;
Current memory = 21691592
Delta memory = 673896
Max memory = 23662128
 Elapsed time= 96.494 sec 
Cpu = 0.000 sec
Buffers = 2048
Reads = 55
Writes = 68649
Fetches = 21873700

commit;
Elapsed time= 0.009 sec
. . .

create unique index t_id on gtt(id);
create index t_s02 on gtt(s02);
create index t_s03 on gtt(s03);

commit;
Current memory = 21911904
Delta memory = 168560
Max memory = 291420376
 Elapsed time= 20.928 sec 
Cpu = 0.000 sec
Buffers = 2048
Reads = 280546
Writes = 52023
Fetches = 28894253
== vs ==
3.2 млн строк, immediate index update: 285 sec
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
insert into gtt
select gen_id(g,1),uuid_to_char(gen_uuid()),uuid_to_char(gen_uuid()),uuid_to_char(gen_uuid())
from rdb$types,rdb$types,rdb$relations;
Current memory = 21971712
Delta memory = 85520
Max memory = 291420376
 Elapsed time= 285.282 sec 
Cpu = 0.000 sec
Buffers = 2048
Reads = 9456360
Writes = 9543423
Fetches = 77563527
commit;
Elapsed time= 0.007 sec
. . .


PS. у Cтаршего Брата много лет существует deferred constraints , проверяемые при commit'e транзакции (даже не по окончаниии стейтмента). Сильно подозреваю, что индексы, которыми обеспечиваются эти самые deferred-констрейнты (UK/FK), также обновляются в самом заду, не сразу. А также (как минимум с 11.1.0) - deferred index maintenance - судя по тексту, это как раз то самое , "с ключиками в памяти".
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563002
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисотложенные индексы - бред.Обоснуй.
Симонов ДенисЯ ещё понимаю если бы ты отложенных FK требовал. И чего ты так к этим GTT доматался? Если ты их используешь только для оптимизации выборок, то может лучше просить фич оптимизатора?Использую, и не я один. Запрос такой фичи оптимизатора (материализацию промежуточных результатов) делать не нужно, она есть вроде бы. По кр. мере, я точно знаю, что ДЕ в трёшке что-то делает (или почти сделал) в этом направлении.

Но GTT'шки юзаются не только для ускорения джойнов. Например, загрузить из файла прайс-лист поставщика с предпросмотром его перед окончательным импортом. Там может быть 1...2 млн строк (речь о запчастях), юзера могут выполнять в нём поиск, всякие модификации цен, скидочных категорий и проч. Джойнов тут нет вообще. Надо просто загрузить его побыстрее и проиндексировать.
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563034
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидPS. у Cтаршего Брата много лет существует deferred constraints , проверяемые при commit'e транзакции (даже не по окончаниии стейтмента). Сильно подозреваю, что индексы, которыми обеспечиваются эти самые deferred-констрейнты (UK/FK), также обновляются в самом заду, не сразу.

с чего ты взял, что deferred constraints будут работать быстрее чем построчные? Да и применяются они не для скорости, а именно чтобы отложить проверку, что как бы следует из названия.

Что касается ускорения загрузки (insert), то тут лучше бы ты просил bulk insert. По-моему даже в трекере где-то есть insert со множественным values.
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563041
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисЧто касается ускорения загрузки (insert), то тут лучше бы ты просил
bulk insert. По-моему даже в трекере где-то есть insert со множественным values.
Array DML было бы эффективнее.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563049
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид(разговор только о времянках!)Это ты так думаешь

Таблоидя знаю, что там всё по-другому; но сравнить, хотя бы с точностью два лаптя, - как еще ?Ты делаешь утверждения - ты их обосновываешь. Пока что твои обоснования не выдерживают критики

Таблоиду Cтаршего Брата много лет существуетЯ знаю. Но у него много чего ещё существует.
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563052
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисс чего ты взял, что deferred constraints будут работать быстрее чем построчные? Да и применяются они не для скорости, а именно чтобы отложить проверку, что как бы следует из названия.я знаю, что они для откладывания проверки. Скорость не сравнивал, в лом. А второй ссылки, про deferred index maintenance, разве не достаточно, чтобы просто обратить внимание на это ?
Симонов ДенисЧто касается ускорения загрузки (insert), то тут лучше бы ты просил bulk insert. По-моему даже в трекере где-то есть insert со множественным values.а что ты вкладываешь в эту фразу, bulk insert ? что при этом должно/ не должно происходить ?
ЗЫ. тикета не вижу; есть только фикс регресса, недавний.
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563053
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

ну или это

Таблоид,

подозреваю что вот это deferred constraints требует блокировки. Да и часто ли ты их применял в ORA. Лично я вижу их пользу только для отложенных FK, да и то только для случая когда в таблицу запихивается древовидная структура и не возможно вставить какую либо запись до вставки её родителя. В остальных случаях порядок вставки всегда можно определить.
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563061
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТы делаешь утверждения - ты их обосновываешь. Пока что твои обоснования не выдерживают критики.ну, а как еще сравнивать-то ? при отсутствии чего-то типа "обнови индекс только по добавленным строкам" ? :-)
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563063
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

CORE-1978 как по мне так это часть CORE-3880
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563072
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис CORE-1978 как по мне так это часть CORE-3880 Это не bulk insert, а именно "конструктор" с заранее известными числами внутри values(). Просто что бы не ходить на поклон к rdb$database. Индексы по-прежнему будут обновляться для каждой добавляемой записи.
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563081
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

я тут только об уменьшении кол-ва round-trip на массовых вставках и это полезно не только для GTT. Про индексы я тут не говорил. Что касается именно отложенных констрейнов, то тебе уже говорили, что если и делать, то для всех таблиц, а не только для GTT. А это куда сложнее
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563085
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидhvladТы делаешь утверждения - ты их обосновываешь. Пока что твои обоснования не выдерживают критики.ну, а как еще сравнивать-то ? Проблемы индейцев ... (ц)
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563097
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидпропущено...ну, а как еще сравнивать-то ? Проблемы индейцев ... (ц)дежурно-казённая отговорка :-)
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563176
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидИспользую, и не я один. Запрос такой фичи оптимизатора (материализацию промежуточных результатов) делать не нужно, она есть вроде бы. По кр. мере, я точно знаю, что ДЕ в трёшке что-то делает (или почти сделал) в этом направлении.

я тоже в некоторых местах использую. Но это от бедности. Кстати разве оконные функции не покрывают 50% таких задач? Материализацию промежуточных результатов покроет ещё 15%. Правда есть у меня одна задачка в которой пока заменить GTT никак не удаётся.
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563196
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денися тоже в некоторых местах использую. Но это от бедности. Кстати разве оконные функции не покрывают 50% таких задач?ты про sum()over() и сравнение с ним значений в соседних столбах для последующего фильтра или про что ?

Симонов ДенисМатериализацию промежуточных результатов покроет ещё 15%. Правда есть у меня одна задачка в которой пока заменить GTT никак не удаётся.я видел её, но не вчитывался, по правде сказать. Надо будет глянуть как-нить.
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563212
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидты про sum()over() и сравнение с ним значений в соседних столбах для последующего фильтра или про что ?

да и не только. Жаль пока нету спецификации кадрирования.

ТаблоидСимонов ДенисМатериализацию промежуточных результатов покроет ещё 15%. Правда есть у меня одна задачка в которой пока заменить GTT никак не удаётся.я видел её, но не вчитывался, по правде сказать. Надо будет глянуть как-нить.
на самом деле там упрощённая формулировка, на самом деле там помимо коэффициента надо ещё вывести полную родословную с пометкой всех инбредных лошадей и раскрасить их разными цветами. Я пробовал на досуге решить это с помощью оконных функций, но до конца так и не добил. Да и работало оно медленней, чем с GTT.
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563522
bazilio77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dimitrbazilio77,

во-первых, только при установленных в -1 параметрах MaxUnflushed* в конфиге. Во-вторых, все-таки проигрывает, пусть и немного.
Ви таки будете смеяться.
Оказалось что на том диске где я проводил тесты оказалась включена компрессия NTFS.
Выключил компрессию в каталоге где лежала БД и получил результат равный рамдиску или даже
быстрее 2:17 vs 2.21 на рамдиске.
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563568
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
bazilio77,

а индексация ? :-)
...
Рейтинг: 0 / 0
Еще раз о ramdisk
    #38563585
bazilio77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ariochbazilio77,

а индексация ? :-)
Индексация чего?
...
Рейтинг: 0 / 0
22 сообщений из 47, страница 2 из 2
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Еще раз о ramdisk
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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