ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / производительность (как всегда о том же)
6 сообщений из 6, страница 1 из 1
производительность (как всегда о том же)
    #37083205
CEH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CEH
Участник
Здесь много полезного накопилось. разной свежести конечно...
предлагаю всем проверить старые "фичи" на свежих кориях каше. Я начну:
...
Рейтинг: 0 / 0
28.01.2011, 04:14
| Ответить | Цитировать | Написать  
производительность (как всегда о том же)
    #37083206
CEH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CEH
Участник
MY_View содержит данные из my_table. My_table содержит поле "Status", возможные значения от 0 до 5, поле будет индексировано. Новые записи имеют Status = 0, когда полностью обработаны Status = 5. Обработаные записи никогда не удаляются, 98% записей имеют статус = 5. После настройки my_table, MY_view стала тормозить , но не всегда.
CEH
Код: 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.
1.	Version=5 и 2009
2.	Selectivity=~17%;
3.	 query: Select * from MY_Table LEFT OUTER JOIN  Other_Table (MY_Table.EntryType  = Other_Table.TimeEntryTypeID) … 3 more JOINS  where MY_Table .Status=?AND …
4.	Modify From clause to have Select from MY_Table where Status<5 -- no effect
5.	Modify From clause to have Select from MY_Table where Status<=4 -- no effect
6.	Modify From clause to have Select from MY_Table where Status<=4 AND Status>=0 -- no effect
7.	Modify From clause to have Select from MY_Table where Status between 0 AND 5 -- no effect
8.	Modify From clause to have Select from MY_Table where Status <> 5 -- no effect
9.	Modify MY_Table.Status property in the class to have the max value of 5 and min value of 0 -- no effect
10.	Modify From clause to have Select from MY_Table where Status in(0,1,2,3,4) – works correctly
11.	From clause to have Select from MY_Table where Status=0 OR Status=1 … -- works correctly
12.	Full join an extra table MY_Table.Status and use it in conjunction with %INORDER (e.g. Select * FROM %INORDER 
             MY_TableStatus INNER JOIN MY_Table ON (MY_Table.StatusID = MY_Tabletatus.StatusID) LEFT OUTER JOIN Other_Table 
             ON    (MY_Table.EntryType            = Other_Table.TimeEntryTypeID)  WHERE MY_TableStatus.StatusID<5) – works correctly
