Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / FB 3.0 медленнее на поздапросе / 21 сообщений из 21, страница 1 из 1
16.02.2016, 16:16
    #39172422
afgm
afgm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FB 3.0 медленнее на поздапросе
Помятуя слова Еманова о том, что тройка может быть медленнее на одиночных запросах, поймал таки ощутимое замедление.

Код: 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
| Ответить | Цитировать | Написать  
16.02.2016, 16:29
    #39172437
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FB 3.0 медленнее на поздапросе
afgm,

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

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

примерчик таки хотелось бы увидеть
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.02.2016, 10:29
    #39172895
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FB 3.0 медленнее на поздапросе
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
| Ответить | Цитировать | Написать  
17.02.2016, 11:21
    #39172955
afgm
afgm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FB 3.0 медленнее на поздапросе
Симонов Денис,

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

Код: 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
| Ответить | Цитировать | Написать  
17.02.2016, 11:40
    #39172991
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FB 3.0 медленнее на поздапросе
afgm,

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

вьюхи можно представить как cte и тогда всё будет в одном запросе. Планов всё равно не видно.
В 3.0 исправлен старый баг оптимизатора, который появился в 2.x, поэтому различное поведение на +0, ||'' на поле по которому идёт группировка меня не удивляет. Планы дадут более полный ответ. Для 3.0 можно ещё на explain глянуть
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.02.2016, 12:42
    #39173062
afgm
afgm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FB 3.0 медленнее на поздапросе
Симонов Денис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
| Ответить | Цитировать | Написать  
17.02.2016, 13:46
    #39173138
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FB 3.0 медленнее на поздапросе
afgm,

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

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

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

а я так и делаю
Код: 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
| Ответить | Цитировать | Написать  
18.02.2016, 13:56
    #39174153
Гаджимурадов Рустам
Гаджимурадов Рустам
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FB 3.0 медленнее на поздапросе
Оба нельзя, можно только 1.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.02.2016, 15:13
    #39174324
afgm
afgm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FB 3.0 медленнее на поздапросе
Гаджимурадов РустамОба нельзя, можно только 1.

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

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

З.Ы. Прибивать планы плохая практика.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.02.2016, 16:06
    #39174451
afgm
afgm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FB 3.0 медленнее на поздапросе
Симонов Денисдык возьми план который даёт 2.5 (только для всего запроса) и прибей его к 3.0 тоже для всего запроса. И сравни. Потом попробуй наоборот.
Так в этом-то и проблема (см. выше).
Симонов ДенисЗ.Ы. Прибивать планы плохая практика.
И прибить я хочу именно для теста.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / FB 3.0 медленнее на поздапросе / 21 сообщений из 21, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 413ms
Закрыть
start [/forum/topic.php?fid=40&mobile=1&tid=1562340]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 37ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 54ms
get tp. blocked users:
 2ms
others: 274ms
total:  413ms
x
x
Закрыть


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