ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
84 сообщений из 84, показаны все 4 страниц
  все  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513583
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all

DDL:
Код: 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.
commit;
recreate table td(id int, s varchar(50)); commit;
set term ^;
execute block as
begin
  begin
    execute statement 'create sequence g';
    when any do begin end
  end
end^
set term ;^
commit;
alter sequence g restart with 0;
commit;

set term ^;
execute block as
declare n int = 1000000;
declare m int;
begin
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'q' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qw' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwe' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwer' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwert' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwerty' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwertyu' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwertyui' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwertyuio' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwertyuiop' ) returning :m-1 into m;
end^ set term ;^ commit;

Статистика по запросам сабжа:
 
Код: 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.
SQL> select count(s) from td where s like '%qwertyuiop%';

                COUNT
=====================
              1000000

Current memory = 2464649880
Delta memory = -848
Max memory = 2470393408
Elapsed time= 8.52 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 0
Writes = 0
Fetches = 20289153
SQL> select count(s) from td where s  NOT  like '%qwertyuiop%';

                COUNT
=====================
              9000000

Current memory = 2464650744
Delta memory = 864
Max memory = 2470393408
Elapsed time= 9.58 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 0
Writes = 0
Fetches = 20289153
SQL>
SQL>
SQL> select count(s) from td where s like '%q%';

                COUNT
=====================
             10000000

Current memory = 2464649864
Delta memory = -880
Max memory = 2470393408
Elapsed time= 8.59 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 0
Writes = 0
Fetches = 20289153
SQL>
SQL> select count(s) from td where s  NOT  like '%q%';

                COUNT
=====================
                    0

Current memory = 2464650728
Delta memory = 864
Max memory = 2470393408
Elapsed time= 8.82 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 0
Writes = 0
Fetches = 20289153
- показывает, что NOT like трудится дольше. И чем длиннее строка, тем сильнее различие.
Однако, характер данных таков, что like '%qwertyuiop%' и NOT like '%qwertyuiop%' должны вроде как работать одинаково: первый должен игнорировать (не рассматривать вообще) 9 млн строк, т.к. длина шаблона превышает фактическое число символов в поле ( а оно ведь известно ? ); второй же должен сразу учитывать их (опять-таки без анализа содержимого) - по той же причине.

Что тогда еще влияет ?

ЗЫ. Запрос без всяких условий:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
SQL> select count(s) from td; 

                COUNT
=====================
             10000000

Current memory = 2464645536
Delta memory = 0
Max memory = 2470393408
Elapsed time= 6.34 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 0
Writes = 0
Fetches = 20289153
...
Рейтинг: 0 / 0
26.12.2013, 20:31:48
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513616
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Ты, как обычно, чепуху всякую навыдумываешь.

Во-первых, я не уверен, что такая оптимизация вообще есть (и думаю, что её нет).
Во-вторых, она возможна только для литералов, но невозможна для параметров.
Тебя конкретно эта "оптимизация" интересует (тогда нужно про неё и спрашивать)
или разница в технике операторов LIKE и NOT LIKE ?

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
26.12.2013, 21:26:32
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513621
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов РустамВо-первых, я не уверен, что такая оптимизация вообще есть (и думаю, что её нет).Да как это ?! ну очевидно же, что незачем анализировать строку, если её длина МЕНЬШЕ длины шаблона блин!
Гаджимурадов РустамВо-вторых, она возможна только для литералов, но невозможна для параметров.
Тебя конкретно эта "оптимизация" интересует (тогда нужно про неё и спрашивать)
или разница в технике операторов LIKE и NOT LIKE ?А почему это для параметров невозможно ? Вот есть ХП, в неё прилетел какой-то там параметр - он же конкретное значение в рантайме будет иметь. Ну, и... чем отличается это от случая, когда явный литерал будет задан ? "План" выполнения тут не надо составлять, просто берём строки и сравниваем.
Короче, интересует прежде всего вот что:
1) LIKE - он способен сразу откидывать строку без рассмотрения или нет ?
2) действительно ли LIKE останавливается и выдаёт результат при обнаружении совпадения с шаблоном ? или лезет дальше, до конца строки ?
...
Рейтинг: 0 / 0
26.12.2013, 21:35:22
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513649
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидочевидно же, что незачем анализировать строку, если её длина МЕНЬШЕ длины шаблона блин!Та ты шо ?
А сравни-ка мне
Код: sql
1.
'Таблоид чепуху говорит' LIKE '%Таблоид%че%пу%ху%го%во%рит%'
...
Рейтинг: 0 / 0
26.12.2013, 22:24:01
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513651
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидNOT like трудится дольше. И чем длиннее строка, тем сильнее различие.Тоже чепуха.
Ты сравнил 2 числа, попал пальцем в ... никуда, и сделал из этого выводы
...
Рейтинг: 0 / 0
26.12.2013, 22:26:29
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513655
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> Да как это ?! ну очевидно же, что незачем анализировать
Таблоид> строку, если её длина МЕНЬШЕ длины шаблона блин!

Это от шаблона зависит. В случае s1 like %s2%
и s2 заведомо больше s1 - да, но для этого надо
саму s1 знать, а типы данных могут быть разные,
плюс нуллы, плюс БЛОБы. Т.е. когда унутрях
дойдёт до сравнения строк, то бишь s3 cmp s4 -
побайтного сравнения не будет, конечно, но,
думаю, это уже *TL-код, а не FB.

> 1) LIKE - он способен сразу откидывать строку без рассмотрения или нет ?
> 2) действительно ли LIKE останавливается и выдаёт результат при обнаружении
> совпадения с шаблоном ? или лезет дальше, до конца строки ?

1. Теоретически - способен в некоторых случаях.
2. Лично я вопрос не понял. Никто не останавливается,
like - это boolen-предикат, который работает так же, как
и все остальные boolean-предикаты.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
26.12.2013, 22:31:00
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513674
fd00ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fd00ch
Участник
hvladТа ты шо ?
А сравни-ка мне
Код: sql
1.
'Таблоид чепуху говорит' LIKE '%Таблоид%че%пу%ху%го%во%рит%'

думаю, вопрос не настолько примитивен был)) искомая строка из лайка, по идее, должна преобразоваться парсером в конечный автомат - набор вызовов StartsText, ContainsText, EndsText, объединенных логическим умножением. если при проверке хотя бы одной из функции вышло False - нет смысла проходить все последующие ступени. если перед выполнением очередной функции оставшаяся длина тестируемой строки меньше, чем длина искомой подстроки (и кодировка не содержит непотребностей в виде суррогатных пар) - нет смысла проходить и текущую ступень.

ну а уж чтобы сканить строку до конца, когда автомат отработал и вернул True - тут я не знаю, как надо "постараться"))
...
Рейтинг: 0 / 0
26.12.2013, 23:12:04
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513677
fd00ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fd00ch
Участник
интересен вопрос: если поиск идет в блобе, который занимает несколько страниц, и шаблон находится в первых страницах - блоб все равно будет считан полностью или только до первого вхождения?
...
Рейтинг: 0 / 0
26.12.2013, 23:15:18
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513684
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
fd00ch> блоб все равно будет считан полностью ... ?

