ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Навигация по индексу FB3
19 сообщений из 19, страница 1 из 1
Навигация по индексу FB3
    #38821824
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Поскольку Beta уже вышла можно про оптимизатор спрашивать.

Имеем такой запрос:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT
    SERVICE.CODE_SERVICE,
    WEBUSER.LOGIN
FROM
    SERVICE
JOIN WEBUSER ON SERVICE.CODE_WEBUSER = WEBUSER.CODE_WEBUSER
--WHERE WEBUSER.LOGIN = 'Abrek'
ORDER BY SERVICE.BYDATE
ROWS 1



 
План и статистика в Fb3
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
План
PLAN JOIN (SERVICE ORDER SERVICE_IDX_BYDATE, WEBUSER INDEX (PK_WEBUSER))

Select Expression
    -> First N Records
        ->  Nested Loop Join (inner)
            -> Table "SERVICE" Access By ID
                -> Index "SERVICE_IDX_BYDATE" Full Scan
            -> Filter
                -> Table "WEBUSER" Access By ID
                    -> Bitmap
                        -> Index "PK_WEBUSER" Unique Scan

------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 16ms
Среднее время на получение одной записи = 16,00 ms
Current memory = 140 557 976
Max memory = 143 829 864
Memory buffers = 8 192
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 50


В Fb2.5 понятное дело всё плохо:

 
План и статистика в Fb2.5
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
План
PLAN SORT (JOIN (WEBUSER NATURAL, SERVICE INDEX (FK_SERVICE_REF_WEBUSER)))

------ Информация о производительности ------
Время подготовки запроса = 16ms
Время выполнения запроса = 4m 7s 246ms
Среднее время на получение одной записи = 247 246,00 ms
Current memory = 17 704 596
Max memory = 268 172 356
Memory buffers = 1 024
Reads from disk to cache = 288 355
Writes from cache to disk = 0
Чтений из кэша = 24 059 934


Но только стоит разкомментировать условие WHERE WEBUSER.LOGIN = 'Abrek', получаем всё наоборот:

 
План и статистика в Fb3
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
План
PLAN JOIN (SERVICE ORDER SERVICE_IDX_BYDATE, WEBUSER INDEX (PK_WEBUSER))

Select Expression
    -> First N Records
        ->  Nested Loop Join (inner)
            -> Table "SERVICE" Access By ID
                -> Index "SERVICE_IDX_BYDATE" Full Scan
            -> Filter
                -> Table "WEBUSER" Access By ID
                    -> Bitmap
                        -> Index "PK_WEBUSER" Unique Scan

------ Информация о производительности ------
Время подготовки запроса = 16ms
Время выполнения запроса = 2s 730ms
Среднее время на получение одной записи = 2 730,00 ms
Current memory = 141 176 288
Max memory = 143 829 864
Memory buffers = 8 192
Reads from disk to cache = 18 708
Writes from cache to disk = 0
Чтений из кэша = 2 982 836



 
План и статистика в Fb2.5
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
План
PLAN SORT (JOIN (WEBUSER INDEX (UNQ_WEBUSER_LOGIN), SERVICE INDEX (FK_SERVICE_REF_WEBUSER)))

------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 31ms
Среднее время на получение одной записи = 31,00 ms
Current memory = 17 719 212
Max memory = 268 172 356
Memory buffers = 1 024
Reads from disk to cache = 474
Writes from cache to disk = 0
Чтений из кэша = 6 350


Изменяем запрос на такой

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT
    SERVICE.CODE_SERVICE,
    WEBUSER.LOGIN
FROM
    SERVICE
JOIN WEBUSER ON SERVICE.CODE_WEBUSER = WEBUSER.CODE_WEBUSER
WHERE WEBUSER.LOGIN = 'Abrek'
ORDER BY SERVICE.BYDATE+0
ROWS 1



и получаем в FB3

 
Код: 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.
План
PLAN SORT (JOIN (WEBUSER INDEX (UNQ_WEBUSER_LOGIN), SERVICE INDEX (FK_SERVICE_REF_WEBUSER)))

