powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / FB 3.0 медленнее на поздапросе
21 сообщений из 21, страница 1 из 1
FB 3.0 медленнее на поздапросе
    #39172422
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Помятуя слова Еманова о том, что тройка может быть медленнее на одиночных запросах, поймал таки ощутимое замедление.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
-- Генерим виртуальные данные (с реальными аналогично)
with
multiplier(val) as (
    select 1 from rdb$database
    union all
    select 1 from rdb$database
    union all
    select 1 from rdb$database
    union all
    select 1 from rdb$database
),
A(type_name) as (
  select t1.rdb$type_name from rdb$types t1, rdb$types t2, multiplier m1, multiplier m2
)
select A.type_name,
-- Можно было и просто count(*). Пример стерильный, но смысл именно в поздапросе
  (select count(*) from A A2 where A2.type_name = A.type_name) from A
group by A.type_name


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
FB 2.5
Prepare time = 0ms
Execute time =  2s 418ms 
Avg fetch time = 93,00 ms
Current memory = 167 203 856
Max memory = 430 400 264
Memory buffers = 9 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 3 406 272

FB 3.0
Prepare time = 0ms
Execute time =  3s 526ms 
Avg fetch time = 135,62 ms
Current memory = 171 938 248
Max memory = 237 987 424
Memory buffers = 9 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 4 217 688

Это так надо или руки у меня?
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39172437
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
afgm,

запросы к rdb$types в 2.5 и 3.0 не эквивалентны. В 3.0 там существенно больше записей. Так что переделывай тест
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39172482
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис,

Да. Всё верно! Пример для воспроизведения я сделал некорректный. Вот теперь надо кумекать, как сделать корректный... на реальных-то данных воспроизводится. Хоть и не в 2 раза разрыв по времени, но есть. Пока буду клепать, глядишь и ответ найду.
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39172750
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
afgmна реальных-то данных воспроизводится.Реальные данные, как правило, обрабатываются одновременно N реальными пользователями, где N >> 1.
А в этом случае 2.5 безнадёжно проср отстанет от 3.0 (особенно если трёшка будет работать как SS; да и SC тоже; а вот 3.0 Cs на сегодня будет примерно как 2.5 Cs).
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39172837
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидРеальные данные, как правило, обрабатываются одновременно N реальными пользователями, где N >> 1.
Судя по всему, в моём случае виноват новый проброс условий внутрь вьюшек.
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39172853
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
afgm,

примерчик таки хотелось бы увидеть
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39172895
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
afgm,

я попробовал переделать твой запрос так чтобы он был независим от rdb$types.
TempCacheLimit = 1024M в 2.5 эквивалентное значение, но в числом

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
set autoddl on;

recreate table tmp (
  n int,
  m int
);

insert into tmp(n, m)
with recursive r(n, m) as (
  select 1, 1 from rdb$database
  union all
  select n+1, mod(m+1, 10) from r where n<1000
)
select r1.n, r1.m from r r1, r r2;

commit;



Код: sql
1.
2.
3.
4.
5.
select
  t1.m,
  (select count(*) from tmp t2 where t1.m=t2.m)
from tmp t1
group by t1.m



2.5.5План
PLAN (T2 NATURAL)
PLAN SORT ((T1 NATURAL))

------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 8s 143ms
Среднее время на получение одной записи = 814,30 ms
Current memory = 274 013 576
Max memory = 429 997 008
Memory buffers = 16 384
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 22 072 089


3.0План
PLAN (T2 NATURAL)
PLAN SORT (T1 NATURAL)

------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 10s 576ms
Среднее время на получение одной записи = 1 057,60 ms
Current memory = 280 340 544
Max memory = 318 095 424
Memory buffers = 16 384
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 22 072 096


вот оно. Проброс условий тут не причём. Оптимизатор даёт полностью идентичные планы, но сам кэш в моноконнекте в 3.0 чуть чуть медленее.

Чтобы подсластить пилюлю, на совсем виртуальных данных 3.0 выигрывает, видимо рекурсивные запросы там выполняются оптимальнее

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
with recursive r(n, m) as (
  select 1, 1 from rdb$database
  union all
  select n+1, mod(m+1, 10) from r where n<1000
),
t(n, m) as (
  select r1.n, r1.m from r r1, r r2
)
select
  t1.m,
  (select count(*) from t t2 where t1.m=t2.m)
from t t1
group by t1.m



