ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
13 сообщений из 13, страница 1 из 1
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657326
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all

DDL:
Код: plaintext
1.
2.
3.
4.
recreate table t(s varchar(36) unique); commit;
insert into t select uuid_to_char( gen_uuid() )
from rdb$types,rdb$types,(select 1 i from rdb$types rows 30)
rows 500000;
commit;

Запросик вида:
Код: plaintext
select count(*) from (select * from t order by s);
- выполняется на моем хосте примерно 1500 мс.

Запускаю трейс вот с таким конфигом (показаны только раскомментаренные опции):
Код: plaintext
1.
2.
3.
4.
  time_threshold =  2000 
  log_statement_finish = true
  print_plan = true
  print_perf = true
NB: time_threshold в конфиге намеренно выставлен таким, чтобы превышал время вып-я запроса "select count(*) from (select * from t order by s)".

Запускаю далее:

run-1.
Код: plaintext
1.
2.
3.
4.
5.
SQL>  select count(*) from (select t.* from t,(select 1 i from rdb$types rows 7) );
 
                COUNT
=====================
              3500000
Трейс:
 
2016 ms, 7035203 fetch(es); "T" = 3'500'000 NR
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
2014-05-30T16:59:06.1020 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3263, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:3236
                (TRA_52406090, CONCURRENCY | WAIT | READ_WRITE)

Statement 83:
-------------------------------------------------------------------------------
select count(*) from (select t.* from t,(select 1 i from rdb$types rows 7) )
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (RDB$TYPES NATURAL, T NATURAL)
1 records fetched
   2016 ms, 7035203 fetch(es)

Table                             Natural     Index    Update    Insert    Delet
********************************************************************************
RDB$TYPES                               7
T                                 3500000


run-2.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
set term ^;
execute block as
  declare n int;
  declare s varchar(80) = 'select count(*) from (select * from t order by s)';
begin
   select count(*) from (select t.* from t,(select 1 i from rdb$types rows 7) )  into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
end
^ set term ;^

Трейс:
 
11937 ms, 7035203 fetch(es), "T" = 3'500'000 NR
Код: 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.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
2014-05-30T16:59:27.3590 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3263, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:3236
                (TRA_52406090, CONCURRENCY | WAIT | READ_WRITE)

Statement 84:
-------------------------------------------------------------------------------
execute block as
  declare n int;
  declare s varchar(80) = 'select count(*) from (select * from t order by s)';
begin
  select count(*) from (select t.* from t,(select 1 i from rdb$types rows 7) ) into n;

  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  --select count(*) from (select * from t union all select * from t union all select * from t  union all select * from t  )
 into n;

end

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (RDB$TYPES NATURAL, T NATURAL)
0 records fetched
  11937 ms, 7035203 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$TYPES                               7
T                                 3500000
Поменялось только время вып-я, всё остальное - то же самое.

Таким обр., если стейтмент выполняется меньше, чем параметр time_threshold, то в трейсе:
1) этот стейтмент со своей отдельной статистикой НЕ будет показан (и это правильно);
2) в итоговой статистике также *НЕ* будут учитываться затраты на этот "легковесный" стейтмент.

След-но, если у мну выполняется 100 таких "легковесных" стейтментов, и каждый из них не достоин регистрации в трейсе, то СУММАРНАЯ статистика по ним... также не будет учитываться в общем выводе!

Это правильно ?
...
Рейтинг: 0 / 0
30.05.2014, 17:13
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657357
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
что то мне всегда казалось что для трейса execute block является одним оператором и вся статистика для него должна попадать в трейс в целом без разбиения по запросам входящим в EB.
...
Рейтинг: 0 / 0
30.05.2014, 17:46
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657380
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисчто то мне всегда казалосьне, неправильно казалось :-)
вот, глянь что будет, если поставить time_threshold = 100:
 
Код: 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.
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.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
Trace session ID 4 started
2014-05-30T18:05:04.1870 (9014:0x7f4f8c081e28) TRACE_INIT
        SESSION_4


2014-05-30T18:05:09.4340 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22365:
-------------------------------------------------------------------------------
select count(*) from (select * from t order by s)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T ORDER RDB$3)
1 records fetched
   1399 ms, 1501761 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            500000