Да, AFAIK.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
26.12.2013, 23:26:52
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513694
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
fd00chдумаю, вопрос не настолько примитивен былА я вот - не думаю. Я читаю вопрос и на него отвечаю.

fd00chискомая строка из лайка, по идее, должна преобразоваться парсером в конечный автоматRTFM: Knuth-Morris-Pratt algorithm
...
Рейтинг: 0 / 0
26.12.2013, 23:50:16
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513695
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
fd00chинтересен вопрос: если поиск идет в блобе, который занимает несколько страниц, и шаблон находится в первых страницах - блоб все равно будет считан полностью или только до первого вхождения?Если шаблон полностью исчерпан, то поиск останавливается. Блоб дочитываться не будет.
...
Рейтинг: 0 / 0
26.12.2013, 23:51:08
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513734
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladА сравни-ка мне
Код: sql
1.
'Таблоид чепуху говорит' LIKE '%Таблоид%че%пу%ху%го%во%рит%'

Ах, вот ты как... :-)
Тогда уточню правило: если хотя бы одно из "слов" шаблона имеет char_length() больше, чем длина фактически хранимых в поле символов, то сопоставлять бестолку. Под "словами" понимаю лексемы, разделённые метасимволами `%` и `_`.

Контрпример будет ?

PS. Пока что есть смутное сомнение, что LIKE не учитывает макс. длину слова внутри шаблонов.
 
1. buf = 256
Код: 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.
SQL> recreate table t(s varchar(20)); commit;
SQL> insert into t select 'Lorem ipsum dolor' 
CON> from rdb$types,rdb$types,(select 1 r from rdb$types rows 20); commit;
SQL> out nul; select count(s) from t; out; -- вычитка
SQL> set stat on;
SQL> select count(s) from t;

       COUNT
============
     1039680

Current memory = 1868244
Delta memory = 0
Max memory = 2440708
 Elapsed time= 1.93 sec 
Buffers = 256
Reads = 16805
Writes 0
Fetches = 2112939
SQL>
SQL> select count(s) from t where s like '% LoremipsumdolorLoremipsum % dolor %';

       COUNT
============
           0

Current memory = 1869820
Delta memory = 1576
Max memory = 2440708
 Elapsed time= 2.61 sec 
Buffers = 256
Reads = 16805
Writes 0
Fetches = 2112939

2. buf = 65000 (#FileSystemCacheThreshold = 65536)
Код: 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.
isql -c 65000 T0.FDB
Database:  T0.FDB
SQL> out nul; select count(s) from t; out; -- вычитка

SQL> set stat on;
SQL> select count(s) from t;

       COUNT
============
     1039680

Current memory = 280929412
Delta memory = 0
Max memory = 281000168
 Elapsed time= 1.70 sec 
Buffers = 65000
Reads = 0
Writes 0
Fetches = 2112939
SQL>
SQL> select count(s) from t where s like '% LoremipsumdolorLoremipsum % dolor %';

       COUNT
============
           0

Current memory = 280942552
Delta memory = 13140
Max memory = 281000168
 Elapsed time= 2.45 sec 
Buffers = 65000
Reads = 6
Writes 0
Fetches = 2112971
...
Рейтинг: 0 / 0
27.12.2013, 01:10:49
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513737
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидNOT like трудится дольше. И чем длиннее строка, тем сильнее различие.Тоже чепуха.
Ты сравнил 2 числа, попал пальцем в ... никуда, и сделал из этого выводыОга
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SQL> select count(s) from t where s like '%LoremipsumdolorLoremipsum%dolor%';

       COUNT
============
           0
. . .
Elapsed time=  2.44 sec 
Buffers = 65000
. . .
SQL> select count(s) from t where s  NOT  like '%LoremipsumdolorLoremipsum%dolor%';

       COUNT
============
     1039680
. . .
Elapsed time=  2.70 sec 
Buffers = 65000
...
Рейтинг: 0 / 0
27.12.2013, 01:13:50
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513741
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ТаблоидПока что есть смутное сомнение, что LIKE не учитывает макс. длину слова
внутри шаблонов.
Естественно не учитывает, поскольку поиск по длинному шаблону в коротких данных смысла не
имеет. А те мизерные доли процента пользователей, которые маются такой фигнёй, рояля не
играют.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.12.2013, 01:16:46
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513745
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов РустамЭто от шаблона зависит. В случае s1 like %s2%
и s2 заведомо больше s1 - да, но для этого надо
саму s1 знать, а типы данных могут быть разные,
плюс нуллы, плюс БЛОБы. Т.е. когда унутрях
дойдёт до сравнения строк , то бишь s3 cmp s4 -
побайтного сравнения не будет, конечно, но,
думаю, это уже *TL-код, а не FB.Не, погодь! я как раз и говорю: существуют случаи, когда сравнивать НЕ НУЖНО. Если известно, конечно же, фактическое число символов, хранимое в строке (см выше, однократно - перед началом подсчета - определяется число символов в самом длинном "слове" в шаблоне).
Про варчары и блобы - отчётливо помню, что тут говорилось: ФБ *знает* число символов в таких полях.
Про то, что такое-то поле содержит нулл - тем более знает.

Гаджимурадов Рустам> 2) действительно ли LIKE останавливается и выдаёт результат при обнаружении
> совпадения с шаблоном ? или лезет дальше, до конца строки ?

2. Лично я вопрос не понял. Никто не останавливается,
like - это boolen-предикат, который работает так же, как
и все остальные boolean-предикаты.я не про пробегание "вниз по строкам" , это понятно всё. Я про работу алгоритма самого LIKE: вот он движется вдоль строки , находит первое соотв-вие - и дальше остановиться должен, выдав для этой строки TRUE.
...
Рейтинг: 0 / 0
27.12.2013, 01:20:17
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513751
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

давай ты сначала научишься учитывать все факторы , а потом я буду смотреть на твои примеры.
...
Рейтинг: 0 / 0
27.12.2013, 01:22:03
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513754
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovТаблоидПока что есть смутное сомнение, что LIKE не учитывает макс. длину слова
внутри шаблонов.
Естественно не учитывает, поскольку поиск по длинному шаблону в коротких данных смысла не
имеет. А те мизерные доли процента пользователей, которые маются такой фигнёй, рояля не
играют.Они (данные) не во всех записях такие короткие! У мну поле в этом примере = варчар(20), а могло бы быть и варчар(2000). Посмотри в первый пост: там всё начинается с `q`, а заканчивается `qwertyuiop`.
Или возьми справочник контрагентов, когда в нём и физлица и юрики. Какой смысл сопоставлять шаблон "%АДМИНИСТРАЦ%ЯРОСЛАВСК%ПРЕДСТАВ%" с челами типа "ПЕТРОВ" или "КУЗНЕЦОВ" (а таких там - прорва!) ?
Мысль понятна, надеюсь.
...
Рейтинг: 0 / 0
27.12.2013, 01:24:15
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513757
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladдавай ты сначала научишься учитывать все факторы , а потом я буду смотреть на твои примеры.Какие "все факторы" не учтены сейчас ?
...
Рейтинг: 0 / 0
27.12.2013, 01:25:50
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513769
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидhvladдавай ты сначала научишься учитывать все факторы , а потом я буду смотреть на твои примеры.Какие "все факторы" не учтены сейчас ?Твоя версия ?
...
Рейтинг: 0 / 0
27.12.2013, 02:04:02
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513770
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> PS. Пока что есть смутное сомнение, что LIKE
Таблоид> не учитывает макс. длину слова внутри шаблонов

