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 ?
25 сообщений из 84, страница 1 из 4
  1  все
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
| Ответить | Цитировать | Написать  
25 сообщений из 84, страница 1 из 4
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&fpage=105&tid=1563981]:
 0ms
get settings:
 6ms
get forum list:
 14ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 65ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 83ms
get tp. blocked users:
 2ms
others: 212ms
total:  401ms
созд. / загр.: 401ms
x
x
Закрыть


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