2014-05-30T18:05:10.6990 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22365:
-------------------------------------------------------------------------------
select count(*) from (select * from t order by s)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T ORDER RDB$3)
1 records fetched
   1264 ms, 1501761 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            500000

2014-05-30T18:05:11.9720 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22365:
-------------------------------------------------------------------------------
select count(*) from (select * from t order by s)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T ORDER RDB$3)
1 records fetched
   1273 ms, 1501761 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            500000

2014-05-30T18:05:13.2940 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22365:
-------------------------------------------------------------------------------
select count(*) from (select * from t order by s)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T ORDER RDB$3)
1 records fetched
   1321 ms, 1501761 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            500000

2014-05-30T18:05:14.5710 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22365:
-------------------------------------------------------------------------------
select count(*) from (select * from t order by s)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T ORDER RDB$3)
1 records fetched
   1277 ms, 1501761 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            500000

2014-05-30T18:05:16.0550 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22365:
-------------------------------------------------------------------------------
select count(*) from (select * from t order by s)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T ORDER RDB$3)
1 records fetched
   1483 ms, 1501761 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            500000

2014-05-30T18:05:17.6140 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22365:
-------------------------------------------------------------------------------
select count(*) from (select * from t order by s)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T ORDER RDB$3)
1 records fetched
   1558 ms, 1501761 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            500000

2014-05-30T18:05:19.2240 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22365:
-------------------------------------------------------------------------------
select count(*) from (select * from t order by s)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T ORDER RDB$3)
1 records fetched
   1609 ms, 1501761 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            500000

2014-05-30T18:05:20.9610 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22365:
-------------------------------------------------------------------------------
select count(*) from (select * from t order by s)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T ORDER RDB$3)
1 records fetched
   1737 ms, 1501761 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            500000

2014-05-30T18:05:22.3440 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22365:
-------------------------------------------------------------------------------
select count(*) from (select * from t order by s)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T ORDER RDB$3)
1 records fetched
   1382 ms, 1501761 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            500000

2014-05-30T18:05:22.3440 (9014:0x7f4f8c081e28) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_3271, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:4440
                (TRA_52407438, CONCURRENCY | WAIT | READ_WRITE)

Statement 22363:
-------------------------------------------------------------------------------
execute block as
  declare n int;
  declare s varchar(80) = 'select count(*) from (select * from t order by s)';
begin
  select count(*) from (select t.* from t,(select 1 i from rdb$types rows 7) ) into n;

  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  execute statement (s) into n;
  --select count(*) from (select * from t union all select * from t union all select * from t  union all select * from t  ) into n;

end

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (RDB$TYPES NATURAL, T NATURAL)
0 records fetched
  18141 ms, 7035211 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$TYPES                               7
T                                 3500000
Статистика выводится как по итоговому EB, так и по всем его "составляющим", в т.ч. ES. И при этом в итоге - складывается.
...
Рейтинг: 0 / 0
30.05.2014, 18:07
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657384
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Симонов Денисчто то мне всегда казалось что для трейса execute block является одним оператором и вся статистика для него должна попадать в трейс в целом без разбиения по запросам входящим в EB.
в целом правильно, но исключая execute statement - он ведь выполняет отдельный запрос к серверу
...
Рейтинг: 0 / 0
30.05.2014, 18:13
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657390
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Хотя, погодь... в EB у мну один "просто" стейтмент (не ES) и 10 ES'ов. Итого - 11 стейтментов.
И вот:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
$ grep "ms," trc_trnk_20140530_180500.log
   1399 ms, 1501761 fetch(es) -- 1
   1264 ms, 1501761 fetch(es) -- 2
   1273 ms, 1501761 fetch(es) -- 3
   1321 ms, 1501761 fetch(es) -- 4
   1277 ms, 1501761 fetch(es) -- 5
   1483 ms, 1501761 fetch(es) -- 6
   1558 ms, 1501761 fetch(es) -- 7
   1609 ms, 1501761 fetch(es) -- 8
   1737 ms, 1501761 fetch(es) -- 9
   1382 ms, 1501761 fetch(es) -- 10
   18141  ms, 7035211 fetch(es)