Создавал ты топик с уверенностью, что учитывает.

Таблоид> Я про работу алгоритма самого LIKE: вот он движется
Таблоид> вдоль строки, находит первое соотв-вие - и дальше
Таблоид> остановиться должен, выдав для этой строки TRUE.


Ну так и делает (наверное - не проверял).
Как и любой другой boolean-предикат.

Таблоид> Они (данные) не во всех записях такие короткие!
Таблоид> Какой смысл

Начинается. Вроде бы, изначально речь шла о полях таблицы
(по крайней мере, мне так показалось), а не о конкретных записях.
А смысл... с практической т.з. смысла в том, что ты предлагаешь
особого нет - ну да, оптимизация, да, в условном 1% случаев
кому-то поможет (если такие как ты ещё есть). :)

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.12.2013, 02:04:44
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513772
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидКакой смысл сопоставлять шаблон...А что ты выигрываешь ? 1 сек на 10млн записей ?
...
Рейтинг: 0 / 0
27.12.2013, 02:05:18
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513910
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидпропущено...Какие "все факторы" не учтены сейчас ?Твоя версия ?А я первый тебя спросил :-)

hvladА что ты выигрываешь ? 1 сек на 10млн записей ? В этом (тривиальном) варианте - да. А что будет при проверке более длинного шаблона и наличии аттачей-конкурентов - кто ж его знает.
...
Рейтинг: 0 / 0
27.12.2013, 09:54:53
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38513915
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов Рустам с практической т.з. смысла в том, что ты предлагаешь особого нет - ну да, оптимизация, да, в условном 1% случаев кому-то поможет (если такие как ты ещё есть). :)т.е. по шаблонам, состоящим из "слов" длиннее 10 символов, уже не ищут, что ле ? Экзотика ?
...
Рейтинг: 0 / 0
27.12.2013, 09:57:22
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514089
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидА я первый тебя спросил :-)Ну так первый и ответь. Если оно тебе надо.

ТаблоидА что будет при проверке более длинного шаблона и наличии аттачей-конкурентов - кто ж его знает.Ну да, конкуренты мешают вычислять like.

PS Займись уже чем-нить реально полезным...
...
Рейтинг: 0 / 0
27.12.2013, 12:23:52
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514096
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

лучше попроси у Влада сборку или патч, где страницы выделяются экстентами (о чём он написал в firebird.devel). Там есть что потестировать.
...
Рейтинг: 0 / 0
27.12.2013, 12:29:29
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514104
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Симонов Денис,

она у него есть :)
Но ему же важнее 2 микросекунды в like'е найти
...
Рейтинг: 0 / 0
27.12.2013, 12:34:58
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514110
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
hvlad,

а мне можно? Я в fbdevel вроде написал, что хочу потестить.
...
Рейтинг: 0 / 0
27.12.2013, 12:37:46
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514123
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Симонов Денисhvlad,

а мне можно? Я в fbdevel вроде написал, что хочу потестить.Я видел твоё письмо, на выходных соберу и выложу бинарники.
А у Tabloid'а - патч и он собирает себе сам.
...
Рейтинг: 0 / 0
27.12.2013, 12:47:11
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514289
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladНу да, конкуренты мешают вычислять like.Ну, немного, конечно же, но таки да: мешают :-)
Вот статистика для того же хоста, когда на нём 250 dml-молотилок издеваются над известной тебе базой idx_under_load.
 
Код: 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.
SQL> set stat on;
SQL> select count(s) from td where s like '%qwertyuiop%';

                COUNT
=====================
              1000000

Current memory = 2763107488
Delta memory = 167184
Max memory = 2766156256
Elapsed time= 8.84 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 54
Writes = 4558
Fetches = 20762024
SQL>
SQL> select count(s) from td where s NOT like '%qwertyuiop%';

                COUNT
=====================
              9000000

Current memory = 2763428488
Delta memory = -309744
Max memory = 2766156256
Elapsed time= 9.84 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 72
Writes = 4304
Fetches = 20672085
SQL>
SQL> select count(s) from td where s like '%q%';

                COUNT
=====================
             10000000

Current memory = 2763755936
Delta memory = -1313368
Max memory = 2775462040
Elapsed time= 9.30 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 83
Writes = 6600
Fetches = 21011277
SQL>
SQL> select count(s) from td where s NOT like '%q%';

                COUNT
=====================
                    0

Current memory = 2764691240
Delta memory = 751192
Max memory = 2775462040
Elapsed time= 9.35 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 103
Writes = 6634
Fetches = 21005441
SQL>

hvladPS Займись уже чем-нить реально полезным...0xFF. я вчера собирал ФБ с сырцов. Твой патч на экстенты (см аттач) - применяется без ошибок (пока --dry-run). Но я забыл: в нём есть эти самые "перепутанные строки" или нет ? И если есть, то покажи, плз, где они.

Модератор: Вложение удалено.
...
Рейтинг: 0 / 0
27.12.2013, 14:36:58
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514379
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

1. ты не перепутал частное мыло с общим форумом ?
2. я разве давал своё согласие на публикацию этого патча ?
3. это не тот патч
4. нет слов
...
Рейтинг: 0 / 0
27.12.2013, 15:50:46
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514413
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид,

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

p.s. из лучших побуждений.
...
Рейтинг: 0 / 0
27.12.2013, 16:10:32
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514478
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
kdv,

не бей его, я сам (аккуратно и нежно) :)
...
Рейтинг: 0 / 0
27.12.2013, 16:46:25
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514485
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
в принудительный отпуск его срочно, куда-нить на Колыму подальше ;-)
...
Рейтинг: 0 / 0
27.12.2013, 16:48:28
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514532
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоид,2. я разве давал своё согласие на публикацию этого патча ?пффф......
2 ip /ws: удалите нахрен плз мой пост!...
2 hvlad: откудова я знал, что его нельзя сюда выпостить ? тем более, ты сказал, что бинарники с этим же функционалом выложишь...

ps. смягчающим обст-вом для себя вижу только одно: собирателей из сырцов тут, на скл.ру, меньше, чем пальцев на руках и ногах. Авось, не увидят :-)
...
Рейтинг: 0 / 0
27.12.2013, 17:32:55
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514538
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrв принудительный отпуск его срочно, куда-нить на Колыму подальше ;-)0xFF.
 
