SQLRU.net
Разработка приложений баз данных

Начало » Использование СУБД » Firebird, HQbird, InterBase » FB 5.0 Производительность, оптимизация
FB 5.0 Производительность, оптимизация [сообщение #4716] Thu, 28 March 2024 15:19 Переход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
Вот такая фигня.

Оптимизация заключалась в выкидывании из запроса мастер таблицы, т.к. в след. джойне было условие 1:1 по FK
подготовка данных - заливка во временные таблицы - 18 сек. одинаково.

выборка из временных таблиц - через execute stmt

"FB50 not Optimized"
"FB50  Optimized"
"FB25 not Optimized"
"FB25 Optimized"
Re: FB 5.0 Производительность, оптимизация [сообщение #4717 является ответом на сообщение #4716] Thu, 28 March 2024 15:24 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
Гм... это что ? Приглашение посмотреть на чёрный ящик ? Smile
Зачем нам знать сколько записей в куда вошло, если этот процесс везде одинаковый ?
Может начать с планов запросов выборки и их статистики ?
Re: FB 5.0 Производительность, оптимизация [сообщение #4718 является ответом на сообщение #4717] Thu, 28 March 2024 15:33 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
пишу (с) Smile
Re: FB 5.0 Производительность, оптимизация [сообщение #4719 является ответом на сообщение #4718] Thu, 28 March 2024 15:58 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
какая-то мистика

иду по всем статментам - везде быстрее
Re: FB 5.0 Производительность, оптимизация [сообщение #4720 является ответом на сообщение #4717] Thu, 28 March 2024 16:26 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
Не самый оптимальный
От повтора запуска статистикак не меняется

select sum( cast(f.FACT_VALUE as numeric(15,2)))
                             from TMP$ITEMS i
                                  join TMP$VALUES v0 on v0.ID_ITEM = i.ID  and v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                  join TMP$VALUES v7 on v7.ID_ITEM = i.ID and v7.ID_ATTRIBUTE = 7  -- код
                                  join TMP$VALUES vG on vG.ID_ITEM = i.ID and vG.ID_ATTRIBUTE = 13
                                  join TMP$FACTS f on f.ID_ITEM = i.ID
                              where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                    and v7.ATTRIBUTE_VALUE = :S7
                                    and vG.ATTRIBUTE_VALUE = :S13
                                    and f.ID_DIMENSION = :ID_PAY

План
--------------------------------------------------------------------------------
PLAN JOIN (F INDEX (TMP$FACTS_DIMENSION), I INDEX (TMP$ITEMS), V0 INDEX (TMP$VALUES), V7 INDEX (TMP$VALUES), VG INDEX (TMP$VALUES))

------ Performance info ------
Prepare time = 0ms
Execute time = 31ms
Avg fetch time = 31,00 ms
Current memory = 1 691 251 696
Max memory = 1 787 191 552
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 81 104
Оптимальный

select sum( cast(f.FACT_VALUE as numeric(15,2)))
                             from -- TMP$ITEMS i
                                  --join TMP$VALUES v0 on v0.ID_ITEM = i.ID  and v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                  TMP$VALUES v0
                                  join TMP$VALUES v7 on v7.ID_ITEM = v0.ID_ITEM and v7.ID_ATTRIBUTE = 7  -- код
                                  join TMP$VALUES vG on vG.ID_ITEM = v0.ID_ITEM and vG.ID_ATTRIBUTE = 13
                                  join TMP$FACTS f on f.ID_ITEM = v0.ID_ITEM
                              where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                    and v7.ATTRIBUTE_VALUE = :S7
                                    and vG.ATTRIBUTE_VALUE = :S13
                                    and f.ID_DIMENSION = :ID_PAY

Первый пуск

План
--------------------------------------------------------------------------------
PLAN JOIN (F INDEX (TMP$FACTS_DIMENSION), V0 INDEX (TMP$VALUES), V7 INDEX (TMP$VALUES), VG INDEX (TMP$VALUES))

------ Performance info ------
Prepare time = 0ms
Execute time = 31ms
Avg fetch time = 31,00 ms
Current memory = 1 691 251 792
Max memory = 1 787 191 552
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 61 484

Повторный пуск

План
--------------------------------------------------------------------------------
PLAN JOIN (F INDEX (TMP$FACTS_DIMENSION), V0 INDEX (TMP$VALUES), V7 INDEX (TMP$VALUES), VG INDEX (TMP$VALUES))

------ Performance info ------
Prepare time = 0ms
Execute time = 16ms
Avg fetch time = 16,00 ms
Current memory = 1 691 251 792
Max memory = 1 787 191 552
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 61 484


Таблицы временные, какой там план внутри процедуры - пес его знает.

вызывается так

for execute statement (PSQL) (S13:=:S13, S7:=:S7, ID_PAY:=:ID_PAY, OPER:=OPER)
                                                             into :M17
Re: FB 5.0 Производительность, оптимизация [сообщение #4721 является ответом на сообщение #4720] Thu, 28 March 2024 16:42 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 332
Зарегистрирован: June 2022
Senior Member
Ты по пустым таблицам что ли планы и статистику приводишь?

Как выводить внутренние планы процедур в 5-ке я тебе могу подсказать. Но не когда они в ES.

Зачем делать cast внутри суммы?
Re: FB 5.0 Производительность, оптимизация [сообщение #4724 является ответом на сообщение #4720] Fri, 29 March 2024 00:45 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
Я правильно понимаю, что есть некая процедура, которая в числе прочего вызывает с помощью EXEC STMT вышеуказанные запросы ?
И эти запросы в 5 выполняются не медленнее, чем в 2.5 ?
Т.е. всё сводится к процедуре, план которой для 5 не известен ?
План процедуры можно увидеть в MON$COMPILED_STATEMENTS, см например, тут
Re: FB 5.0 Производительность, оптимизация [сообщение #4725 является ответом на сообщение #4724] Fri, 29 March 2024 07:39 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
так точно

1. готовлю воспроизводимую минимальную базу
2. посмотрю. в 2.5 в обычных запросах к временным таблицам внутри SP (в которой они набивались) не подхватывались индексы
было обойдено через ES
3. попробую еще и в редэксперте с профилированием

Re: FB 5.0 Производительность, оптимизация [сообщение #4728 является ответом на сообщение #4724] Fri, 29 March 2024 12:31 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
меняем показания:


порезал код процедуры с 900 строк до 100.

остался последний ES,. тормоз остался Sad

нашел четыре обращения к большим временным таблицам без ES

итого:


1. ES стали работать медленнее

есть две идентичные базы 2.5 и 5.0
в архиве - около 10 мб

прислать?

[Обновления: Fri, 29 March 2024 13:13]

Известить модератора

Re: FB 5.0 Производительность, оптимизация [сообщение #4729 является ответом на сообщение #4721] Fri, 29 March 2024 13:57 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
sim_84 писал(а) Thu, 28 March 2024 16:42
Ты по пустым таблицам что ли планы и статистику приводишь?

Как выводить внутренние планы процедур в 5-ке я тебе могу подсказать. Но не когда они в ES.

Зачем делать cast внутри суммы?
1. нет. в основной таблице 500к + записей
джойнится сама с собой несколько раз

2. Влад подсказал

3. FB не в курсе что лежит в текстовом поле. так надо.
Re: FB 5.0 Производительность, оптимизация [сообщение #4730 является ответом на сообщение #4716] Fri, 29 March 2024 14:04 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
[color=blue]ASQL[/color] = 'select 
                                    v7.ATTRIBUTE_VALUE as CODE,
                                    v8.ATTRIBUTE_VALUE as NAME,
                                    cast(v13.ATTRIBUTE_VALUE as numeric(15,2)) as PRICE,
                                    sum( cast(v14.ATTRIBUTE_VALUE as numeric(15,1))) as AMOUNT--,
                             from 
                                  TMP$VALUES v0
                                  join TMP$VALUES v7 on v7.ID_ITEM = v0.ID_ITEM and v7.ID_ATTRIBUTE = 7  -- код
                                  join TMP$VALUES v8 on v8.ID_ITEM = v0.ID_ITEM and v8.ID_ATTRIBUTE = 8 -- название
                                  join TMP$VALUES v10 on v10.ID_ITEM = v0.ID_ITEM and v10.ID_ATTRIBUTE = 10 -- группа услуг
                                  join TMP$VALUES v13 on v13.ID_ITEM = v0.ID_ITEM and v13.ID_ATTRIBUTE = 13 -- цена
                                  join TMP$VALUES v14 on v14.ID_ITEM = v0.ID_ITEM and v14.ID_ATTRIBUTE = 14 -- кол-во
                             where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                   and v7.ATTRIBUTE_VALUE = :S7
                                   and v10.ATTRIBUTE_VALUE = :S10
                             group by 1, 2, 3
                             order by 1, 2, 3';
вызывается вот так (995 раз)
модельные параметры:

OPER = 'SALE'
S7 = '1003'
S10 = 'Бассейн'



                                           DB = 'NOW';
                                           -- услуги в группировке по коду/имени/цене
                                           CNT_ASQL = CNT_ASQL + 1;
                                           for execute statement (ASQL) (S7:=:S1, S10:=:S10, OPER:=:OPER)
                                               into :S7, :S8, :S13, :S14
                                               do begin
                                                   /*
                                                   STRINGS = (select first 1 s.MON$EXPLAINED_PLAN from MON$COMPILED_STATEMENTS s
                                                   where S.MON$SQL_TEXT containing 'TMP$VALUES');
                                                   suspend;
                                                   */
                                                  end -- услуги в группировке по коду/имени/цене
                                           DE = 'NOW';
                                           STRINGS = '<!-- "'|| :S1|| '" "'|| :S2|| '"  '||datediff( millisecond, DB, DE)||' -->'; suspend;
  

FB50

изнутри процедуры

<!-- "1003" "3083"  130.0 -->


Select Expression
   -> Sort (record length: 2628, key length: 1044)
       -> Aggregate
           -> Refetch
               -> Sort (record length: 1152, key length: 1044)
                   -> Filter
                       -> Hash Join (inner)
                           -> Hash Join (inner)
                               -> Hash Join (inner)
                                   -> Hash Join (inner)
                                       -> Hash Join (inner)
                                           -> Filter
                                               -> Table "TMP$VALUES" as "V0" Access By ID
                                                   -> Bitmap
                                                       -> Index "TMP$VALUES_ATT" Range Scan (full match)
                                           -> Record Buffer (record length: 561)
                                               -> Filter
                                                   -> Table "TMP$VALUES" as "V7" Access By ID
                                                       -> Bitmap
                                                           - > Index "TMP$VALUES_ATT" Range Scan (full match)
                                       -> Record Buffer (record length: 561)
                                           -> Filter
                                               -> Table "TMP$VALUES" as "V8" Access By ID
                                                   -> Bitmap
                                                       -> Index "TMP$VALUES_ATT" Range Scan (full match)
                                   -> Record Buffer (record length: 561)
                                       -> Filter
                                           -> Table "TMP$VALUES" as "V10" Access By ID
                                               -> Bitmap
                                                   -> Index "TMP$VALUES_ATT" Range Scan (full match)
                               -> Record Buffer (record length: 561)
                                   -> Filter
                                       -> Table "TMP$VALUES" as "V13" Access By ID
                                           -> Bitmap
                                               -> Index "TMP$VALUES_ATT" Range Scan (full match)
                           -> Record Buffer (record length: 561)
                               -> Filter
                                   -> Table "TMP$VALUES" as "V14" Access By ID
                                       -> Bitmap
                                           -> Index "TMP$VALUES_ATT" Range Scan (full match)

отдельно, с теми же параметрами

------ Performance info ------
Prepare time = 0ms
Execute time = 172ms
Avg fetch time = 172,00 ms
Current memory = 456 180 224
Max memory = 538 854 576
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 255 640

PLAN SORT (SORT (HASH (HASH (HASH (HASH (HASH (V0 INDEX (TMP$VALUES_ATT), V7 INDEX (TMP$VALUES_ATT)), V8 INDEX (TMP$VALUES_ATT)), V10 INDEX (TMP$VALUES_ATT)), V13 INDEX (TMP$VALUES_ATT)), V14 INDEX (TMP$VALUES_ATT))))

------------------------------------------------------------ --------------------
------------------------------------------------------------ --------------------
------------------------------------------------------------ --------------------

FB25

изнутри процедуры

<!-- "1003" "3083"  85 -->

плана, есс-но нет

отдельно, с теми же параметрами

План
------------------------------------------------------------ --------------------
PLAN SORT (SORT (JOIN (V0 INDEX (TMP$VALUES_AV), V7 INDEX (TMP$VALUES), V8 INDEX (TMP$VALUES), V10 INDEX (TMP$VALUES), V13 INDEX (TMP$VALUES), V14 INDEX (TMP$VALUES))))

------ Performance info ------
Prepare time = 0ms
Execute time = 125ms
Avg fetch time = 125,00 ms
Current memory = 449 807 208
Max memory = 463 328 096
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 285 675
Re: FB 5.0 Производительность, оптимизация [сообщение #4731 является ответом на сообщение #4730] Fri, 29 March 2024 14:45 Переход к предыдущему сообщениюПереход к следующему сообщению
dimitr в настоящее время не в онлайне  dimitr
Сообщений: 18
Зарегистрирован: July 2022
Junior Member
А если увеличить InlineSortThreshold в конфиге? до 10К, например?
Re: FB 5.0 Производительность, оптимизация [сообщение #4732 является ответом на сообщение #4730] Fri, 29 March 2024 14:48 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 332
Зарегистрирован: June 2022
Senior Member
Таблицы временные - оптимизатору не известны ни кардинальности, ни нормальные селективности индексов, вот и фигачит везде HASH JOIN.

Если бы таблицы были постоянными у оптимизатора 5-ки было бы выше шансов построить оптимальный план
Re: FB 5.0 Производительность, оптимизация [сообщение #4733 является ответом на сообщение #4731] Fri, 29 March 2024 14:55 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
dimitr писал(а) Fri, 29 March 2024 14:45
А если увеличить InlineSortThreshold в конфиге? до 10К, например?
могу базы предоставить
в них кроме тестовой информации уже ничего нет
Re: FB 5.0 Производительность, оптимизация [сообщение #4734 является ответом на сообщение #4732] Fri, 29 March 2024 14:59 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
sim_84 писал(а) Fri, 29 March 2024 14:48
Таблицы временные - оптимизатору не известны ни кардинальности, ни нормальные селективности индексов, вот и фигачит везде HASH JOIN.

Если бы таблицы были постоянными у оптимизатора 5-ки было бы выше шансов построить оптимальный план
я раз в два года беспокою Влада по этому поводу.
при использовании ES в 2.5 жизнь наладилась

после чесания репы, наладилась еще в 2.5 раза

в 5.0 немножко вернулась взад, на исходную

т.к. сбор отчетов через временные таблицы становится мейнстримом (кубы для нищебродов Smile), то хочется найти пусть и обходное, но решение
Re: FB 5.0 Производительность, оптимизация [сообщение #4735 является ответом на сообщение #4734] Fri, 29 March 2024 15:05 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
pastor писал(а) Fri, 29 March 2024 13:59
sim_84 писал(а) Fri, 29 March 2024 14:48
Таблицы временные - оптимизатору не известны ни кардинальности, ни нормальные селективности индексов, вот и фигачит везде HASH JOIN.

Если бы таблицы были постоянными у оптимизатора 5-ки было бы выше шансов построить оптимальный план
я раз в два года беспокою Влада по этому поводу.
при использовании ES в 2.5 жизнь наладилась

после чесания репы, наладилась еще в 2.5 раза

в 5.0 немножко вернулась взад, на исходную

т.к. сбор отчетов через временные таблицы становится мейнстримом (кубы для нищебродов Smile), то хочется найти пусть и обходное, но решение
А насколько большие эти GTT ?
Re: FB 5.0 Производительность, оптимизация [сообщение #4736 является ответом на сообщение #4735] Fri, 29 March 2024 15:10 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
hvlad писал(а) Fri, 29 March 2024 15:05
pastor писал(а) Fri, 29 March 2024 13:59
sim_84 писал(а) Fri, 29 March 2024 14:48
Таблицы временные - оптимизатору не известны ни кардинальности, ни нормальные селективности индексов, вот и фигачит везде HASH JOIN.

Если бы таблицы были постоянными у оптимизатора 5-ки было бы выше шансов построить оптимальный план
я раз в два года беспокою Влада по этому поводу.
при использовании ES в 2.5 жизнь наладилась

после чесания репы, наладилась еще в 2.5 раза

в 5.0 немножко вернулась взад, на исходную

т.к. сбор отчетов через временные таблицы становится мейнстримом (кубы для нищебродов Smile), то хочется найти пусть и обходное, но решение
А насколько большие эти GTT ?
26 record(s) was(were) inserted into TMP$ATTRIBUTES
26536 record(s) was(were) inserted into TMP$ITEMS
563640 record(s) was(were) inserted into TMP$VALUES
70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
2 record(s) was(were) inserted into TMP$DIMENSIONS
26536 record(s) was(were) inserted into TMP$FACTS

это за месяц
около 1000 проходов - 2.5 минуты на АИ50 и 1 мин на АИ25

за год соответственно 6 млн записей
27 мин и 11 мин соответственно

[Обновления: Fri, 29 March 2024 15:10]

Известить модератора

Re: FB 5.0 Производительность, оптимизация [сообщение #4737 является ответом на сообщение #4736] Fri, 29 March 2024 15:16 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
pastor писал(а) Fri, 29 March 2024 14:10
hvlad писал(а) Fri, 29 March 2024 15:05
А насколько большие эти GTT ?
26 record(s) was(were) inserted into TMP$ATTRIBUTES
26536 record(s) was(were) inserted into TMP$ITEMS
563640 record(s) was(were) inserted into TMP$VALUES
70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
2 record(s) was(were) inserted into TMP$DIMENSIONS
26536 record(s) was(were) inserted into TMP$FACTS

это за месяц
около 1000 проходов - 2.5 минуты на АИ50 и 1 мин на АИ25

за год соответственно 6 млн записей
27 мин и 11 мин соответственно
Ещё один вопрос - сколько времени займёт пересчёт статики для всех индексов TMP$VALUES ?
Re: FB 5.0 Производительность, оптимизация [сообщение #4738 является ответом на сообщение #4736] Fri, 29 March 2024 15:18 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
непонятна разница между выполнением в процедуре и отдельно

FB25
изнутри процедуры

<!-- "1003" "3083"  85 -->

снаружи
Execute time = 125ms
Re: FB 5.0 Производительность, оптимизация [сообщение #4739 является ответом на сообщение #4735] Fri, 29 March 2024 15:20 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 332
Зарегистрирован: June 2022
Senior Member
Покажи какие индексы на TMP$VALUES
Re: FB 5.0 Производительность, оптимизация [сообщение #4740 является ответом на сообщение #4732] Fri, 29 March 2024 15:22 Переход к предыдущему сообщениюПереход к следующему сообщению
SD в настоящее время не в онлайне  SD
Сообщений: 417
Зарегистрирован: August 2022
Senior Member
sim_84 писал(а) Fri, 29 March 2024 12:48
Таблицы временные - оптимизатору не известны ни кардинальности, ни нормальные селективности индексов, вот и фигачит везде HASH JOIN.
Обычно это обходилось одноразовым пересчётом статистики индексов при наполненной временной таблице. Сохранённая селективность индекса после этого получала какое-то значение и с тех пор могла использоваться оптимизатором.

Цитата:
сбор отчетов через временные таблицы становится мейнстримом (кубы для нищебродов), то хочется найти пусть и обходное, но решение
"Кубы для нищебродов" это хранимые агрегаты. Временные таблицы это костыль для MS SQL.
Re: FB 5.0 Производительность, оптимизация [сообщение #4741 является ответом на сообщение #4737] Fri, 29 March 2024 15:25 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 332
Зарегистрирован: June 2022
Senior Member
hvlad писал(а) Fri, 29 March 2024 15:16

Ещё один вопрос - сколько времени займёт пересчёт статики для всех индексов TMP$VALUES ?
А что на временной таблице можно пересчитать статистику индексов и использовать её в той же транзакции?

Теоретически на ON COMMIT PRESERVE ROWS можно в разных транзакциях сделать заливку, пересчёт статистики и сам запрос.
Но в ON COMMIT DELETE ROWS, да ещё в той же транзакции/блоке это вообще реально?
Re: FB 5.0 Производительность, оптимизация [сообщение #4742 является ответом на сообщение #4737] Fri, 29 March 2024 15:25 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
hvlad писал(а) Fri, 29 March 2024 15:16
Ещё один вопрос - сколько времени займёт пересчёт статики для всех индексов TMP$VALUES ?
сделать в ES? в отдельной транзакции?

on commit delete rows

set statistics index TMP$VALUES

------ Performance info ------
Prepare time = 16ms
Execute time = 0ms
Current memory = 454 119 088
Max memory = 538 743 520
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 32
Re: FB 5.0 Производительность, оптимизация [сообщение #4743 является ответом на сообщение #4742] Fri, 29 March 2024 15:29 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 332
Зарегистрирован: June 2022
Senior Member
pastor, индексы то покажи какие есьт для TMP$VALUES
Re: FB 5.0 Производительность, оптимизация [сообщение #4744 является ответом на сообщение #4739] Fri, 29 March 2024 15:30 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
create global temporary table TMP$VALUES(
ID_ITEM ZLS$FK,
ID_ATTRIBUTE ZLS$FK,
ATTRIBUTE_VALUE ZLS$COMMENT,
constraint TMP$VALUES
 primary key(ID_ITEM, ID_ATTRIBUTE),
constraint TMP$VALUES_ITEM
 foreign key (ID_ITEM)
 references TMP$ITEMS (ID)
 on delete CASCADE,
constraint TMP$VALUES_ATT
 foreign key (ID_ATTRIBUTE)
 references TMP$ATTRIBUTES (ID)
 on delete CASCADE

)
on commit delete rows
^
commit^
comment on table TMP$VALUES is 'Значения атрибутов экземпляра # !'^
comment on column TMP$VALUES.ID_ITEM is 'Экземпляр'^
comment on column TMP$VALUES.ID_ATTRIBUTE is 'Атрибут'^
comment on column TMP$VALUES.ATTRIBUTE_VALUE is 'Значение атрибута'^
comment on index TMP$VALUES is 'Первичный ключ'^
comment on index TMP$VALUES_ITEM is 'Экземпляр'^
comment on index TMP$VALUES_ATT is 'Атрибут'^

create index TMP$VALUES_AV
on TMP$VALUES( ID_ATTRIBUTE, ATTRIBUTE_VALUE)

^
comment on index TMP$VALUES_AV is 'Значения атрибутов'^
Re: FB 5.0 Производительность, оптимизация [сообщение #4745 является ответом на сообщение #4737] Fri, 29 March 2024 15:33 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
hvlad писал(а) Fri, 29 March 2024 15:16

Ещё один вопрос - сколько времени займёт пересчёт статики для всех индексов TMP$VALUES ?
DB = 'NOW';
execute statement('set statistics index TMP$VALUES');
DE = 'NOW';
STRINGS = '<!-- set statistics index TMP$VALUES '||datediff( millisecond, DB, DE)||' -->'; suspend;

результат

('<!-- sales facts [26450] 181.0 -->');
('<!-- returns facts [86] 164.0 -->');
('<!-- set statistics index TMP$VALUES 0.0 -->');
('<!-- "1003 135.0ms -->');
Re: FB 5.0 Производительность, оптимизация [сообщение #4746 является ответом на сообщение #4742] Fri, 29 March 2024 15:44 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
pastor писал(а) Fri, 29 March 2024 14:25
hvlad писал(а) Fri, 29 March 2024 15:16
Ещё один вопрос - сколько времени займёт пересчёт статики для всех индексов TMP$VALUES ?
сделать в ES? в отдельной транзакции?

on commit delete rows
Тогда в отдельной тр-ции нет смысла. Как и в ES


pastor
set statistics index TMP$VALUES

------ Performance info ------
Prepare time = 16ms
Execute time = 0ms
Current memory = 454 119 088
Max memory = 538 743 520
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 32
Статистика пересчитывается по коммиту, т.е. тут нужно в *одной* тр-ции:
- наполнить GTT данными
- выполнить SET STATS для каждого интересующего нас индекса
- выполнить коммит и смотреть на его ран-тайм статистику
Re: FB 5.0 Производительность, оптимизация [сообщение #4747 является ответом на сообщение #4733] Fri, 29 March 2024 15:44 Переход к предыдущему сообщениюПереход к следующему сообщению
dimitr в настоящее время не в онлайне  dimitr
Сообщений: 18
Зарегистрирован: July 2022
Junior Member
pastor писал(а) Fri, 29 March 2024 14:55
dimitr писал(а) Fri, 29 March 2024 14:45
А если увеличить InlineSortThreshold в конфиге? до 10К, например?
могу базы предоставить
а давай
Re: FB 5.0 Производительность, оптимизация [сообщение #4748 является ответом на сообщение #4747] Fri, 29 March 2024 15:50 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
select
                                   v7.ATTRIBUTE_VALUE as CODE,
                                   v8.ATTRIBUTE_VALUE as NAME,
                                   cast(v13.ATTRIBUTE_VALUE as numeric(15,2)) as PRICE,
                                   sum( cast(v14.ATTRIBUTE_VALUE as numeric(15,1))) as AMOUNT--,
                            from
                                 TMP$VALUES v0
                                 join TMP$VALUES v7 on v7.ID_ITEM = v0.ID_ITEM and v7.ID_ATTRIBUTE = 7  -- код
                                 join TMP$VALUES v8 on v8.ID_ITEM = v0.ID_ITEM and v8.ID_ATTRIBUTE = 8 -- название
                                 join TMP$VALUES v10 on v10.ID_ITEM = v0.ID_ITEM and v10.ID_ATTRIBUTE = 10 -- группа услуг
                                 join TMP$VALUES v13 on v13.ID_ITEM = v0.ID_ITEM and v13.ID_ATTRIBUTE = 13 -- цена
                                 join TMP$VALUES v14 on v14.ID_ITEM = v0.ID_ITEM and v14.ID_ATTRIBUTE = 14 -- кол-во
                            where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                  and v7.ATTRIBUTE_VALUE = :S7
                                  and v10.ATTRIBUTE_VALUE = :S10
                            group by 1, 2, 3
PLAN JOIN (V0 INDEX (TMP$VALUES_AV), V7 INDEX (TMP$VALUES), V8 INDEX (TMP$VALUES), V10 INDEX (TMP$VALUES), V13 INDEX (TMP$VALUES), V14 INDEX (TMP$VALUES))
                            order by 1, 2, 3

дало 170->106 ms в отдельном запросе

при попытке вставить в ES
Dynamic SQL Error.
SQL error code = -104.
Token unknown - line 22, column 30.
group.
<Missing arg #1 - possibly status vector overflow>.
-----------------------------------------------------------------------------------------
SQLCODE: -104
SQLSTATE: 42000
GDSCODE: 335544569
Re: FB 5.0 Производительность, оптимизация [сообщение #4749 является ответом на сообщение #4748] Fri, 29 March 2024 15:54 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 332
Зарегистрирован: June 2022
Senior Member
2 ES выполненные друг за другом
Re: FB 5.0 Производительность, оптимизация [сообщение #4750 является ответом на сообщение #4747] Fri, 29 March 2024 16:00 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
dimitr писал(а) Fri, 29 March 2024 15:44

а давай[/quote]

пжлста
  • Вложение: TST.7z
    (Размер: 1.47MB, Загружено 223 раза)
  • Вложение: TST50.7z
    (Размер: 1.57MB, Загружено 209 раз)
  • Вложение: sales_by_group.sql
    (Размер: 6.89KB, Загружено 214 раз)
  • Вложение: select.sql
    (Размер: 1.52KB, Загружено 205 раз)
Re: FB 5.0 Производительность, оптимизация [сообщение #4751 является ответом на сообщение #4750] Fri, 29 March 2024 17:33 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
PLAN нужно писать после GROUP BY, а не до Wink
В процедуре - неправильное место.
Re: FB 5.0 Производительность, оптимизация [сообщение #4752 является ответом на сообщение #4751] Fri, 29 March 2024 19:22 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
в эксперте прокатилло

а доку по планам я сегодня в первый раз читал. и вней прям буквами - "перед order"

PS точно. слаб на глаза стал

PPS

------ Performance info ------
Prepare time = 0ms
Execute time = 49s 750ms
Avg fetch time = 49,95 ms
Current memory = 777 161 200
Max memory = 811 366 512
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 6 416
Fetches from cache = 125 050 775

[Обновления: Fri, 29 March 2024 19:28]

Известить модератора

Re: FB 5.0 Производительность, оптимизация [сообщение #4754 является ответом на сообщение #4752] Fri, 29 March 2024 23:06 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
pastor
------ Performance info ------
Prepare time = 0ms
Execute time = 49s 750ms
Это нужно сравнивать с
pastor
около 1000 проходов - 2.5 минуты на АИ50 и 1 мин на АИ25
?
Т.е. стало чуть лучше, чем было в 2.5 ?
Re: FB 5.0 Производительность, оптимизация [сообщение #4755 является ответом на сообщение #4741] Sat, 30 March 2024 01:42 Переход к предыдущему сообщениюПереход к следующему сообщению
SD в настоящее время не в онлайне  SD
Сообщений: 417
Зарегистрирован: August 2022
Senior Member
sim_84 писал(а) Fri, 29 March 2024 13:25

А что на временной таблице можно пересчитать статистику индексов и использовать её в той же транзакции?
Насколько мне изменяет склероз, статистика после пересчёта сохраняется в системных таблицах и будет использоваться во всех последующих транзакциях. Так что один раз её сфабриковать достаточно.
Re: FB 5.0 Производительность, оптимизация [сообщение #4756 является ответом на сообщение #4755] Sat, 30 March 2024 10:20 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
это паллиатив

оно и так уже на нескольких обходных решениях держится

четыре предметные области, каждая со своим набором сущностей и атрибутов,
в каждой свои критерии группировки

свои произвольные\календарные\сезонн ые\тренировочные периоды

математически довольно легко формализуется

решается через отчеты по временным таблицам.
на небольших массивах - на отлично, 100% покрытие

на больших - упирается в быстродействие
лечится оно или нет? не знаю

может быть есть какое-нибудь элементарное решение типа весовых коэффициентов для временных таблиц оптимизатора, которое повысит вероятность использования индекса а не хаша.
или особенное вычисление/получение статистики индексов для временных таблиц (мы же знаем размер индекса,да?)
или в 6-ке будут гистограммы по мере наполнения данными

в исходниках оптимизатора я не ориентируюсь, вижу только внешние проявления, то вот, (стучу в бубен) взываю к Владу
чаще всего, (Небесный Ворон отвечает) получаю дельный совет
Re: FB 5.0 Производительность, оптимизация [сообщение #4757 является ответом на сообщение #4741] Sat, 30 March 2024 11:09 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
sim_84 писал(а) Fri, 29 March 2024 14:25
hvlad писал(а) Fri, 29 March 2024 15:16

Ещё один вопрос - сколько времени займёт пересчёт статики для всех индексов TMP$VALUES ?
А что на временной таблице можно пересчитать статистику индексов и использовать её в той же транзакции?

Теоретически на ON COMMIT PRESERVE ROWS можно в разных транзакциях сделать заливку, пересчёт статистики и сам запрос.
Но в ON COMMIT DELETE ROWS, да ещё в той же транзакции/блоке это вообще реально?
Я хотел узнать о времени, которое занимает оный пересчёт.

Штатными ср-вами обновить статистику и использовать её в той же транзакции для GTT ON COMMIT DELETE ROWS действительно невозможно.
Пока что
Re: FB 5.0 Производительность, оптимизация [сообщение #4760 является ответом на сообщение #4757] Sat, 30 March 2024 15:47 Переход к предыдущему сообщениюПереход к следующему сообщению
SD в настоящее время не в онлайне  SD
Сообщений: 417
Зарегистрирован: August 2022
Senior Member
Так это для любых таблиц невозможно: статистика пересчитывается в DFW по коммиту.
Re: FB 5.0 Производительность, оптимизация [сообщение #4761 является ответом на сообщение #4754] Sat, 30 March 2024 16:42 Переход к предыдущему сообщениюПереход к следующему сообщению
pastor в настоящее время не в онлайне  pastor
Сообщений: 83
Зарегистрирован: June 2022
Географическое положение: Калуга
Member
hvlad писал(а) Fri, 29 March 2024 23:06
pastor
------ Performance info ------
Prepare time = 0ms
Execute time = 49s 750ms
Это нужно сравнивать с
pastor
около 1000 проходов - 2.5 минуты на АИ50 и 1 мин на АИ25
?
Т.е. стало чуть лучше, чем было в 2.5 ?
на 5.0 - 43 сек
на 2.5 - 47 секунд
там есть еще 4 (или уже 2? не помню) прохода по таблицам обычным запросом, без ES

это первые проходы сразу после коннекта
на втором удаляется по 600 000 записей

ЗЫ процедуры сильно урезаны по сравнению с оригиналом из первого поста.

[Обновления: Sat, 30 March 2024 17:01]

Известить модератора

Re: FB 5.0 Производительность, оптимизация [сообщение #4762 является ответом на сообщение #4760] Sat, 30 March 2024 17:07 Переход к предыдущему сообщениюПереход к предыдущему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
SD писал(а) Sat, 30 March 2024 14:47
Так это для любых таблиц невозможно: статистика пересчитывается в DFW по коммиту.
а) читай внимательнее
б) это не высечено в камне
Предыдущая тема: Подключение пользователя с указанием роли на которую у него нет прав
Следующая тема: Многократное обновление таблицы
Переход к форуму:
  


Текущее время: Sun Dec 22 19:17:20 GMT+3 2024

Общее время, затраченное на создание страницы: 0.01415 секунд