2.5.5------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 17s 940ms
Среднее время на получение одной записи = 1 794,00 ms
Current memory = 274 052 152
Max memory = 430 779 496
Memory buffers = 16 384
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 55 075


3.0------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 15s 101ms
Среднее время на получение одной записи = 1 510,10 ms
Current memory = 280 499 432
Max memory = 444 644 152
Memory buffers = 16 384
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 55 063
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39172955
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис,

возможно, я слишком упростил.
Никак не могу сделать простой пример :(

Код: sql
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.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
with A as (
    select av.attribute_value /*||''*/ -- + строка
       as GROUP_NAME, o.object_name as OBJECT_NAME from p_objects o
      inner join p_attribute_values av on o.unq=av.unq and av.attribute_name='GROUP'
    where o.object_type in ('MS2008_TABLE','MS2008_VIEW','MS2008_PROCEDURE','MS2008_UDF')
)
select A.GROUP_NAME ,
       (
         select count(*) from A A2 where A2.GROUP_NAME = A.GROUP_NAME
        )
from A
group by A.GROUP_NAME 

/*
FB 2.5
прямой: 9s 485ms
+строка: 11s 887ms

FB 3.0
прямой: 1s 857ms
+строка: 17s 535ms
*/

-- Стал выкидывать "лишнее", и всё перевернулось
with A as (
    select av.attribute_value /*||''*/ -- + строка
       as GROUP_NAME
       from p_attribute_values av where av.attribute_name='GROUP'
)
select A.GROUP_NAME ,
       (
         select count(*) from A A2 where A2.GROUP_NAME = A.GROUP_NAME
        )
from A
group by A.GROUP_NAME 

/*
FB 2.5
прямой: 1s 498ms
+строка: 9s 594ms

FB 3.0
прямой: 1s 700ms
+строка: 6s 957ms
*/



p_attribute_values - вьюшка
p_objects - вьюшка на вьюшке

Если что: Бэкап в zip-е весит 32 метра, 7z - 10 метров
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39172991
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
afgm,

из этих запросов не фига не понятно.
afgmp_attribute_values - вьюшка
p_objects - вьюшка на вьюшке

вьюхи можно представить как cte и тогда всё будет в одном запросе. Планов всё равно не видно.
В 3.0 исправлен старый баг оптимизатора, который появился в 2.x, поэтому различное поведение на +0, ||'' на поле по которому идёт группировка меня не удивляет. Планы дадут более полный ответ. Для 3.0 можно ещё на explain глянуть
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39173062
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисafgm,

из этих запросов не фига не понятно.
Да я прекрасно понимаю понимаю. Без реальной базы даже с полными метаданными и полными простынями планов разбираться слишком муторно.
Метаданные представлений
Код: sql
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.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
CREATE OR ALTER VIEW P_ATTRIBUTE_VALUES(
    ID,
    UNQ,
    ATTRIBUTE_ID,
    ATTRIBUTE_NAME,
    ATTRIBUTE_VALUE)
AS
select 
    AV.id,
    AV.UNQ,
    AV.attribute_id,
    A.attribute_name,
    AV.attribute_value
from attribute_values AV, attributes A,UNQ U
    where AV.attribute_id = A.ID
      and AV.UNQ = U.UNQ
      and U.LOAD_ID = rdb$get_context('USER_SESSION', 'LOAD_ID');

CREATE OR ALTER VIEW P_OBJECTS(
    UNQ,
    LOAD_ID,
    ELEMENT_ID,
    ID,
    OBJECT_TYPE_ID,
    OBJECT_TYPE,
    OBJECT_NAME,
    OBJECT_OWNER,
    DELPHI_NAME,
    AUTHOR,
    LOGICAL_LEVEL,
    UNUSED,
    TODEL,
    DESCRIPTION,
    CREATION_DATE,
    TODO,
    FOREXTERNAL,
    SERVICE,
    TOFUTURE,
    "DESCRIBE",
    ENTITY_NAME,
    ENTITY_ALIAS,
    ENTITY_ALTERNATE_CONSTR_FLD,
    ENTITY_GENERATE_CONSTANTS,
    ENTITY_PREFIXES,
    CONSTANTS_INFO_FIELD_NAME,
    IMPLICITUSE,
    PARENT_COUNT,
    CHILD_COUNT,
    SOURCE_SIZE,
    DBU)
AS
select UNQ, LOAD_ID, ELEMENT_ID,
       ID, OBJECT_TYPE_ID, OBJECT_TYPE, OBJECT_NAME, OBJECT_OWNER, DELPHI_NAME,
       AUTHOR, LOGICAL_LEVEL, UNUSED, TODEL,
       DESCRIPTION, CREATION_DATE,
       TODO, FOREXTERNAL, SERVICE, TOFUTURE, DESCRIBE,
       ENTITY_NAME, ENTITY_ALIAS, ENTITY_ALTERNATE_CONSTR_FLD, ENTITY_GENERATE_CONSTANTS, ENTITY_PREFIXES,
       CONSTANTS_INFO_FIELD_NAME,
       IMPLICITUSE,
       PARENT_COUNT, CHILD_COUNT,
       SOURCE_SIZE,
       DBU
from P_OBJECTS_FULL
where SHOW_IN_OBJECTS = 1;

CREATE OR ALTER VIEW P_OBJECTS_FULL(
    UNQ,
    LOAD_ID,
    ELEMENT_ID,
    ID,
    OBJECT_TYPE_ID,
    OBJECT_TYPE,
    OBJECT_NAME,
    OBJECT_OWNER,
    DELPHI_NAME,
    AUTHOR,
    LOGICAL_LEVEL,
    UNUSED,
    TODEL,
    DESCRIPTION,
    CREATION_DATE,
    TODO,
    FOREXTERNAL,
    SERVICE,
    TOFUTURE,
    "DESCRIBE",
    ENTITY_NAME,
    ENTITY_ALIAS,
    ENTITY_ALTERNATE_CONSTR_FLD,
    ENTITY_GENERATE_CONSTANTS,
    ENTITY_PREFIXES,
    CONSTANTS_INFO_FIELD_NAME,
    IMPLICITUSE,
    PARENT_COUNT,
    CHILD_COUNT,
    SOURCE_SIZE,
    DBU,
    SHOW_IN_OBJECTS)
AS
select
    O.UNQ,
    U.load_id,
    U.element_id,
    O.id,
    U.object_type_id,
    OT.type_name as object_type,
    O.object_name,
    o.object_owner,
    O.delphi_name,
    O.author,
    O.logical_level,
    O.UNUSED,
    O.TODEL,
    O.description,
    O.creation_date,
    O.TODO,
    O.FOREXTERNAL,
    O.SERVICE,
    O.TOFUTURE,
    O.DESCRIBE,
    O.ENTITY_NAME,
    O.ENTITY_ALIAS,
    O.ENTITY_ALTERNATE_CONSTR_FLD,
    O.ENTITY_GENERATE_CONSTANTS,
    O.ENTITY_PREFIXES,
    O.CONSTANTS_INFO_FIELD_NAME,
    O.IMPLICITUSE,
    O.parent_count,
    O.child_count,
    O.source_size,
    O.dbu,
    OT.SHOW_IN_OBJECTS
from objects O, UNQ U, OBJECTS_TYPES OT
where O.UNQ = U.UNQ
and U.OBJECT_TYPE_ID = OT.ID
and U.LOAD_ID = rdb$get_context('USER_SESSION', 'LOAD_ID')
--with check option
;





Запрос без строки
Код: sql
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.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
with A as (
    select av.attribute_value /*||''*/ -- + строка
       as GROUP_NAME, o.object_name as OBJECT_NAME from p_objects o
      inner join p_attribute_values av on o.unq=av.unq and av.attribute_name='GROUP'
    where o.object_type in ('MS2008_TABLE','MS2008_VIEW','MS2008_PROCEDURE','MS2008_UDF')
)
select A.GROUP_NAME ,
       (
         select count(*) from A A2 where A2.GROUP_NAME = A.GROUP_NAME
        )
from A
group by A.GROUP_NAME 

2.5
PLAN JOIN (A2 O P_OBJECTS_FULL OT NATURAL, A2 O P_OBJECTS_FULL U INDEX (FK_UNQ_1, UNQ_IDX3), A2 O P_OBJECTS_FULL O INDEX (FK_OBJECTS_1), A2 AV U INDEX (UNQ_IDX1), A2 AV AV INDEX (FK_ATTRIBUTE_VALUES_5), A2 AV A INDEX (PK_ATTRIBUTES))
PLAN SORT (JOIN (A O P_OBJECTS_FULL OT NATURAL, A O P_OBJECTS_FULL U INDEX (FK_UNQ_1, UNQ_IDX3), A O P_OBJECTS_FULL O INDEX (FK_OBJECTS_1), A AV U INDEX (UNQ_IDX1), A AV AV INDEX (FK_ATTRIBUTE_VALUES_5), A AV A INDEX (PK_ATTRIBUTES)))

3.0
PLAN JOIN (A2 AV A INDEX (ATTRIBUTES_IDX1), A2 AV AV INDEX (FK_ATTRIBUTE_VALUES_1), A2 O P_OBJECTS_FULL O INDEX (FK_OBJECTS_1), A2 O P_OBJECTS_FULL U INDEX (UNQ_IDX1), A2 O P_OBJECTS_FULL OT INDEX (PK_OBJECTS_TYPES), A2 AV U INDEX (UNQ_IDX1))
PLAN SORT (JOIN (A AV A INDEX (ATTRIBUTES_IDX1), A AV AV INDEX (FK_ATTRIBUTE_VALUES_1), A O P_OBJECTS_FULL O INDEX (FK_OBJECTS_1), A O P_OBJECTS_FULL U INDEX (UNQ_IDX1), A O P_OBJECTS_FULL OT INDEX (PK_OBJECTS_TYPES), A AV U INDEX (UNQ_IDX1)))

Select Expression
    -> Singularity Check
        -> Aggregate
            ->  Nested Loop Join (inner)
                -> Filter
                    -> Table "ATTRIBUTES" as "A2 AV A" Access By ID
                        -> Bitmap
                            -> Index "ATTRIBUTES_IDX1" Unique Scan
                -> Filter
                    -> Table "ATTRIBUTE_VALUES" as "A2 AV AV" Access By ID
                        -> Bitmap
                            -> Index "FK_ATTRIBUTE_VALUES_1" Range Scan (full match)
                -> Filter
                    -> Table "OBJECTS" as "A2 O P_OBJECTS_FULL O" Access By ID
                        -> Bitmap
                            -> Index "FK_OBJECTS_1" Range Scan (full match)
                -> Filter
                    -> Table "UNQ" as "A2 O P_OBJECTS_FULL U" Access By ID
                        -> Bitmap
                            -> Index "UNQ_IDX1" Unique Scan
                -> Filter
                    -> Table "OBJECTS_TYPES" as "A2 O P_OBJECTS_FULL OT" Access By ID
                        -> Bitmap
                            -> Index "PK_OBJECTS_TYPES" Unique Scan
                -> Filter
                    -> Table "UNQ" as "A2 AV U" Access By ID
                        -> Bitmap
                            -> Index "UNQ_IDX1" Unique Scan
Select Expression
    -> Aggregate
        -> Sort (record length: 4784, key length: 2052)
            ->  Nested Loop Join (inner)
                -> Filter
                    -> Table "ATTRIBUTES" as "A AV A" Access By ID
                        -> Bitmap
                            -> Index "ATTRIBUTES_IDX1" Unique Scan
                -> Filter
                    -> Table "ATTRIBUTE_VALUES" as "A AV AV" Access By ID
                        -> Bitmap
                            -> Index "FK_ATTRIBUTE_VALUES_1" Range Scan (full match)
                -> Filter
                    -> Table "OBJECTS" as "A O P_OBJECTS_FULL O" Access By ID
                        -> Bitmap
                            -> Index "FK_OBJECTS_1" Range Scan (full match)
                -> Filter
                    -> Table "UNQ" as "A O P_OBJECTS_FULL U" Access By ID
                        -> Bitmap
                            -> Index "UNQ_IDX1" Unique Scan
                -> Filter
                    -> Table "OBJECTS_TYPES" as "A O P_OBJECTS_FULL OT" Access By ID
                        -> Bitmap
                            -> Index "PK_OBJECTS_TYPES" Unique Scan
                -> Filter
                    -> Table "UNQ" as "A AV U" Access By ID
                        -> Bitmap
                            -> Index "UNQ_IDX1" Unique Scan



Запрос со строкой
Код: sql
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.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
with A as (
    select av.attribute_value ||'' -- + строка
       as GROUP_NAME, o.object_name as OBJECT_NAME from p_objects o
      inner join p_attribute_values av on o.unq=av.unq and av.attribute_name='GROUP'
    where o.object_type in ('MS2008_TABLE','MS2008_VIEW','MS2008_PROCEDURE','MS2008_UDF')
)
select A.GROUP_NAME ,
       (
         select count(*) from A A2 where A2.GROUP_NAME = A.GROUP_NAME
        )
from A
group by A.GROUP_NAME 

2.5
PLAN JOIN (A2 O P_OBJECTS_FULL OT NATURAL, A2 O P_OBJECTS_FULL U INDEX (FK_UNQ_1, UNQ_IDX3), A2 O P_OBJECTS_FULL O INDEX (FK_OBJECTS_1), A2 AV U INDEX (UNQ_IDX1), A2 AV AV INDEX (FK_ATTRIBUTE_VALUES_5), A2 AV A INDEX (PK_ATTRIBUTES))
PLAN SORT (JOIN (A O P_OBJECTS_FULL OT NATURAL, A O P_OBJECTS_FULL U INDEX (FK_UNQ_1, UNQ_IDX3), A O P_OBJECTS_FULL O INDEX (FK_OBJECTS_1), A AV U INDEX (UNQ_IDX1), A AV AV INDEX (FK_ATTRIBUTE_VALUES_5), A AV A INDEX (PK_ATTRIBUTES)))

3.0
PLAN JOIN (A2 AV A INDEX (ATTRIBUTES_IDX1), A2 AV AV INDEX (FK_ATTRIBUTE_VALUES_1), A2 O P_OBJECTS_FULL O INDEX (FK_OBJECTS_1), A2 O P_OBJECTS_FULL U INDEX (UNQ_IDX1), A2 O P_OBJECTS_FULL OT INDEX (PK_OBJECTS_TYPES), A2 AV U INDEX (UNQ_IDX1))
PLAN SORT (JOIN (A AV A INDEX (ATTRIBUTES_IDX1), A AV AV INDEX (FK_ATTRIBUTE_VALUES_1), A O P_OBJECTS_FULL O INDEX (FK_OBJECTS_1), A O P_OBJECTS_FULL U INDEX (UNQ_IDX1), A O P_OBJECTS_FULL OT INDEX (PK_OBJECTS_TYPES), A AV U INDEX (UNQ_IDX1)))

Select Expression
    -> Singularity Check
        -> Aggregate
            ->  Nested Loop Join (inner)
                -> Filter
                    -> Table "ATTRIBUTES" as "A2 AV A" Access By ID
                        -> Bitmap
                            -> Index "ATTRIBUTES_IDX1" Unique Scan
                -> Filter
                    -> Table "ATTRIBUTE_VALUES" as "A2 AV AV" Access By ID
                        -> Bitmap
                            -> Index "FK_ATTRIBUTE_VALUES_1" Range Scan (full match)
                -> Filter
                    -> Table "OBJECTS" as "A2 O P_OBJECTS_FULL O" Access By ID
                        -> Bitmap
                            -> Index "FK_OBJECTS_1" Range Scan (full match)
                -> Filter
                    -> Table "UNQ" as "A2 O P_OBJECTS_FULL U" Access By ID
                        -> Bitmap
                            -> Index "UNQ_IDX1" Unique Scan
                -> Filter
                    -> Table "OBJECTS_TYPES" as "A2 O P_OBJECTS_FULL OT" Access By ID
                        -> Bitmap
                            -> Index "PK_OBJECTS_TYPES" Unique Scan
                -> Filter
                    -> Table "UNQ" as "A2 AV U" Access By ID
                        -> Bitmap
                            -> Index "UNQ_IDX1" Unique Scan
Select Expression
    -> Aggregate
        -> Sort (record length: 4784, key length: 2052)
            ->  Nested Loop Join (inner)
                -> Filter
                    -> Table "ATTRIBUTES" as "A AV A" Access By ID
                        -> Bitmap
                            -> Index "ATTRIBUTES_IDX1" Unique Scan
                -> Filter
                    -> Table "ATTRIBUTE_VALUES" as "A AV AV" Access By ID
                        -> Bitmap
                            -> Index "FK_ATTRIBUTE_VALUES_1" Range Scan (full match)
                -> Filter
                    -> Table "OBJECTS" as "A O P_OBJECTS_FULL O" Access By ID
                        -> Bitmap
                            -> Index "FK_OBJECTS_1" Range Scan (full match)
                -> Filter
                    -> Table "UNQ" as "A O P_OBJECTS_FULL U" Access By ID
                        -> Bitmap
                            -> Index "UNQ_IDX1" Unique Scan
                -> Filter
                    -> Table "OBJECTS_TYPES" as "A O P_OBJECTS_FULL OT" Access By ID
                        -> Bitmap
                            -> Index "PK_OBJECTS_TYPES" Unique Scan
                -> Filter
                    -> Table "UNQ" as "A AV U" Access By ID
                        -> Bitmap
                            -> Index "UNQ_IDX1" Unique Scan



Со строкой и без, что в 2.5, что в 3.0 планы внутри версии не меняются. А вот между версиями - разные.
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39173138
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
afgm,

бр... Тяжело конечно что-то понять. Я бы для начала сравнил планы для исходных вьюх.
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39173173
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисЯ бы для начала сравнил планы для исходных вьюх.
Ну вот уже для p_objects, ранее, я на 3-ке получил улучшение, потому как условия проталкиваются глубже. В случае преставления на представлении, как я понял. Вот кажется отсюда ноги и растут. Вижу разные планы, а надо бы понимать "почему?" они разные (3.0, ясное дело :)), и почему в одном случае помогает, а в ином вредит.
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39173191
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
afgm,