13.	Same as the Test 9 except %INORDER is not Used – works correctly
14.	Change MY_Table.Status to Property Status As %Integer(VALUELIST=",0,1,2,3,4,5"… -- no effect
15.	Change MY_Table.Status to Property Status As %TinyInt(… -- no effect
16.	Return SQL to its initial state, Edit the WHERE clause: MY_TABLE.Status in (1,2,3) – works correctly
17.	Edit the WHERE clause: MY_TABLE.Status in (1,2,3,4) – no effect  (This is absolutely crazy!)
18.	Change selectivity to 50% in storage and and rerun test #15: -- noeffect

 19.	Edit the WHERE clause: MY_TABLE.Status in (1,2) – no effect
20.	Edit the WHERE clause: MY_TABLE.Status in (1) – works correctly.  (It looks like if the SELECTIVITY*NUMBEROFARGUMENTS>50%? 60%? 70%, Cache doesn’t use the status index.)
21.	Edit Selectivity to "52.6275%"run with : MY_TABLE.Status in (1) – no effect
22.	Edit Selectivity to "52.6274%"run with : MY_TABLE.Status in (1) – works correctly!!!


В заключение:
1.Точная формула для определения наиболее эффективного плана запроса неясна. Selectivity, кажется, работает с нормально распределеными данными. (normal distribution).
2. В таблицах типа my_table исключите Selectivity и Extent Size в Property и Storage. Пока лучшим решением является использование %INORDER.
...
Рейтинг: 0 / 0
28.01.2011, 04:21
| Ответить | Цитировать | Написать  
производительность (как всегда о том же)
    #37083236
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Текст не читал, многа букав
Суть в том, что формально селективность по полю статус плохая, а на самом деле хорошая?

И каше этого не понимает, так как селективность ставится на поле целиком, и план формируется на запрос без конкретных значений.
Решения - %IgnoreIndices, конструкции типа select * from (select * table)
Можно в хранении руками селективность поправить, но это не сильно хорошо.
...
Рейтинг: 0 / 0
28.01.2011, 06:49
| Ответить | Цитировать | Написать  
производительность (как всегда о том же)
    #37089658
CEH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CEH
Участник
Вот ещё -- иногда простейшее изменение в SQL может дать ощутимые результаты.
UPPER? LOWER?Dynamic Queries - prepare and execute only:
Test 1.1: 2 records retrieved in 3.200526 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE %ALPHAUP(Invoice_Number) LIKE '%150477%'

Test 1.2: 2 records retrieved in 3.185824 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE %ALPHAUP(Invoice_Number) [ '150477'

Test 1.3: 2 records retrieved in 2.82 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE $Find(%ALPHAUP(Invoice_Number),'150477')>0

Test 2.1: 2 records retrieved in 3.264058 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE UPPER(Invoice_Number) LIKE '%150477%'

Test 2.2: 2 records retrieved in 2.865078 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE UPPER(Invoice_Number) [ '150477'

Test 2.3: 2 records retrieved in 2.550148 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE $Find(UPPER(Invoice_Number),'150477')>0

Test 3.1: 2 records retrieved in 2.645666 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE %UPPER(Invoice_Number) LIKE '%150477%'

Test 3.2: 2 records retrieved in 2.770384 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE %UPPER(Invoice_Number) [ '150477'

Test 3.3: 2 records retrieved in 2.602717 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE $Find(%UPPER(Invoice_Number),'150477')>0

Test 4.1: 2 records retrieved in .471094 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE UCASE(Invoice_Number) LIKE '%150477%'

Test 4.2: 2 records retrieved in .506032 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE UCASE(Invoice_Number) [ '150477'

Test 4.3: 2 records retrieved in .480911 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE $Find(UCASE(Invoice_Number),'150477')>0

Test 5.1: 2 records retrieved in .829205 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE %SQLUPPER(Invoice_Number) LIKE '%150477%'

Test 5.2: 2 records retrieved in .286431 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE %SQLUPPER(Invoice_Number) [ '150477'

Test 5.3: 2 records retrieved in .474841 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE $Find(%SQLUPPER(Invoice_Number),'150477')>0

Test 6.1: 2 records retrieved in .422882 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE LOWER(Invoice_Number) LIKE '%150477%'

Test 6.2: 2 records retrieved in .446032 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE LOWER(Invoice_Number) [ '150477'

Test 6.3: 2 records retrieved in .37884 sec.
SELECT TOP 1000 * FROM BillingJournal WHERE $Find(LOWER(Invoice_Number),'150477')>0

Embedded SQL (e.g. &slq(Select * from Billing Journal...) execute to get cursor to the first record:
LOWER & LIKE: 0.279768 sec.
%SQLUPPER & LIKE: 0.400521 sec.
UPPER & LIKE: 1.00274 sec.
UCASE & LIKE: 0.308962 sec.

Глупо как-то выходит. Документация клянётся %SQLUPPER рулит, а получается не совсем так.
...
Рейтинг: 0 / 0
01.02.2011, 04:27
| Ответить | Цитировать | Написать  
производительность (как всегда о том же)
    #37089660
CEH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CEH
Участник
Блок А.Н.1. Текст не читал, многа букав
2. Решения - %IgnoreIndices, конструкции типа select * from (select * table)
3. Можно в хранении руками селективность поправить, но это не сильно хорошо.
1. ?
2. плохое решение потому что я хочу пользоваться индексами но не в предлагаемом порядке и без JOIN ооочень долго
3. многа букв как раз описывают такой эксперимент. То что это не желательно я согласен.
Поэтому решил пользоваться %INORDER и создал 2 запроса:
(1) для Status in (0,1,2,3,4)
(2) Status=5
...
Рейтинг: 0 / 0
01.02.2011, 04:49
| Ответить | Цитировать | Написать  
производительность (как всегда о том же)
    #37112298
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
servit
Участник
CEH ,

Пожалуйста, приведите текст класса и код генерации данных для точного воспроизведения.
Например:

Class del.b Extends %Persistent
{

Index in On n;
Index in1 On (n As Exact);
Index in2 On (n As SqlUpper(5));

Property n As %String;

ClassMethod Fill(n As %Integer = 1000000)
{
  do ..%KillExtent()
  set ^del.bD=n
  for i=1:1:n set ^del.bD(i)=$lb("",$r(n)+1)
  do ..%BuildIndices(,1)
  do $system.SQL.TuneTable("del.b",1)
}
}

Время выполнения в Портале для миллиона строк (возвращается 1000 записей):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select TOP  1000  * from del.b where %SQLSTRING(n) LIKE '%458%'
-- ~ 1.4 с.
select TOP  1000  * from del.b where %EXACT(n) LIKE '%458%'
-- ~ 0.5 с.
select TOP  1000  * from del.b where %EXACT(n) [ '458'
-- ~ 0.3 с.
select TOP  1000  * from del.b where n [ '458'
-- ~ 0.3 с.

Вам нужен поиск с учётом регистра или без?
От сортировки по-умолчанию и типа индекса будет зависеть скорость тех или иных запросов.
...
Рейтинг: 0 / 0
11.02.2011, 18:56
| Ответить | Цитировать | Написать  
6 сообщений из 6, страница 1 из 1
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / производительность (как всегда о том же)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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