я и так на Колыме сижу. До центра моцквы добираюсь теперь полтора часа (когда дождя/снега нет), до работа - два с половиной. А из ДП самолёт вроде как 40 минут летит ?
Так что не надо "ля-ля", всех не перевешаете! :-)
...
Рейтинг: 0 / 0
27.12.2013, 17:36:11
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514547
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидоткудова я знал, что его нельзя сюда выпоститьДело не в зя\низя. И не в конкретном патче.
Ну неужели взрослым людям нужно рассказывать банальности про этику, про частную переписку и её отличие от публичного общения ?
...
Рейтинг: 0 / 0
27.12.2013, 17:42:37
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514569
Фотография wadman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wadman
Участник
У меня дежавю...
...
Рейтинг: 0 / 0
27.12.2013, 17:56:31
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514578
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
wadmanУ меня дежавю...чё там ? рассказывай...
...
Рейтинг: 0 / 0
27.12.2013, 18:05:11
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514584
Фотография wadman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wadman
Участник
ТаблоидwadmanУ меня дежавю...чё там ? рассказывай...
По поводу лайк и длины строки.
...
Рейтинг: 0 / 0
27.12.2013, 18:06:55
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514590
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
wadmanПо поводу лайк и длины строки.да блин... тынц давай, чего огородами ходишь! :-)
...
Рейтинг: 0 / 0
27.12.2013, 18:11:33
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514605
Фотография wadman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wadman
Участник
ТаблоидwadmanПо поводу лайк и длины строки.да блин... тынц давай, чего огородами ходишь! :-)
Был-бы тынц, я-бы не дежавю написал, а баян. Но в памяти почему-то именно фб касается.
...
Рейтинг: 0 / 0
27.12.2013, 18:21:57
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514608
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
wadmanПо поводу лайк и длины строки.Это не о том, ли, что в параметр нельзя всунуть больше символов, чем есть в поле ?
...
Рейтинг: 0 / 0
27.12.2013, 18:27:59
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514611
Фотография wadman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wadman
Участник
hvladwadmanПо поводу лайк и длины строки.Это не о том, ли, что в параметр нельзя всунуть больше символов, чем есть в поле ?
Про параметры было на скуле, точно помню. Но у меня дежавю вызвал твой пример с лайками и с %. Грубо говоря, это пустой холивар.
...
Рейтинг: 0 / 0
27.12.2013, 18:32:13
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514615
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
wadmanГрубо говоря, это пустой холивар.Не может быть ! А как же 1 сек\10млн записей ? Это же катастрофа !
...
Рейтинг: 0 / 0
27.12.2013, 18:37:17
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514618
Фотография wadman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wadman
Участник
hvladwadmanГрубо говоря, это пустой холивар.Не может быть ! А как же 1 сек\10млн записей ? Это же катастрофа !
За то пообщались душевно. :)
...
Рейтинг: 0 / 0
27.12.2013, 18:43:40
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514630
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
wadmanБыл-бы тынця все заголовки своих топегов давно в эксель вытаскиваю отсюда, тупым копипастом. Когда не могу найти гуглом, то просто начинаю просматривать обычным поиском в этом экселе, по Упр-Фе. Чаще всего помогает.
...
Рейтинг: 0 / 0
27.12.2013, 19:04:04
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514711
fd00ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fd00ch
Участник
Таблоид, нажать вверху страницы ссылку авторТемы: [ избранные, мои , участ.]не помогает?
...
Рейтинг: 0 / 0
27.12.2013, 20:51:42
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514716
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
fd00chТаблоид, нажать вверху страницы ссылку авторТемы: [ избранные, мои , участ.]не помогает?не сильно. много там чего-то накопилось (за бесцельно прожитые годы :-)), а поиск на этому форуме - не самая сильная его сторона.
...
Рейтинг: 0 / 0
27.12.2013, 21:04:40
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514728
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
hvladне бей его, я сам (аккуратно и нежно)
я не бью. просто я знал и знаю несколько людей вот с такими "нервами", с одной стороны это смешно, если смотреть с точки зрения серии Футурамы про то, как
YouTube Video
YouTube Video
...
Рейтинг: 0 / 0
27.12.2013, 21:21:38
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514752
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Так-с. "продолжаем разговор!" (С) :-)
Тут вылезло вот еще что: на произв-сть влияет декларированная длина varchar-поля.
Выше были цветочки, там варчар(50). А вот что получается для ягодок, когда варчар(32760).
DDL:
 
Код: 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.
commit;
recreate table td(id int, s varchar(32760)); commit;
set term ^;
execute block as
begin
  begin
    execute statement 'create sequence g';
    when any do begin end
  end
end^
set term ;^
commit;
alter sequence g restart with 0;
commit;

set term ^;
execute block as
declare n int = 1000000;
declare m int;
begin
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'q' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qw' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwe' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwer' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwert' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwerty' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwertyu' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwertyui' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwertyuio' ) returning :m-1 into m;
m=n; while(m>0) do insert into td(id, s) values( gen_id(g,1), 'qwertyuiop' ) returning :m-1 into m;
end^ set term ;^ commit;
(ждать - задолбался, минут 5-7 на сильном серваке молотило; при том, что предварительно было сделано gfix -w async; размер файла в итоге = 5593 Mb).

Дальше - то же самое.
Вычитка:
SQL> set stat on;
 
46 sec
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SQL> out nul; select count(s) from td; out;
Current memory = 2498097104
Delta memory = -6168
Max memory = 2527625632
Elapsed time= 45.99 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 1430580
Writes = 0
Fetches = 22860311
И теперь повторяем забег:
Код: 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.
SQL> select count(s) from td where s like '%q%';

                COUNT
=====================
             10000000

Current memory = 2498102392
Delta memory = 5288
Max memory = 2527625632
Elapsed time= 50.45 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 1430580
Writes = 0
Fetches = 22860311
SQL> select count(s) from td where s NOT like '%q%';

                COUNT
=====================
                    0

Current memory = 2498103256
Delta memory = 864
Max memory = 2527625632
Elapsed time= 49.75 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 1430580
Writes = 0
Fetches = 22860311

Сначала я думкал, что он тратит время на "паддинг" до 32760, когда считывает в память строки, а не на сам LIKE.
Но вот что получается при обычном execute block'e, когда строка уже предварительно создана с замыкающими пробелами - тут вообще к базе обращений нету:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
set stat on;
set term ^;
execute block returns(cnt int) as
declare n int = 10000000;
declare s varchar( 32760 );
begin
  cnt=0;
  s=rpad('q',32760,' ');
  while (n>0) do begin
    cnt = cnt + iif( s like '%q%', 1, 0);
    n=n-1;
  end
  suspend;
end^
set term ;^
set stat off;

output:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Current memory = 2450596208
Delta memory = 390320
Max memory = 2450628912
 Elapsed time= 34.18 sec 
Cpu = 0.00 sec
Buffers = 524288
Reads = 16
Writes = 0
Fetches = 37
SQL> set term ;^
SQL> set stat off;

=== vs ===

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
set stat on;
set term ^;
execute block returns(cnt int) as
declare n int = 10000000;
declare s varchar( 50 );
begin
  cnt=0;
  s=rpad('q',50,' ');
  while (n>0) do begin
    cnt = cnt + iif( s like '%q%', 1, 0);
    n=n-1;
  end
  suspend;
end^
set term ;^
set stat off;

output:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
Current memory = 2450530424
Delta memory = -65784
Max memory = 2450628912
 Elapsed time= 6.68 sec 
Cpu = 0.00 sec
Buffers = 524288
Reads = 0
Writes = 0
Fetches = 2

И почти то же самое время, когда строка имеет длину = 1 байт (что также странно!):
 
Код: 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.
SQL> set stat on;
SQL> set term ^;
SQL> execute block returns(cnt int) as
CON> declare n int = 10000000;
CON> declare s varchar(1);
CON> begin
CON>   cnt=0;
CON>   s='q'; --rpad('q',1,' ');
CON>   while (n>0) do begin
CON>     cnt = cnt + iif( s like '%q%', 1, 0);
CON>     n=n-1;
CON>   end
CON>   suspend;
CON> end^
set term ;^
set stat off;

         CNT
============
    10000000

Current memory = 2450526032
Delta memory = -4392
Max memory = 2450628912
Elapsed time= 6.61 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 0
Writes = 0
Fetches = 0
SQL> set term ;^
SQL> set stat off;
В воздухе витает нехороший вывод. Строка начинается с `q`, дальше только пробелы. Шаблон сравнения - '%q%`. Это значит, что LIKE должен был прекращать разбор строки НЕЗАВИСИМО от её длины сразу после того, как увидит ПЕРВЫЙ символ.
Но тут как-то не видно "независимости" этой.

0xFF. И чего это файл так взбух при варчаре 32760 ? там несжимаемый заголовок записи вырос или чего ?
...
Рейтинг: 0 / 0
27.12.2013, 21:48:02
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514755
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvС другой стороны это адский угар, в том смысле что руки опережают мозг, и совершенно явно нужно как-то притормозить.блин, ну покаялся я ужо перед Владом (в личке), чего еще-то ? нехрена было вообще разговор про эти экстенты тут заводить... :-)
kdvС третьей стороны, я же видел Таблоида очно (Павел, извини, что о тебе в третьем лице), и "невротиком" я бы его не назвал.дык я вообще не волнуюсь ни об чём... давно как бэ...
...
Рейтинг: 0 / 0
27.12.2013, 21:50:30
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514757
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидElapsed time= 49.75 sec
Buffers = 524288
Reads = 1430580


Disk transfer rate, mb/s = (Reads * PageSize)/1024/1024/ElapsedTime

если я не ошибся, и у тебя размер страницы 16к, то тогда скорость будет 447 мегабайт в секунду. Тебе мало? Это скорость raid 1 или raid 10 с SSD, или хорошего raid 10 на hdd.
Если 8 к, то тогда 223 мегабайта в секунду. Это скорость среднего RAID 10 на hdd.

Сделай select count (*) from td
и сравни с твоими селект каунтами и like.

p.s. все познается в сравнении.
...
Рейтинг: 0 / 0
27.12.2013, 21:54:56
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514760
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид,

заодно учитывай, что при повторном выполнении запросов будет работать кэш ОС (в плане опережающего чтения, или prefetch, или как оно там).
...
Рейтинг: 0 / 0
27.12.2013, 21:57:35
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514765
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvТаблоидElapsed time= 49.75 sec
Buffers = 524288
Reads = 1430580


Disk transfer rate, mb/s = (Reads * PageSize)/1024/1024/ElapsedTime

если я не ошибся, и у тебя размер страницы 16к, то тогда скорость будет 447 мегабайт в секунду. Тебе мало? Это скорость raid 1 или raid 10 с SSD, или хорошего raid 10 на hdd.а причём тут конкретные цифирки про скорость в ДАННОМ замере ? я сравниваю LIKE для строк *с* и *без* завершающих пробелов, причём шаблон и сама строка такова, что поиск по LIKE должен завершаться немедленно на каждой итерации: там ПЕРВЫМ символом идёт как раз тот, что в шаблоне.
И погляди, какое различие лезет. Чем объяснишь ?


kdvЕсли 8 к, то тогда 223 мегабайта в секунду. Это скорость среднего RAID 10 на hdd.

Сделай select count (*) from td
и сравни с твоими селект каунтами и like.

p.s. все познается в сравнении.ну сделал:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SQL> set stat on; select count (*) from td;

                COUNT
=====================
             10000000

Current memory = 2450777544
Delta memory = 251512
Max memory = 2450847176
Elapsed time= 8.33 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 1431185
Writes = 0
Fetches = 22860497
Что мне с этого каунта, когда он саму строку не вычитывает ? он же только заголовок записи читает там.
...
Рейтинг: 0 / 0
27.12.2013, 22:01:31
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514767
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvпри повторном выполнении запросов будет работать кэш ОС (в плане опережающего чтения, или prefetch, или как оно там).я по ТРИ раза делал каждый запрос. Статистика приведена в каждом случае для третьего прогона.
...
Рейтинг: 0 / 0
27.12.2013, 22:02:10
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514770
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидЧто мне с этого каунта, когда он саму строку не вычитывает ? он же только заголовок записи читает там.
с этого каунта ты понимаешь скорость голой вычитки записей/версий, и можешь сравнить ее с "накладными расходами" на сравнение like, not like и т.д. Ну ей-богу, это элементарные же вещи :-)
...
Рейтинг: 0 / 0
27.12.2013, 22:07:42
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514775
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоидя по ТРИ раза делал каждый запрос. Статистика приведена в каждом случае для третьего прогона.
не везде. Вот тут 15357511 у тебя

"повторяем забег"
Buffers = 524288
Reads = 1430580

то есть непонятно, в таблице 1430к страниц, или 1950к страниц. Нужен первый select count, а еще лучше с кэшем в 1024 например. Ну в общем, именно чтобы понять скорость вычитки с диска, с кэшем ОС, и так далее. Потом уже можно "троекратно" экспериментировать со всякими условиями.
...
Рейтинг: 0 / 0
27.12.2013, 22:11:13
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514781
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvТаблоидЧто мне с этого каунта, когда он саму строку не вычитывает ? он же только заголовок записи читает там. с этого каунта ты понимаешь скорость голой вычитки записей/версий, и можешь сравнить ее с "накладными расходами" на сравнение like, not like и т.д. Ну ей-богу, это элементарные же вещи :-)Кхе! ясен пень, что при наличии предиката where s like '%q' будут возникать "доп. расходы" (по сравнению с отсутствием оного).
Интересует причина, по которой на скорость LIKE влияет число символов в строке, при том что сама строка и шаблон таковы, что поиск должен был прекратиться уже на первом символе:
Код: plaintext
1.
строка:  'q________________________. . .________________'
шаблон: '%q%'

Спрашивается: как может на скорость LIKE влиять "хвост" из 100500 млн символов, если матчер увидит TRUE уже на первом символе ? И действия с базой (дисковый IO) тут вообще не причём, вроде бы: это и в execute block'e видно, где в базу никто не лезет. Посмотри выше , плз.
...
Рейтинг: 0 / 0
27.12.2013, 22:16:56
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514784
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvто есть непонятно, в таблице 1430к страниц, или 1950к страниц. в базе - вот:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
TD (128)
    Primary pointer page: 200, Index root page: 201
    Total formats: 1, used formats: 1
    Average record length: 528.50, total records: 10000000
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 32770.00, compression ratio: 62.01
    Pointer pages: 1583, data page slots:  1'428'572 
    Data pages:  1'428'572 , average fill: 94%
    Primary pages: 1428572, full pages: 1428571, swept pages: 0
    Fill distribution:
         0 - 19% = 0
        20 - 39% = 0
        40 - 59% = 1
        60 - 79% = 0
        80 - 99% = 1428571
