ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
25 сообщений из 69, страница 2 из 3
  2  все
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612596
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
unahPLAN JOIN (O NATURAL, S INDEX (PK_SHOPS))

PLAN JOIN (S NATURAL, O INDEX (FK_ORDER_REF_SHOP))



Хоспиди, да при чём тут ПК-не ПК... Азбука, порядок объединения таблиц. Ясен пень перебор большей с подтягиванием элементов меньшей будет тормозней, какой индекс ни используй. Вот почему оптимизатор тройки из-за простой перестановки позиций таблиц и полей в запросе, без волшебной палочки +0, меняет порядок перебора - для меня загадка. Никогда у нас такого не было и вот оно опять?
...
Рейтинг: 0 / 0
09.03.2018, 15:56
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612597
unah
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unah
Гость
Старый плюшевый мишкаХоспиди, да при чём тут ПК-не ПК... Азбука, порядок объединения таблиц. Ясен пень перебор большей с подтягиванием элементов меньшей будет тормозней, какой индекс ни используй.
Результат видели? Перебор большей с подтягиванием элементов меньшей получился быстрее ;)
...
Рейтинг: 0 / 0
09.03.2018, 15:59
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612598
unah
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unah
Гость
unahСтарый плюшевый мишкаХоспиди, да при чём тут ПК-не ПК... Азбука, порядок объединения таблиц. Ясен пень перебор большей с подтягиванием элементов меньшей будет тормозней, какой индекс ни используй.
Результат видели? Перебор большей с подтягиванием элементов меньшей получился быстрее ;)
Я так понимаю, причина в том, что страницы большой таблицы сервер читает последовательно, а маленькая умещается в кешах.

Если ходить по маленькой и присоединять большую, записи большой таблицы будут подтягиваться рандомно из разных страниц, страницы придётся перечитывать.
...
Рейтинг: 0 / 0
09.03.2018, 16:13
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612601
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
unahИ напоследок. Отношения многие-ко-многим.
Мастер-сущность в таблице с 30 млн. записей, Detail - 3 млн. записей и линков между ними - более 300 млн (отдельная таблица со ссылками на master и detail для каждой связи, всё по лучшим практикам).
И вот как раз join к таблице links стал захлёбываться (потому что не по unique index?).Какая глубина индекса по большой таблице?

unahПросто надо buffers поднимать ))) Кто-ж знал )))Теперь же знаешь, вот и поднимай. :)
...
Рейтинг: 0 / 0
09.03.2018, 16:21
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612602
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
unahСтарый плюшевый мишкаХоспиди, да при чём тут ПК-не ПК... Азбука, порядок объединения таблиц. Ясен пень перебор большей с подтягиванием элементов меньшей будет тормозней, какой индекс ни используй.
Результат видели? Перебор большей с подтягиванием элементов меньшей получился быстрее ;)

Упс, упустил момент когда вы count ввели в запрос. Это уже другая история. Это раз. Два - упустил из виду второй азбучный случай. Такой эффект возможен если индекс под FK просто дико плохой для конкретного запроса. Крайний случай - 90% записей в Orders имеют один Shops_ID и отбираются записи именно с ним. В таком случае его надо глушить волшебной палкой, без него будет лучше. А если отбираются остатние 10, то индекс будет просто замечательным. Или в индексе вообще 2-3 равномерно распределённых значения. Тогда его надо глушить просто всегда. И, если предметная область позволяет в смысле конкурентности, то есть, в мастер-таблице не бывает удалений, вообще заменить FK на Check.
...
Рейтинг: 0 / 0
09.03.2018, 16:21
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612607
unah
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unah
Гость
Ivan_PisarevskyКакая глубина индекса по большой таблице?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
    Index FK_LINKS_REF_RECSET (1) 
	Depth: 3, leaf buckets: 127682, nodes: 338547294 
	Average data length: 0.10, total dup: 305812566, max dup: 216 
	Fill distribution: 
	     0 - 19% = 6 
	    20 - 39% = 2 
	    40 - 59% = 2743 
	    60 - 79% = 2 
	    80 - 99% = 124929