Сумма по 1...10 = 14303 мс.
Значит, 18141 - 14303 = 3838 - наверное , это затраты на НЕдинамический select count(*) from (select t.* from t,(select 1 i from rdb$types rows 7) ) , который в вышеприведенном execute block'e указан первым.

Т.е. трейс показывает итоговую статистику как сумму
1) затрат на динамические SQL, но только те, что превысили time_threshold;
2) затрат на все остальные операторы внутри EB, которые *не* динамические. И вот по ТАКИМ операторам он действительно никогда не выдаёт разблюдовку, статистика по ним - общая.

Странновато как-то это всё...
...
Рейтинг: 0 / 0
30.05.2014, 18:20
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657395
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

EB со всеми своими статическими внутренностями - это один запрос, каждый ES внутри EB - отдельный от EB запрос. Вот и все.
...
Рейтинг: 0 / 0
30.05.2014, 18:24
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657402
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrкаждый ES внутри EB - отдельный от EB запрос.А их как-то "связать" можно в плане того, чтобы статистика всегда суммировалась, даже если сам ES слишком быстр, но их (ES'ов таких) - много ?
...
Рейтинг: 0 / 0
30.05.2014, 18:29
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657424
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

должна суммироваться вроде бы
...
Рейтинг: 0 / 0
30.05.2014, 18:54
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657431
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrдолжна суммироваться вроде быдык не суммируется, как бэ... глянь в стартовый пост, плз...
...
Рейтинг: 0 / 0
30.05.2014, 18:59
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657462
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

э погодь. Если всё так как сказал dimitr, то всё правильно. Статистика по отдельным ES не попадает, т.к. они выполняются отдельно, но время суммируется, т.к. оно относится ко всему EB
...
Рейтинг: 0 / 0
30.05.2014, 19:57
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657468
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов ДенисСтатистика по отдельным ES не попадает, т.к. они выполняются отдельно , но время суммируется, т.к. оно относится ко всему EBES всегда выполняются "из-под" внешнего блока. Время суммируем, статистику не суммируем, а тут вообще рыбу заворачиваем...
Я понял теперь причину всех этих "загадок" со странно долгим временем и микроскопной статистикой.

Получается, что если ставить time_threshold в какое-то большое значение (например, в 5000 мс), то верить дальше можно только общему ВРЕМЕНИ, но никак не прочим параметрам!
Потому что если в коде имеются ES, даже вполне себе быстрые при однократном своем вызове, но вызываемые многократно , то они втихаря наплюсуют время, но не отразятся на fetch(es)/read(s)/write(s)/mark(s).

Пойду в аптеку, блин...
...
Рейтинг: 0 / 0
30.05.2014, 20:16
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38657473
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидdimitrдолжна суммироваться вроде быдык не суммируется, как бэ... глянь в стартовый пост, плз...
проверил - действительно не суммируются, ибо похоже не привязываются к родительскому запросу. В общем случае (ES on external, например) это и невозможно, но в случае локальных ES теоретически можно было бы. Придет лесник Влад - скажет свое веское слово :-)
...
Рейтинг: 0 / 0
30.05.2014, 20:26
| Ответить | Цитировать | Написать  
trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
    #38659348
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrПридет лесник Влад - скажет свое веское слово :-)Лесник не пришёл. А значит, я сам пойду к нему.

http://tracker.firebirdsql.org/browse/CORE-4448

(приоритет специально оставил 'Major', ибо без этого очень трудно понять, где-чего надо рихтовать).
...
Рейтинг: 0 / 0
02.06.2014, 21:56
| Ответить | Цитировать | Написать  
13 сообщений из 13, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / trace: должны ли добавляться операции в общую стат-ку, если каждая из них < t_threshold ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&gotonew=1&tid=1563542]:
 0ms
get settings:
 8ms
get forum list:
 20ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 171ms
get topic data:
 9ms
get first new msg:
 6ms
get forum data:
 2ms
get page messages:
 46ms
get tp. blocked users:
 1ms
others: 209ms
total:  480ms
созд. / загр.: 480ms
x
x
Закрыть


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