Из-за того, что был фулл-скан, страницы в кеше не удерживались: сработала защита от вытеснения этим фулл-сканом других данных, которые могли бы оказаться там в результате "более полезных" запросов.

ЗЫ. А откудова он берёт вот это: Average record length: 528.50 - я не понял.
...
Рейтинг: 0 / 0
27.12.2013, 22:22:30
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514793
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
понднимаю топег.
народ, ура! Источники Света починили в трёшке mon$-запросы, теперь взлёт ракеты просто:
Код: 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.
 
 
 query [code=plaintext]SQL>     select
CON>       current_time dts
CON>       -- mon$attachments:
CON>       ,cast(row_number()over(order by mon$attachment_id) as char(3)) rn
CON>       ,a.mon$remote_address remote_IP
CON>       ,a.mon$attachment_id attach_id
CON>       ,a.mon$user mon_user
CON>       ,a.mon$stat_id       stat_id
CON>       ,a.mon$server_pid    server_PID
CON>       ,a.mon$remote_pid    remote_PID
CON>       -- mon$memory_usage:
CON>       ,u.mon$memory_used used_memory
CON>       ,u.mon$memory_allocated alloc_by_OS
CON>       -- mon$io_stats:
CON>       ,i.mon$page_reads reads
CON>       ,i.mon$page_writes writes
CON>       ,i.mon$page_fetches fetches
CON>       ,i.mon$page_marks marks
CON>       -- mon$record_stats:
CON>       ,r.mon$record_seq_reads seq_reads
CON>       ,r.mon$record_idx_reads idx_reads
CON>       ,r.mon$record_inserts ins_cnt
CON>       ,r.mon$record_updates upd_cnt
CON>       ,r.mon$record_deletes del_cnt
CON>       ,r.mon$record_backouts bk_outs
CON>       ,r.mon$record_purges purges
CON>       ,r.mon$record_expunges expunges
CON>       -- aux info:
CON>       ,right(a.mon$remote_process,30) remote_process
CON>       -- mon$statements:
CON>       --,left(cast(s.mon$sql_text as varchar(32760)),50) sql_txt
CON>     from mon$attachments a
CON>     --left join mon$statements s on a.mon$attachment_id = s.mon$attachment_id
CON>     left join mon$memory_usage u on a.mon$stat_id=u.mon$stat_id
CON>     left join mon$io_stats i on a.mon$stat_id=i.mon$stat_id
CON>     left join mon$record_stats r on a.mon$stat_id=r.mon$stat_id
CON>     where
CON>     --a.mon$state=1 and
CON>     a.mon$attachment_id<>current_connection
CON>     --order by a.mon$attachment_id
CON> ;

Current memory = 3030337752
Delta memory = 15434792
Max memory = 3149496984
Elapsed time= 0.75 sec
Cpu = 0.00 sec
Buffers = 524288
Reads = 13
Writes = 570
Fetches = 1425859
(при том, что сейчас на этой базе молотит 450 зверских DML'ек)
...
Рейтинг: 0 / 0
27.12.2013, 22:32:03
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514797
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
пардон, обшибся топегом.
Это я вот сюда хотел:
http://www.sql.ru/forum/1049076/nagruzochnyy-test-300-isql-vsegda-rabotavshiy-mon-zapros-stal-valit-svoy-zhe-konnekt
...
Рейтинг: 0 / 0
27.12.2013, 22:33:56
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514802
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоидесли матчер увидит TRUE уже на первом символе
Ничего о не увидит, пока DPM не прочитает запись, SQZ её не распакует, а INTL не приведёт
всю строку к пригодному к сравнению виду в соответствии с коллейтом.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.12.2013, 22:42:55
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514805
fd00ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fd00ch
Участник
Dimitry SibiryakovНичего о не увидит, пока DPM не прочитает запись, SQZ её не распакует, а INTL не приведёт
всю строку к пригодному к сравнению виду в соответствии с коллейтом.а если строка больше, чем остаток свободной памяти?
...
Рейтинг: 0 / 0
27.12.2013, 22:49:41
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514810
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovТаблоидесли матчер увидит TRUE уже на первом символе
Ничего о не увидит, пока DPM не прочитает запись, SQZ её не распакует, а INTL не приведёт
всю строку к пригодному к сравнению виду в соответствии с коллейтом.а что тогда в случае с execute block'ом, где нет никакой записи и её распаковки ? только INTL там так тупит ?
...
Рейтинг: 0 / 0
27.12.2013, 22:57:10
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514813
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидА откудова он берёт вот это: Average record length: 528.50 - я не понял.
из фактов. Как работает RLE-сжатие, рассказывалось неоднократно.
...
Рейтинг: 0 / 0
27.12.2013, 23:03:26
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514816
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидпочинили в трёшке mon$-запросы
ничего не трогали, ей-богу :-)
...
Рейтинг: 0 / 0
27.12.2013, 23:05:22
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514866
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1068116&msg=15357511 вот что получается при обычном execute block'e, когда строка уже предварительно создана с замыкающими пробелами - тут вообще к базе обращений нету :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
set term ^;
execute block returns(cnt int) as
declare n int = 10000000;
declare s varchar( 32760 );
. . .
Elapsed time=  34.18 sec 

=== vs ===

declare n int = 10000000;
declare s varchar( 50 );
. . .
Elapsed time=  6.68 sec

Решил проверить, что там на яве будет в аналогичном случае (NB: такой же интерпретируемый язык, как и BLR (или как там его)). А именно: будет ли зависеть время выполнения от длины строки.

code:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
import static java.lang.System.*;
import java.util.regex.*;
class MatchesCount {
  public static void main(String[] args) {
    int pad = args.length > 0 ? Integer.parseInt(args[0]) : 32760;
    String s = String.format("%1$-" + pad + "s", "q");
    //out.println("s=>"+s+"<");
    Pattern p = Pattern.compile(".*?q.*?");
    Matcher m;
    int cnt=0;
    long t0 = currentTimeMillis();
    for(int i=0; i < 10000000; i++) {
      m=p.matcher(s);
      cnt += m.find() ? 1 : 0;
    }
    out.println("s.length()="+s.length()+", cnt="+cnt+", done at "+(  currentTimeMillis() - t0 )+" ms");
  }
}



Статистика по запускам:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
D:\JAVA>java MatchesCount 10
s.length()=10, cnt=10000000, done at 5562 ms

D:\JAVA>java MatchesCount
s.length()=32760, cnt=10000000, done at 5860 ms

D:\JAVA>java MatchesCount 256000
s.length()=256000, cnt=10000000, done at 5594 ms

D:\JAVA>java MatchesCount 512000
s.length()=512000, cnt=10000000, done at 5735 ms

