|
|
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
dimitrВыкинет твой волшебный инсерт все конкурентные сортировки в своп и придут по твою душу злые клиенты и/или админы. Будешь им рассказывать про новые времена и свой подход к дешевым гигабайтам.Они и так придут, если я не выставлю адекватный TempCacheLimit, а не эти нищебродские 64 Мб :-) И, кстати: а ведь можно ввести такой параметр, как максимальная квота использования TempSpace одним аттачем ? Тогда ко мне в комнату точно никто не придёт с б/битой. Кажеццо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:29:52 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидhvladЗа контроль уникальности я даже не заикаюсь.Я вёл речь только об insert'ахА их что - не надо контролировать ? А что делать параллельным коннектам, которые тоже что-то вставляют ? ТаблоидЕсли же прога написана так, что делает insert'ы недопустимых дубликатов - разраб ССЗБ, пусть переписывает на merge.Так и сделаем - введём новый код ошибки isc_app_dev_is_a_fool и будем её возвращать. Всегда. ТаблоидРезультат теста предсказуем и не интересен, но пусть будет как аргумент.С этим у тебя всегда проблемы. Твой тест не отражает реальности. Ибо при построении индекса применяется совсем не дакой алгоритм, как при добавлении ключей в индекс (пусти и пачки). И вернёмся к начальному вопросу: ТаблоидhvladА что такое "входной поток" ? Где он начинается и где заканчивается ?эммм... ну вот когда движок начинает делать вот такое: Код: sql 1. - то разве он не "чувствует", когда заканчиваются данные из источника ?А теперь найди этот вот Код: sql 1. в своём предсказуемом и не интересном (полностью согласен!) тесте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:32:15 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид, отложенные индексы - бред. Я ещё понимаю если бы ты отложенных FK требовал. И чего ты так к этим GTT доматался? Если ты их используешь только для оптимизации выборок, то может лучше просить фич оптимизатора? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:45:40 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидпропущено...Я вёл речь только об insert'ахА их что - не надо контролировать ? А что делать параллельным коннектам, которые тоже что-то вставляют ?куда, в GTT ? (разговор только о времянках!) hvladТвой тест не отражает реальности. Ибо при построении индекса применяется совсем не дакой алгоритм, как при добавлении ключей в индекс (пусти и пачки).я знаю, что там всё по-другому; но сравнить, хотя бы с точностью два лаптя, - как еще ? hvladА теперь найди этот вот Код: sql 1. в своём предсказуемом и не интересном (полностью согласен!) тестекогда 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. 3.2 млн строк, immediate index update: 285 sec Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. PS. у Cтаршего Брата много лет существует deferred constraints , проверяемые при commit'e транзакции (даже не по окончаниии стейтмента). Сильно подозреваю, что индексы, которыми обеспечиваются эти самые deferred-констрейнты (UK/FK), также обновляются в самом заду, не сразу. А также (как минимум с 11.1.0) - deferred index maintenance - судя по тексту, это как раз то самое , "с ключиками в памяти". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:08:27 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Симонов Денисотложенные индексы - бред.Обоснуй. Симонов ДенисЯ ещё понимаю если бы ты отложенных FK требовал. И чего ты так к этим GTT доматался? Если ты их используешь только для оптимизации выборок, то может лучше просить фич оптимизатора?Использую, и не я один. Запрос такой фичи оптимизатора (материализацию промежуточных результатов) делать не нужно, она есть вроде бы. По кр. мере, я точно знаю, что ДЕ в трёшке что-то делает (или почти сделал) в этом направлении. Но GTT'шки юзаются не только для ускорения джойнов. Например, загрузить из файла прайс-лист поставщика с предпросмотром его перед окончательным импортом. Там может быть 1...2 млн строк (речь о запчастях), юзера могут выполнять в нём поиск, всякие модификации цен, скидочных категорий и проч. Джойнов тут нет вообще. Надо просто загрузить его побыстрее и проиндексировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:13:25 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидPS. у Cтаршего Брата много лет существует deferred constraints , проверяемые при commit'e транзакции (даже не по окончаниии стейтмента). Сильно подозреваю, что индексы, которыми обеспечиваются эти самые deferred-констрейнты (UK/FK), также обновляются в самом заду, не сразу. с чего ты взял, что deferred constraints будут работать быстрее чем построчные? Да и применяются они не для скорости, а именно чтобы отложить проверку, что как бы следует из названия. Что касается ускорения загрузки (insert), то тут лучше бы ты просил bulk insert. По-моему даже в трекере где-то есть insert со множественным values. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:29:08 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисЧто касается ускорения загрузки (insert), то тут лучше бы ты просил bulk insert. По-моему даже в трекере где-то есть insert со множественным values. Array DML было бы эффективнее. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:31:58 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид(разговор только о времянках!)Это ты так думаешь Таблоидя знаю, что там всё по-другому; но сравнить, хотя бы с точностью два лаптя, - как еще ?Ты делаешь утверждения - ты их обосновываешь. Пока что твои обоснования не выдерживают критики Таблоиду Cтаршего Брата много лет существуетЯ знаю. Но у него много чего ещё существует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:39:28 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Симонов Денисс чего ты взял, что deferred constraints будут работать быстрее чем построчные? Да и применяются они не для скорости, а именно чтобы отложить проверку, что как бы следует из названия.я знаю, что они для откладывания проверки. Скорость не сравнивал, в лом. А второй ссылки, про deferred index maintenance, разве не достаточно, чтобы просто обратить внимание на это ? Симонов ДенисЧто касается ускорения загрузки (insert), то тут лучше бы ты просил bulk insert. По-моему даже в трекере где-то есть insert со множественным values.а что ты вкладываешь в эту фразу, bulk insert ? что при этом должно/ не должно происходить ? ЗЫ. тикета не вижу; есть только фикс регресса, недавний. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:40:49 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, ну или это Таблоид, подозреваю что вот это deferred constraints требует блокировки. Да и часто ли ты их применял в ORA. Лично я вижу их пользу только для отложенных FK, да и то только для случая когда в таблицу запихивается древовидная структура и не возможно вставить какую либо запись до вставки её родителя. В остальных случаях порядок вставки всегда можно определить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:41:38 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
hvladТы делаешь утверждения - ты их обосновываешь. Пока что твои обоснования не выдерживают критики.ну, а как еще сравнивать-то ? при отсутствии чего-то типа "обнови индекс только по добавленным строкам" ? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:44:04 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Симонов Денис CORE-1978 как по мне так это часть CORE-3880 Это не bulk insert, а именно "конструктор" с заранее известными числами внутри values(). Просто что бы не ходить на поклон к rdb$database. Индексы по-прежнему будут обновляться для каждой добавляемой записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:47:56 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид, я тут только об уменьшении кол-ва round-trip на массовых вставках и это полезно не только для GTT. Про индексы я тут не говорил. Что касается именно отложенных констрейнов, то тебе уже говорили, что если и делать, то для всех таблиц, а не только для GTT. А это куда сложнее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:51:55 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидhvladТы делаешь утверждения - ты их обосновываешь. Пока что твои обоснования не выдерживают критики.ну, а как еще сравнивать-то ? Проблемы индейцев ... (ц) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:53:21 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидпропущено...ну, а как еще сравнивать-то ? Проблемы индейцев ... (ц)дежурно-казённая отговорка :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:58:26 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидИспользую, и не я один. Запрос такой фичи оптимизатора (материализацию промежуточных результатов) делать не нужно, она есть вроде бы. По кр. мере, я точно знаю, что ДЕ в трёшке что-то делает (или почти сделал) в этом направлении. я тоже в некоторых местах использую. Но это от бедности. Кстати разве оконные функции не покрывают 50% таких задач? Материализацию промежуточных результатов покроет ещё 15%. Правда есть у меня одна задачка в которой пока заменить GTT никак не удаётся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 15:33:58 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Симонов Денися тоже в некоторых местах использую. Но это от бедности. Кстати разве оконные функции не покрывают 50% таких задач?ты про sum()over() и сравнение с ним значений в соседних столбах для последующего фильтра или про что ? Симонов ДенисМатериализацию промежуточных результатов покроет ещё 15%. Правда есть у меня одна задачка в которой пока заменить GTT никак не удаётся.я видел её, но не вчитывался, по правде сказать. Надо будет глянуть как-нить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 15:41:09 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоидты про sum()over() и сравнение с ним значений в соседних столбах для последующего фильтра или про что ? да и не только. Жаль пока нету спецификации кадрирования. ТаблоидСимонов ДенисМатериализацию промежуточных результатов покроет ещё 15%. Правда есть у меня одна задачка в которой пока заменить GTT никак не удаётся.я видел её, но не вчитывался, по правде сказать. Надо будет глянуть как-нить. на самом деле там упрощённая формулировка, на самом деле там помимо коэффициента надо ещё вывести полную родословную с пометкой всех инбредных лошадей и раскрасить их разными цветами. Я пробовал на досуге решить это с помощью оконных функций, но до конца так и не добил. Да и работало оно медленней, чем с GTT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 15:48:18 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
dimitrbazilio77, во-первых, только при установленных в -1 параметрах MaxUnflushed* в конфиге. Во-вторых, все-таки проигрывает, пусть и немного. Ви таки будете смеяться. Оказалось что на том диске где я проводил тесты оказалась включена компрессия NTFS. Выключил компрессию в каталоге где лежала БД и получил результат равный рамдиску или даже быстрее 2:17 vs 2.21 на рамдиске. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 18:36:03 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77, а индексация ? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:07:01 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38563053&tid=1563883]: |
0ms |
get settings: |
9ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
436ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
| others: | 232ms |
| total: | 755ms |

| 0 / 0 |