...
Рейтинг: 0 / 0
09.03.2018, 16:27
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612611
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
unahСамое простое - загрузка (или любая другая операция) с большим списком сущностей, по которой юзер хочет видеть прогресс.
Тогда первый запрос select Id from ... join ....
узнаём, сколько всего будет строк в результате, а потом выполняем операцию (грузим на клиент) пачками по 100-1000.Мои в этом плане отучены уже требовать прогресс бар. дрессировка, однако. Прогресс бары зло, на них ресурсов надо почти как на само действо. Как правило такая долгоиграющая хрень запускается в отдельном треде(да еще и с обращением к вспомогательному серверу), как отработало, выводит месседж "забирай, милок, свою XML-ку на обычном месте". Работающему в фоне процессу прогресс бар как корове седло.
...
Рейтинг: 0 / 0
09.03.2018, 16:31
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612612
unah
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unah
Гость
в мастер-таблице не бывает удалений, вообще заменить FK на Check.
что именно проверять надо?
...
Рейтинг: 0 / 0
09.03.2018, 16:32
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612614
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
unah
Код: plaintext
1.
Depth: 3

навскидку криминала не заметно, если интересно лучше создать отдельный топик и перетереть, с примерами, планами, статистикой.
...
Рейтинг: 0 / 0
09.03.2018, 16:35
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612616
unah
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unah
Гость
Ivan_PisarevskyМои в этом плане отучены уже требовать прогресс бар. дрессировка, однако. Прогресс бары зло, на них ресурсов надо почти как на само действо
Ну вот ещё причина. Допустим, сервер приложений не умеет делать read-only транзакции, а выборка 8000 объектов (с кучей подгрузок из других таблиц) занимает 10 минут.

В этом случае, быстро получаем список Id документов в одной короткой транзакции (без деталей).
И потом делаем небольшие транзакции, на пару секунд, по 20 документов в пачке.

300 транзакций по 2 секунды лучше, чем одна 10-минутная?
...
Рейтинг: 0 / 0
09.03.2018, 16:38
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612618
unah
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unah
Гость
Ivan_Pisarevskyнавскидку криминала не заметно, если интересно лучше создать отдельный топик и перетереть, с примерами, планами, статистикой.
Сейчас не важно. Понятно, что buffers сильно не хватало.
Было это на FB 2.5 CS, текущий FB 3.0 SS может и справился бы, если увеличить buffers.
Но всё равно, новая денормализованная схема будет быстрее любых join-ов.
...
Рейтинг: 0 / 0
09.03.2018, 16:43
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612632
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Ivan_Pisarevskyнавскидку криминала не заметно

Я не знаю как страницы распределяются по глубине, но у меня впечатление, что в кэш не
влезли даже первых два уровня.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.03.2018, 17:24
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612634
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Старый плюшевый мишкаВот почему оптимизатор тройки из-за простой перестановки позиций таблиц и полей в запросе, без волшебной палочки +0, меняет порядок перебора - для меня загадка. Никогда у нас такого не было и вот оно опять?Это где это ? В этой теме я вижу только разные запросы с разными хинтами +0
...
Рейтинг: 0 / 0
09.03.2018, 17:30
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612635
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
unahFetches from cache = 0Серьёзно ? Откуда это ???
...
Рейтинг: 0 / 0
09.03.2018, 17:31
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612637
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
unahв мастер-таблице не бывает удалений, вообще заменить FK на Check.
что именно проверять надо?

Наличие записи в Sklad при вставке в Order и при изменении в ордере склада.
...
Рейтинг: 0 / 0
09.03.2018, 17:38
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612638
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Dimitry Sibiryakovв кэш не влезли даже первых два уровня.Про кэш выше уже обсудили.
unah300 транзакций по 2 секунды лучше, чем одна 10-минутная?Смотря где и смотря для чего. Для отчетов я выбрал одну транзакцию. Я не ограничен по времени, у меня под рукой сервер на репликации, надо мне чтоб он час рубал запрос - будет час рубать запрос. Такие долгоиграющие сборы запускают только по закрытому периоду, поэтому транзакция рид коммитед, административно не ожидается изменений.
unahНо всё равно, новая денормализованная схема будет быстрее любых join-ов.Очень оптимистичное и неоднозначное заявление.
...
Рейтинг: 0 / 0
09.03.2018, 17:40
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612640
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
hvladСтарый плюшевый мишкаВот почему оптимизатор тройки из-за простой перестановки позиций таблиц и полей в запросе, без волшебной палочки +0, меняет порядок перебора - для меня загадка. Никогда у нас такого не было и вот оно опять?Это где это ? В этой теме я вижу только разные запросы с разными хинтами +0