сам запрос то насколько реальный? Просто там энтот подзапрос (SELECT COUNT(*) FROM A A2 WHERE ...) на фиг не упал.
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39173224
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Дениссам запрос то насколько реальный? Просто там энтот подзапрос (SELECT COUNT(*) FROM A A2 WHERE ...) на фиг не упал.
Сейчас да. Это уже вырожденный случай. Но изначально там был каскад из list-ов. Там и словил. В результате упростил до простой группировки, но вопросы-то остались.
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39173999
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Продолжаю разбираться.
Есть план для запроса с with. Ругается если его указать явно, после запроса. Как в таком случае указать?
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39174018
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
afgm,

план можно указать только для запроса целиком, а не для отдельной его части в with
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39174072
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис,

а я так и делаю
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
with A as (
    select av.attribute_value ||'' -- + строка
       as GROUP_NAME, o.object_name as OBJECT_NAME from p_objects o
      inner join p_attribute_values av on o.unq=av.unq and av.attribute_name='GROUP'
    where o.object_type in ('MS2008_TABLE','MS2008_VIEW','MS2008_PROCEDURE','MS2008_UDF')
)

select A.GROUP_NAME ,
       (
         select count(*) from A A2 where A2.GROUP_NAME = A.GROUP_NAME
        )