А ведь регэкспы, да еще в яве - не самое быстрое оружие. Да, и еще: эта статистика - не на мощном серваке, а на PC-чахотке 2.4 MHz / ram 1 gb.

В общем, "так грустно, что хочется танцевать".
...
Рейтинг: 0 / 0
28.12.2013, 02:44:23
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514884
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
execute block returns(cnt int) as
declare n int = 1000000;
begin
  while (n>0) do
  begin
    select count(*) from T20 where S = 'XXX' into cnt;
    n=n-1;
  end
  suspend;
end


Для S
varchar(20) - 2.8 сек.
varchar(2000) - 3.2 сек.
varchar(32000) - 9.7 сек.
...
Рейтинг: 0 / 0
28.12.2013, 06:29:51
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514886
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
В таблице одна запись.
...
Рейтинг: 0 / 0
28.12.2013, 06:38:18
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514906
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидИнтересует причина, по которой на скорость LIKE влияет число символов в строке
сравнение выполняется в некоей канонической форме, в которую аргументы преобразуются перед сравнением. Для простых случаев каноническое представление может совпадать с исходным, но даже в этом случае исходная строка копируется. Само сравнение реально заканчивается на первом же символе, а вот подготовительные alloc + memcpy наверняка и жрут время в зависимости от длины строки.
...
Рейтинг: 0 / 0
28.12.2013, 11:05:51
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514936
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitr Для простых случаев каноническое представление может совпадать с исходным, но даже в этом случае исходная строка копируется.1) Какова цель такого преобразования, почему сразу нельзя скормить строку и шаблон на поиск соотв-вия ?
2) Можно ли избежать этого копирования в этих простых случаях ? (коих не так уж мало, КМК: запросы вида select * from contragents c where c.name like '%НЕФТ%ГАЗ%' - частые гости любой произв. системы)
...
Рейтинг: 0 / 0
28.12.2013, 12:52:47
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514941
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

1) приведение к виду, позволяющему побайтовый поиск. Для мультибайтовых чарсетов, например.
2) теоретически можно. Пиши трекеру, авось Адриано сподобится этим заняться.
...
Рейтинг: 0 / 0
28.12.2013, 12:59:18
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514958
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоид1) Какова цель такого преобразования, почему сразу нельзя скормить строку и
шаблон на поиск соотв-вия ?
Тебе ведь регистронечувствительный поиск, небось, хочется?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
28.12.2013, 13:46:57
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514961
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovТаблоид1) Какова цель такого преобразования, почему сразу нельзя скормить строку и
шаблон на поиск соотв-вия ?Тебе ведь регистронечувствительный поиск, небось, хочется?..тссс! хочется, да! только никому не говори!
Но это... LIKE в отличие от CONTAINING - он же того, регистроЧувственный как раз.
...
Рейтинг: 0 / 0
28.12.2013, 13:52:59
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514968
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоидон же того, регистроЧувственный как раз.
Даже если выставить CI-коллейт?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
28.12.2013, 14:03:18
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514981
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrПиши трекеру, авось Адриано сподобится этим заняться. Поздравил я его с НГ, пущай почитает.
ЗЫ. Решил сравнить с Большим Братом.
Результат: если строка *И* шаблон объявлены одинаковым образом, то всё пучком, как для varchar2 так и для N varchar2.
 
0.5 sec
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
SH@ao61 14:26:01>declare
  2    n number := 10000000;
  3    s nvarchar2(32000 char);
  4    p nvarchar2(3 char) := '%q%';
  5    --s varchar2(32000);
  6    --p varchar2(3) := '%q%';
  7    cnt number := 0;
  8  begin
  9    s:=rpad('q', 16000);
 10    for i in 1..n loop
 11      if s like p then
 12        cnt := cnt+1;
 13       end if;
 14    end loop;
 15    dbms_output.put_line(cnt);
 16  end;
 17  /
10000000

Elapsed: 00:00:00.51

Но когда строка объявлена как N varchar2, а шаблон не объявлен вообще, а просто указан в LIKE-операторе, то у них там тупить что-то начинает:
 
90 sec!
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SH@ao61 14:04:32>declare
  2    n number := 10000000;
  3    s nvarchar2(4000);
  4    cnt number := 0;
  5  begin
  6    s:=rpad('q', 4000);
  7    for i in 1..n loop
  8      if s like '%q%' then
  9        cnt := cnt+1;
 10       end if;
 11    end loop;
 12    dbms_output.put_line(cnt);
 13  end;
 14  /
10000000

PL/SQL procedure successfully completed.

Elapsed: 00:01:29.90


У нас же ситуация лучше: такой дикой разницы нет.
Если объявить строку *И* шаблон как utf8, то на длине 50 будет:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
set stat on;
set term ^;
execute block returns(cnt int) as
declare n int = 10000000;
declare s varchar(50) character set utf8;
declare p varchar(3) character set utf8;
begin
cnt=0;
s=rpad('q',50,' ');
 p ='%q%';
while (n>0) do begin
  cnt = cnt + iif( s like  p , 1, 0);
  n=n-1;
end
  suspend;
end^
set term ;^
set stat off;
Код: plaintext
Elapsed time= 16.22 sec

А если шаблон просто подсовывать в явном виде:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
set stat on;
set term ^;
execute block returns(cnt int) as
declare n int = 10000000;
declare s varchar(50) character set utf8;
--declare p varchar(3) character set utf8;
begin
cnt=0;
s=rpad('q',50,' ');
--p='%q%';
while (n>0) do begin
  cnt = cnt + iif( s like  '%q%' , 1, 0);
  n=n-1;
end
  suspend;
end^
set term ;^
set stat off;
- то:
Код: plaintext
Elapsed time= 14.20 sec
...
Рейтинг: 0 / 0
28.12.2013, 14:40:55
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514985
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovТаблоидон же того, регистроЧувственный как раз.
Даже если выставить CI-коллейт?..Если указывать явно - да, будет case INsensitive:

Код: plaintext
1.
2.
3.
4.
5.
SQL> with c as (select _utf8 'эхо мацы' s1, _utf8 'Эхо Мацы' s2 from rdb$database)
CON> select s1,s2,iif(s1 collate unicode_ci like s2 collate unicode_ci, 1, 0) r from c;

S1       S2                  R
======== ======== ============
эхо мацы Эхо Мацы            1

