powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
25 сообщений из 84, страница 3 из 4
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514755
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvС другой стороны это адский угар, в том смысле что руки опережают мозг, и совершенно явно нужно как-то притормозить.блин, ну покаялся я ужо перед Владом (в личке), чего еще-то ? нехрена было вообще разговор про эти экстенты тут заводить... :-)
kdvС третьей стороны, я же видел Таблоида очно (Павел, извини, что о тебе в третьем лице), и "невротиком" я бы его не назвал.дык я вообще не волнуюсь ни об чём... давно как бэ...
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514757
Фотография 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
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514760
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

заодно учитывай, что при повторном выполнении запросов будет работать кэш ОС (в плане опережающего чтения, или prefetch, или как оно там).
...
Рейтинг: 0 / 0
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
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514767
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvпри повторном выполнении запросов будет работать кэш ОС (в плане опережающего чтения, или prefetch, или как оно там).я по ТРИ раза делал каждый запрос. Статистика приведена в каждом случае для третьего прогона.
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514770
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЧто мне с этого каунта, когда он саму строку не вычитывает ? он же только заголовок записи читает там.
с этого каунта ты понимаешь скорость голой вычитки записей/версий, и можешь сравнить ее с "накладными расходами" на сравнение like, not like и т.д. Ну ей-богу, это элементарные же вещи :-)
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514775
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидя по ТРИ раза делал каждый запрос. Статистика приведена в каждом случае для третьего прогона.
не везде. Вот тут 15357511 у тебя

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

то есть непонятно, в таблице 1430к страниц, или 1950к страниц. Нужен первый select count, а еще лучше с кэшем в 1024 например. Ну в общем, именно чтобы понять скорость вычитки с диска, с кэшем ОС, и так далее. Потом уже можно "троекратно" экспериментировать со всякими условиями.
...
Рейтинг: 0 / 0
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
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
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
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
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514802
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидесли матчер увидит TRUE уже на первом символе
Ничего о не увидит, пока DPM не прочитает запись, SQZ её не распакует, а INTL не приведёт
всю строку к пригодному к сравнению виду в соответствии с коллейтом.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514805
fd00ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovНичего о не увидит, пока DPM не прочитает запись, SQZ её не распакует, а INTL не приведёт
всю строку к пригодному к сравнению виду в соответствии с коллейтом.а если строка больше, чем остаток свободной памяти?
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514810
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидесли матчер увидит TRUE уже на первом символе
Ничего о не увидит, пока DPM не прочитает запись, SQZ её не распакует, а INTL не приведёт
всю строку к пригодному к сравнению виду в соответствии с коллейтом.а что тогда в случае с execute block'ом, где нет никакой записи и её распаковки ? только INTL там так тупит ?
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514813
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА откудова он берёт вот это: Average record length: 528.50 - я не понял.
из фактов. Как работает RLE-сжатие, рассказывалось неоднократно.
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514816
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидпочинили в трёшке mon$-запросы
ничего не трогали, ей-богу :-)
...
Рейтинг: 0 / 0
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
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514884
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
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514886
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В таблице одна запись.
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514906
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидИнтересует причина, по которой на скорость LIKE влияет число символов в строке
сравнение выполняется в некоей канонической форме, в которую аргументы преобразуются перед сравнением. Для простых случаев каноническое представление может совпадать с исходным, но даже в этом случае исходная строка копируется. Само сравнение реально заканчивается на первом же символе, а вот подготовительные alloc + memcpy наверняка и жрут время в зависимости от длины строки.
...
Рейтинг: 0 / 0
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
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514941
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

1) приведение к виду, позволяющему побайтовый поиск. Для мультибайтовых чарсетов, например.
2) теоретически можно. Пиши трекеру, авось Адриано сподобится этим заняться.
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514958
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид1) Какова цель такого преобразования, почему сразу нельзя скормить строку и
шаблон на поиск соотв-вия ?
Тебе ведь регистронечувствительный поиск, небось, хочется?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514961
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоид1) Какова цель такого преобразования, почему сразу нельзя скормить строку и
шаблон на поиск соотв-вия ?Тебе ведь регистронечувствительный поиск, небось, хочется?..тссс! хочется, да! только никому не говори!
Но это... LIKE в отличие от CONTAINING - он же того, регистроЧувственный как раз.
...
Рейтинг: 0 / 0
where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
    #38514968
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидон же того, регистроЧувственный как раз.
Даже если выставить CI-коллейт?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25 сообщений из 84, страница 3 из 4
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / where s LIKE '%txt%' *vs* where s NOT like '%txt%': первое быстрее. Why ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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