from A
group by A.GROUP_NAME
PLAN JOIN (A2 AV A INDEX (ATTRIBUTES_IDX1), A2 AV AV INDEX (FK_ATTRIBUTE_VALUES_1), A2 O P_OBJECTS_FULL O INDEX (FK_OBJECTS_1), A2 O P_OBJECTS_FULL U INDEX (UNQ_IDX1), A2 O P_OBJECTS_FULL OT INDEX (PK_OBJECTS_TYPES), A2 AV U INDEX (UNQ_IDX1))
PLAN SORT (JOIN (A AV A INDEX (ATTRIBUTES_IDX1), A AV AV INDEX (FK_ATTRIBUTE_VALUES_1), A O P_OBJECTS_FULL O INDEX (FK_OBJECTS_1), A O P_OBJECTS_FULL U INDEX (UNQ_IDX1), A O P_OBJECTS_FULL OT INDEX (PK_OBJECTS_TYPES), A AV U INDEX (UNQ_IDX1)))


Код: plaintext
1.
Token unknown - line 15, column 1.
PLAN.

Если убрать PLAN JOIN и оставить только PLAN SORT, то не ругается и даже выполняется.
А как указать оба плана?
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39174153
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Оба нельзя, можно только 1.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39174324
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамОба нельзя, можно только 1.

Жаль. Я думал прибить одинаковые планы в 2.5 и 3.0, и проверить производительность. Так можно было бы наблюдать внутренние скорости.
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39174342
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
afgm,

дык возьми план который даёт 2.5 (только для всего запроса) и прибей его к 3.0 тоже для всего запроса. И сравни. Потом попробуй наоборот.

З.Ы. Прибивать планы плохая практика.
...
Рейтинг: 0 / 0
FB 3.0 медленнее на поздапросе
    #39174451
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисдык возьми план который даёт 2.5 (только для всего запроса) и прибей его к 3.0 тоже для всего запроса. И сравни. Потом попробуй наоборот.
Так в этом-то и проблема (см. выше).
Симонов ДенисЗ.Ы. Прибивать планы плохая практика.
И прибить я хочу именно для теста.
...
Рейтинг: 0 / 0
21 сообщений из 21, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / FB 3.0 медленнее на поздапросе
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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