Select Expression
    -> First N Records
        -> Sort (record length: 92, key length: 12)
            ->  Nested Loop Join (inner)
                -> Filter
                    -> Table "WEBUSER" Access By ID
                        -> Bitmap
                            -> Index "UNQ_WEBUSER_LOGIN" Unique Scan
                -> Filter
                    -> Table "SERVICE" Access By ID
                        -> Bitmap
                            -> Index "FK_SERVICE_REF_WEBUSER" Range Scan (full match)

------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 46ms
Среднее время на получение одной записи = 46,00 ms
Current memory = 140 579 832
Max memory = 143 829 864
Memory buffers = 8 192
Reads from disk to cache = 496
Writes from cache to disk = 0
Чтений из кэша = 6 373


Т.е. трёшка не понимает, когда надо отказаться от навигации по индексу, а когда нет. Причём без ограничителя ROWS оценка идёт правильно и навигация по индексу заменяется внешней сортировкой.
...
Рейтинг: 0 / 0
01.12.2014, 19:23
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38821937
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ROWS считается хинтом и отключает оценку стоимости в пользу принудительного использования плана ORDER. Как видим, это не всегда является удачной мыслью.
...
Рейтинг: 0 / 0
01.12.2014, 20:48
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822057
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
dimitr,

это я уже понял. Просто думал может к релизу планируются изменения на этот счёт.

Ещё хотел спросить. Если в плане будет отображаться стоимостная оценка и кардинальность, то можно для индексов писать ещё и селективность? Если эти сведения будут проще понять почему оптимизатор выбрал именно такой план. Тем более что селективность самого индекса верна только для равенства, а для остальных сравнений используются некоторые константы, вот пусть они и выводятся.
...
Рейтинг: 0 / 0
01.12.2014, 23:52
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822065
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Симонов Денис> в плане ... можно для индексов писать ещё и селективность?

Кстати, да, интересная идея, +1. При чём не только из-за
констант и пр., но и поскольку селективность меняется.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
02.12.2014, 00:33
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822071
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkMaster
Участник
Симонов Денис,

Кстати, вопрос светочам (бо неуч, каюсь - 3 сервера в голове удержать одновременно ;( ) - селективность индекса пересчитывается когда?
...
Рейтинг: 0 / 0
02.12.2014, 01:16
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822072
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
DarkMaster,

при alter index active (включая restore), и set statistics index ...
...
Рейтинг: 0 / 0
02.12.2014, 01:25
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822074
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
DarkMasterселективность индекса пересчитывается когда?1) при вводе create index ... on ...
2) при вводе set statistics index ...

Селективность НЕ пересчитывается, если сначала индекс создать, а затем заливать в таблицу данные. Поэтому после всяких bulk-апдейтов (или просто на периодической основе) надо делать set statictics index, если не хотим огрести тормоза на неверных планах с inner-join'ами. Операция эта не требует отрубания юзеров.
...
Рейтинг: 0 / 0
02.12.2014, 01:26
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822095
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkMaster
Участник
kdv, Таблоид - спасибо, в очередной раз внесли ясность...

Вдогодку - есть ли смысл (для компонент) на автомате генерить SET STATISTICS после заведомо больших порций данных, влитых через скрипт (ими же исполненный) и где (примерно) эта магическая граница для больших порций (есть кое-какая задумка, но пока в плане прикидок - стоит оно или нет)...
...
Рейтинг: 0 / 0
02.12.2014, 02:55
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822108
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
DarkMaster> есть ли смысл (для компонент)

Чего-чего?

DarkMaster> генерить SET STATISTICS после заведомо больших порций данных,
DarkMaster> влитых через скрипт (ими же исполненный)