Исходные запросы. Я зевнул когда добавили count-ы и хинты (и взгрустнул по гистораммам)
...
Рейтинг: 0 / 0
09.03.2018, 17:42
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612643
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Старый плюшевый мишка,

гистрограммы джойнам не помогут
...
Рейтинг: 0 / 0
09.03.2018, 17:50
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612644
unah
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unah
Гость
hvladunahFetches from cache = 0Серьёзно ? Откуда это ???
Похоже, IBExpert перестал показывать.
В mon-таблицах всё честно:
Код: sql
1.
select io.MON$PAGE_FETCHES from MON$IO_STATS io join MON$TRANSACTIONS tr on tr.MON$STAT_ID=io.MON$STAT_ID where tr.MON$TRANSACTION_ID=current_transaction


2511127
...
Рейтинг: 0 / 0
09.03.2018, 17:51
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612647
unah
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unah
Гость
Старый плюшевый мишкаНаличие записи в Sklad при вставке в Order и при изменении в ордере склада.
Я думал, какой check constraint предлагаете...
Видимо, подразумевалось заменить foreign key на index.
...
Рейтинг: 0 / 0
09.03.2018, 17:57
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612649
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Старый плюшевый мишкаhvladСтарый плюшевый мишкаВот почему оптимизатор тройки из-за простой перестановки позиций таблиц и полей в запросе, без волшебной палочки +0, меняет порядок перебора - для меня загадка. Никогда у нас такого не было и вот оно опять?Это где это ? В этой теме я вижу только разные запросы с разными хинтами +0
Исходные запросы. Я зевнул когда добавили count-ы и хинты (и взгрустнул по гистораммам)Если это 21245947 исходные запросы, то хинты там уже были :)
Ну что - ложная тревога ? :)
...
Рейтинг: 0 / 0
09.03.2018, 18:00
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612650
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
unahПохоже, IBExpert перестал показывать.Если так, то нужно сообщить Александру
...
Рейтинг: 0 / 0
09.03.2018, 18:01
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612666
unah
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unah
Гость
hvladunahПохоже, IBExpert перестал показывать.Если так, то нужно сообщить Александру

Я потестил немного... Проблема не в IBExpert.

Берём gds32.dll от FB 2.6, кладём в IBExpert - fetches показывает (естественно, на FB 2.5, к 3.0 не коннектится).

Но любая 32-битная fbclient.dll от тройки (начиная с беты до последнего снепшота 3.0.4) или четвёрки (4.0.0.918) приводит к тому, что fetches=0, что при подключении к FB3, что к FB2.5

Версия IBExpert любая - 2015, 2017, 2018

Как бы эти fetches и не нужны вовсе. Убрать их, чтобы не смущали.
...
Рейтинг: 0 / 0
09.03.2018, 19:29
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612668
unah
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
unah
Гость
unahот FB 2.6
от 2.5.6
...
Рейтинг: 0 / 0
09.03.2018, 19:52
| Ответить | Цитировать | Написать  
Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
    #39612669
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
unah,

я те уберу
...
Рейтинг: 0 / 0
09.03.2018, 19:59
| Ответить | Цитировать | Написать  
25 сообщений из 69, страница 2 из 3
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Вебинар: Firebird 3.0 - оптимизатор и расширенные планы запросов
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39612618&tid=1561165]:
 0ms
get settings:
 10ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 62ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 67ms
get tp. blocked users:
 1ms
others: 311ms
total:  488ms
созд. / загр.: 488ms
x
x
Закрыть


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