Но для этого же containing есть.
...
Рейтинг: 0 / 0
28.12.2013, 14:52:50
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38515412
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
ТаблоидРешил проверить, что там на яве будет в аналогичном случае (NB: такой же интерпретируемый языкУ тебя совесть есть?
Большие киты уже второе тысячелетие пилят "оперативную компиляцию" (just-in-time compiler), а ты - "интерпретируемый".
Сравни с ключом "-int", если уж так хочется потрепаться за интерпретацию.
...
Рейтинг: 0 / 0
29.12.2013, 18:14:53
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38515423
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Basil A. SidorovТаблоидРешил проверить, что там на яве будет в аналогичном случае (NB: такой же интерпретируемый языкУ тебя совесть есть?
Большие киты уже второе тысячелетие пилят "оперативную компиляцию" (just-in-time compiler), а ты - "интерпретируемый".
Сравни с ключом "-int", если уж так хочется потрепаться за интерпретацию.Давай сюда версию своей явы, обе команды (компиляция + запуск) и результаты для коротких и длинных строк - так, как я выше привёл.
У меня такого ключика нет. Вообще.
 
javac -help
Код: 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.
Usage: javac <options> <source files>
where possible options include:
  -g                         Generate all debugging info
  -g:none                    Generate no debugging info
  -g:{lines,vars,source}     Generate only some debugging info
  -nowarn                    Generate no warnings
  -verbose                   Output messages about what the compiler is doing
  -deprecation               Output source locations where deprecated APIs are used
  -classpath <path>          Specify where to find user class files and annotation processors
  -cp <path>                 Specify where to find user class files and annotation processors
  -sourcepath <path>         Specify where to find input source files
  -bootclasspath <path>      Override location of bootstrap class files
  -extdirs <dirs>            Override location of installed extensions
  -endorseddirs <dirs>       Override location of endorsed standards path
  -proc:{none,only}          Control whether annotation processing and/or compilation is done.
  -processor <class1>[,<class2>,<class3>...]Names of the annotation processors to run; bypasses default discovery process
  -processorpath <path>      Specify where to find annotation processors
  -d <directory>             Specify where to place generated class files
  -s <directory>             Specify where to place generated source files
  -implicit:{none,class}     Specify whether or not to generate class files for implicitly referenced files 
  -encoding <encoding>       Specify character encoding used by source files
  -source <release>          Provide source compatibility with specified release
  -target <release>          Generate class files for specific VM version
  -version                   Version information
  -help                      Print a synopsis of standard options
  -Akey[=value]              Options to pass to annotation processors
  -X                         Print a synopsis of nonstandard options
  -J<flag>                   Pass <flag> directly to the runtime system
 
java -help
Код: 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.
Usage: java [-options] class [args...]
           (to execute a class)
   or  java [-options] -jar jarfile [args...]
           (to execute a jar file)

where options include:
    -client       to select the "client" VM
    -server       to select the "server" VM
    -hotspot      is a synonym for the "client" VM  [deprecated]
                  The default VM is client.
                  
    -cp <class search path of directories and zip/jar files>
    -classpath <class search path of directories and zip/jar files>
                  A ; separated list of directories, JAR archives,
                  and ZIP archives to search for class files.
    -D<name>=<value>
                  set a system property
    -verbose[:class|gc|jni]
                  enable verbose output
    -version      print product version and exit
    -version:<value>
                  require the specified version to run
    -showversion  print product version and continue
    -jre-restrict-search | -jre-no-restrict-search
                  include/exclude user private JREs in the version search
    -? -help      print this help message
    -X            print help on non-standard options
    -ea[:<packagename>...|:<classname>]
    -enableassertions[:<packagename>...|:<classname>]
                  enable assertions
    -da[:<packagename>...|:<classname>]
    -disableassertions[:<packagename>...|:<classname>]
                  disable assertions
    -esa | -enablesystemassertions
                  enable system assertions
    -dsa | -disablesystemassertions
                  disable system assertions
    -agentlib:<libname>[=<options>]
                  load native agent library <libname>, e.g. -agentlib:hprof
                    see also, -agentlib:jdwp=help and -agentlib:hprof=help
    -agentpath:<pathname>[=<options>]
                  load native agent library by full pathname
    -javaagent:<jarpath>[=<options>]
                  load Java programming language agent, see java.lang.instrument
    -splash:<imagepath>
                  show splash screen with specified image
...
Рейтинг: 0 / 0
29.12.2013, 18:45:28
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38515425
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
 
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
    -Xmixed           mixed mode execution (default)
   -Xint             interpreted mode execution only
    -Xbootclasspath:<directories and zip/jar files separated by ;>
                      set search path for bootstrap classes and resources
    -Xbootclasspath/a:<directories and zip/jar files separated by ;>
                      append to end of bootstrap class path
    -Xbootclasspath/p:<directories and zip/jar files separated by ;>
                      prepend in front of bootstrap class path
    -Xnoclassgc       disable class garbage collection
    -Xincgc           enable incremental garbage collection
    -Xloggc:<file>    log GC status to a file with time stamps
    -Xbatch           disable background compilation
    -Xms<size>        set initial Java heap size
    -Xmx<size>        set maximum Java heap size
    -Xss<size>        set java thread stack size
    -Xprof            output cpu profiling data
    -Xfuture          enable strictest checks, anticipating future default
    -Xrs              reduce use of OS signals by Java/VM (see documentation)
    -Xcheck:jni       perform additional checks for JNI functions
    -Xshare:off	      do not attempt to use shared class data
    -Xshare:auto      use shared class data if possible (default)
    -Xshare:on	      require using shared class data, otherwise fail.

The -X options are non-standard and subject to change without notice.

Плюс, надо учитывать, что JIT тоже требует времени "на раскочегариться".
Поэтому рекомендуется сначала покрутить тестируемый код секунду-другую и только потом начинать замеры.
...
Рейтинг: 0 / 0
29.12.2013, 18:51:57
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38515491
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Basil A. Sidorov,

чё-то ты мне не то подсказал :-)

Сначала я думкал, что всё взвисло (ЦПУ на 99%), но затем вылезло:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
java -Xint MatchesCount
s.length()=32760, cnt=10000000, done at 93266 ms

java -Xint MatchesCount 10
s.length()=10, cnt=10000000, done at 103203 ms

java -Xint MatchesCount 10
s.length()=10, cnt=10000000, done at 97454 ms
Значение несопоставимо ни с какими воротами, замедлитель какой-то туда всунули. Фтопку его.
Тем более, что Адриано уже взял в разработку этот тикет.
...
Рейтинг: 0 / 0
29.12.2013, 21:01:28
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38516040
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
ТаблоидBasil A. Sidorov,
чё-то ты мне не то подсказал :-)Было заявлено, что ява - интерпретируемый язык.
Теперь тебе известна разница между интерпретацией (-Xint) и компиляцией (-Xmixed, по умолчанию).
...
Рейтинг: 0 / 0
30.12.2013, 16:53:50
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38525272
Cobalt747
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cobalt747
Участник
Таблоид,

Велика ли разница по времени между выборкой всех строк и выборкой по шаблону?
...
Рейтинг: 0 / 0
14.01.2014, 10:27:12
| Ответить | Цитировать | Написать  
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38525486
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Cobalt747Велика ли разница по времени между выборкой всех строк и выборкой по шаблону?а что даст это сравнение ?
...
Рейтинг: 0 / 0
14.01.2014, 12:59:32
| Ответить | Цитировать | Написать  
84 сообщений из 84, показаны все 4 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=40&tid=1563981]:
 0ms
get settings:
 10ms
get forum list:
 12ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 210ms
get topic data:
 9ms
get forum data:
 3ms
get page messages:
 109ms
get tp. blocked users:
 2ms
others: 235ms
total:  598ms
созд. / загр.: 598ms
x
x
Закрыть


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