Есть. Зависит от соотношения новых данных
к старым и содержания индексируемых полей.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
02.12.2014, 04:29
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822224
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
DarkMasterгде (примерно) эта магическая граница для больших порцийОгребание тормозов на запросах, которые раньше летали - вот и вся "магическая граница" :-)
Создай скриптик, который будет делать 5-6 запросов к твоей базе, и "фоткать" время их выполнения до и после.
Запросы должны быть не вымученными, а такими, которые часто используются, ну и достаточно "тяжелыми". В запросах обязательно должны быть inner join'ы тех таблиц, которые сейчас менялись. Т.е. такие должны быть места, на которых оптимизатор будет делать выбор .
Ну, и пусть твой скрипт сравнивает время. Если оно отличается на 25% и более - этот же скрипт пусть и пересчитывает статистику. ИМХО.
...
Рейтинг: 0 / 0
02.12.2014, 10:21
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822232
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
PS. А вообще, пересчет статистики - очень быстрая операция. Даже на больших таблицах и при сотнях работающих роботах. Не говоря уже про работу обычных юзеров. Так что нет смысла заморачиваться, скажу шершавым языком агитпропа: "залил - пересчитывай!"
...
Рейтинг: 0 / 0
02.12.2014, 10:25
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822235
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkMaster
Участник
Гаджимурадов РустамDarkMaster> есть ли смысл (для компонент)
Чего-чего?


IBO ;)
...
Рейтинг: 0 / 0
02.12.2014, 10:26
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822240
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkMaster
Участник
Таблоид,

Ну ты у нас известный нагибатор ;) Спасибо за информацию... Правда не думаю, что что-то придумается универсальное ;(
...
Рейтинг: 0 / 0
02.12.2014, 10:28
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822278
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> Ну, и пусть твой скрипт сравнивает время. Если оно отличается на
Таблоид> 25% и более - этот же скрипт пусть и пересчитывает статистику.

Сколько букв, ппц, время, скрипт, сравни...
Правило собсно простое - если заливаешь
больше 25% неравнораспределённых данных -
можно уже пересчитывать. Дотошные могут
уменьшить цифру до 20%, 15%.

DarkMaster> IBO ;)

Да хоть IBX. При чём тут статистика индексов? :)
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
02.12.2014, 11:00
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822312
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Гаджимурадов РустамДа хоть IBX. При чём тут статистика индексов? :)
насколько я понял, речь про допилить компоненты для автоматического обновления статистики после массовой заливки
...
Рейтинг: 0 / 0
02.12.2014, 11:27
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822330
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkMaster
Участник
dimitrГаджимурадов РустамДа хоть IBX. При чём тут статистика индексов? :)
насколько я понял, речь про допилить компоненты для автоматического обновления статистики после массовой заливки

Абсолютно верно.
...
Рейтинг: 0 / 0
02.12.2014, 11:34
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822347
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Какой ужас... Мне бы такое в голову не пришло. :)
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
02.12.2014, 11:48
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38822997
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Приурочить к штатному свипу-бэкапу ночером не судьба?
...
Рейтинг: 0 / 0
02.12.2014, 19:58
| Ответить | Цитировать | Написать  
Навигация по индексу FB3
    #38823069
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkMaster
Участник
Ivan_Pisarevsky,

Да без проблем - так оно и крутится сейчас. Просто например в моем зоопарке пару раз в месяц в базу влетает порядка 1 млн. записей - в остальном штатная работа пользователей без массовых операций аплейта/делита Вот и пришла идея совместить в том же роботе,что данные вливает еще и перестройку индексов при необходимости.
...
Рейтинг: 0 / 0
02.12.2014, 22:30
| Ответить | Цитировать | Написать  
19 сообщений из 19, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Навигация по индексу FB3
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&fpage=84&tid=1563160]:
 0ms
get settings:
 11ms
get forum list:
 20ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 88ms
get topic data:
 14ms
get forum data:
 4ms
get page messages:
 73ms
get tp. blocked users:
 2ms
others: 253ms
total:  473ms
созд. / загр.: 473ms
x
x
Закрыть


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