ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
25 сообщений из 189, страница 1 из 8
  1  все
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38032991
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all

Дано:
1) Из текущих сырцов собран LI-V2.5.3.26554 (никаких патчей от Источников Света к сырцам не применял).
2) Имеется база с единственной таблицей `t` (id int, s varchar(50), h bigint; поле `id` - индексное), в таблице 1 миллиард записей. Размер базы - 118 Гб.
3) Никаких "фрагментов" файла базы в кеше операционки нет.

Вижу на такой базе несколько удивительных эффектов (все коннекты к базе - через TCP).

ЭКСПЕРИМЕНТ-1.
Запускаю трейс, в другом окне - isql.
Ввожу в isql: select * from t where id = 789456123; (такой ID'шник - существует).
Выборка по индексу единственной записи уходит в себя на... 5 минут.
ДЕ мне объяснил, что это время тратится на "вычитку" PP. Но не многовато ли 5 минут читать эту самую "пэ-пэ" ? Я знаю, что скорость копирования файлов на этой машине ~50 Mb/sec ==> за 300 сек можно скопировать ~15 Gb.
Как примерно определить, сколько места занимает PP ?
Далее, в трейсе вышеприведенный запрос появится только после того, как будет завершена эта самая "вычитка" PP. И там будет некоторое микроскопическое время, которое он якобы делался.
Я понимаю, что трейс на сегодня показывает не все "служебные действия" (sweep только) - но нельзя ли расширить его в этом вопросе ?

ЭКСПЕРИМЕНТ-2.
В первом окне ввожу запрос к таблице `t` на выборку данных (не подсчет строк - а именно выборку полей).
Во втором окне пытаюсь срубить деятельность окна_1 через
Код: sql
1.
commit; delete from mon$statements ...;


Результат: ноль. Окно_1 будет работать, невзирая на все потуги окна_2. Срубить окно_1 можно только через delete from mon$attachments.
Код: 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.
 session #1 
SQL> out /dev/null; set stat on; set plan on;
SQL> select * from t where id between 123456789 and 456789123;

PLAN (T INDEX (T_ID))
-- ушло в себя --

 session #2 
SQL> commit; select * from mon$statements where mon$state<>0 and mon$attachment_id<>current_connection;

MON$STATEMENT_ID                38
MON$ATTACHMENT_ID               49
MON$TRANSACTION_ID              184
MON$STATE                       2
MON$TIMESTAMP                   2012-11-10 17:21:00.8280
MON$SQL_TEXT                    0:4
select * from t where id between 123456789 and 456789123
MON$STAT_ID                     7


SQL> commit; delete from mon$statements where mon$attachment_id<>current_connection;
SQL> commit; select * from mon$statements where mon$state<>0 and mon$attachment_id<>current_connection;

MON$STATEMENT_ID                38
MON$ATTACHMENT_ID               49
MON$TRANSACTION_ID              184
MON$STATE                       2
MON$TIMESTAMP                   2012-11-10 17:21:00.8280
MON$SQL_TEXT                    0:4
select * from t where id between 123456789 and 456789123
MON$STAT_ID                     7

(и так можно повторять select + delete + select + ... хоть до посинения)

ЭКСПЕРИМЕНТ 3.
Срубил окно, пытавшееся завалить выборку, но саму выборку оставил работать.
Запустил с другой машины isql и попытался подключиться к этой же базе.
Результат: подключение к базе из второго isql-окна длится... МИНУТУ(!).
В подключающемся окне я запускал батник, в котором непосредственно перед isql указано: echo %time%.
Затем посмотрел, в какой момент времени трейс покажет установку соединения от этого второго окна.
Итого:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
C:\MIX\firebird\fb25>echo 17:43:26,11
 17:43:26 ,11

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n
Database:  192.168.0.59:t1

Трейс:
2012-11-10T17:44:19.9100 (3754:0x2aaaab252728) TRACE_INIT
        SESSION_5


2012-11-10T 17:44:19 .9100 (3754:0x2aaaab252728) ATTACH_DATABASE
        t1 (ATT_51, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1780

2012-11-10T17:44:19.9130 (3754:0x2aaaab252728) START_TRANSACTION
        t1 (ATT_51, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1780
                (TRA_209, CONCURRENCY | WAIT | READ_WRITE)
...
Рейтинг: 0 / 0
10.11.2012, 17:53:32
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033004
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
PS. Повторил эксперимент_2 на "разогретой" базе - ноль эмоций: index-выборка из 10Е9-таблицы через mon$statements не срубается (вводил в другом окне commit; delete from mon$statements where ... ; commit; не менее 10 раз - всё бестолку).

Трейс этих лихорадочных попыток срубить запрос см. в аттаче.
...
Рейтинг: 0 / 0
10.11.2012, 18:09:51
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033045
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидВыборка по индексу единственной записи уходит в себя на... 5 минут.
не выборка, а prepare запроса, потому что да, prepare читает PP таблицы для определения ее кардинальности (хочет понять, сколько там записей).
и на терабайтной базе было не 5 минут, а 45 секунд, и не на миллиарде записей, а на 3.7 миллиардах.

ТаблоидИ там будет некоторое микроскопическое время, которое он якобы делался.
да, тоже есть такой эффект. Якобы время сканирования pp для сервера пролетело как один миг.
...
Рейтинг: 0 / 0
10.11.2012, 19:01:31
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033061
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvи на терабайтной базе было не 5 минут, а 45 секунд, и не на миллиарде записей, а на 3.7 миллиардах.Очень странно. У мну эта база сейчас на нормальном linux-серваке, с вменяемым дисковым массивом. Но время таки не 45 сек, а гораздо больше.
...
Рейтинг: 0 / 0
10.11.2012, 19:21:24
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033065
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvне выборка, а prepare запроса, потому что да, prepare читает PP таблицы для определения ее кардинальности (хочет понять, сколько там записей)..А зачем ему оценивать кардинальность, когда нет соединения с другим источником и есть эвристика оптимизатора, при которой индексное поле обязательно будет задействовано в случае указания его в where-предикате ? То есть, зачем ему что-то там оценивать, когда нет альтернативы и всё равно придется "ходить лошадью индексом" ?
...
Рейтинг: 0 / 0
10.11.2012, 19:26:41
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033073
avp_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avp_
Участник
ТаблоидА зачем ему оценивать кардинальность, когда нет соединения с другим источником и есть эвристика оптимизатора, при которой индексное поле обязательно будет задействовано в случае указания его в where-предикате ? То есть, зачем ему что-то там оценивать, когда нет альтернативы и всё равно придется "ходить лошадью индексом" ?

Кардинальность оценивается всегда - цена универсальности оптимизатора. Он вполне может решить не использовать индекс и пройтись натуралом. Другой вопрос, что нет заточки для частных синтетических случаев, когда например индекс уникальный.
...
Рейтинг: 0 / 0
10.11.2012, 19:36:59
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033080
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
avp_Он вполне может решить не использовать индекс и пройтись натуралом.Не в ФБ. Если по полю создан индекс и это поле указано в предикате, то индекс *будет* задействован, помимо нашей воли и сознания. Даже при выборке всех строк.
...
Рейтинг: 0 / 0
10.11.2012, 19:44:02
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033094
avp_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avp_
Участник
Таблоидavp_Он вполне может решить не использовать индекс и пройтись натуралом.Не в ФБ. Если по полю создан индекс и это поле указано в предикате, то индекс *будет* задействован, помимо нашей воли и сознания. Даже при выборке всех строк.
Может быть натурал и не заложен, но порядок соединения и используемые индексы однозначно оценивает через умножение кардинальности на селективность.
...
Рейтинг: 0 / 0
10.11.2012, 19:49:39
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033114
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ТаблоидОчень странно. У мну эта база сейчас на нормальном linux-серваке, с
вменяемым дисковым массивом. Но время таки не 45 сек, а гораздо больше.
Ничего странного: у тебя страница четыре килобайта, а у ДК - 16. Время чтения (как
обнаружил Пол Ривз на конференции) зависит не от объёма, а от количества чтений, коих у
тебя вчетверо больше.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
10.11.2012, 20:09:30
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033167
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидНе в ФБ
не в текущих версиях ФБ, не более того. Это всегда может измениться.
...
Рейтинг: 0 / 0
10.11.2012, 21:13:21
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033173
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovВремя чтения (как
обнаружил Пол Ривз на конференции) зависит не от объёма, а от количества чтений, коих у
тебя вчетверо больше.Поздравляю с открытием
Вот тебе еще одно "откровение" - для SSD это тоже верно, хоть и в меньшей степени.
...
Рейтинг: 0 / 0
10.11.2012, 21:20:54
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033174
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид ЭКСПЕРИМЕНТ-1.
Я понимаю, что трейс на сегодня показывает не все "служебные действия" (sweep только) - но нельзя ли расширить его в этом вопросе ?
трейс должен это время показывать в строке, относящейся к prepare

Таблоид ЭКСПЕРИМЕНТ-2.
В первом окне ввожу запрос к таблице `t` на выборку данных (не подсчет строк - а именно выборку полей).
Во втором окне пытаюсь срубить деятельность окна_1 через
Код: sql
1.
commit; delete from mon$statements ...;


Результат: ноль. Окно_1 будет работать, невзирая на все потуги окна_2. Срубить окно_1 можно только через delete from mon$attachments.
особенность текущей реализации, к сожалению. Удалить (сиречь: остановить) можно только активный риквест. А в твоем случае он всегда опознается как неактивный (stalled), мы это уже обсуждали недавно. Я подумаю, что тут можно сделать.

Таблоид ЭКСПЕРИМЕНТ 3.
Срубил окно, пытавшееся завалить выборку, но саму выборку оставил работать.
Запустил с другой машины isql и попытался подключиться к этой же базе.
Результат: подключение к базе из второго isql-окна длится... МИНУТУ(!).
вот это фигня какая-то, не должно такого быть
...
Рейтинг: 0 / 0
10.11.2012, 21:21:10
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033186
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladПоздравляю с открытием
Да для меня-то это открытием не было, но удивление Пола было так забавно, что я не
преминул встрять.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
10.11.2012, 21:27:41
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033259
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоид ЭКСПЕРИМЕНТ 3.
Срубил окно, пытавшееся завалить выборку, но саму выборку оставил работать.
Запустил с другой машины isql и попытался подключиться к этой же базе.
Результат: подключение к базе из второго isql-окна длится... МИНУТУ(!).вот это фигня какая-то, не должно такого бытьЭто повторяется уже как минимум в третий раз.
И происходит сиё, когда :
0) во втором isql-окне делаем quit;
1) в "молотильном" isql-окне ждём, когда завершится выборка по диапазону, для верности делаем там commit;
2) даём серверу заняться чем-то, что вытеснит базу или часть её из кеша операционки (увы, но я не сразу вспомнил про FileSystemCacheThreshold, см ниже)
3) в "молотильном окне" запускаем одиночный index-поиск:
Код: sql
1.
select * from t where id=789456123;

При этом в трейсе *НЕ* появится никакого сообщения о prepare stetement. Будет только START_TRANSACTION. Акцентирую на этом особое внимание, т.к. из слов kdv выше следует обратное: что затраты идут именно на prepare.
4) снова пытаемся подключиться вторым isql-окном:
Код: plaintext
1.
echo %time%
isql 192.168.0.59:t1 -n
В моём случае echo-команда сработала в 22:05:21,70 . А в трейсе сообщение об аттаче появилось только в 22:06:31

В итоге, в трейсе на момент завершения одиночного index-поиска, который длился 201 секунду(!), вижу:
 
trace
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
2012-11-10T22:05:08.3830 (3754:0x2aaaab256b60) FREE_STATEMENT
        t1 (ATT_53, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249

Statement 40:
-------------------------------------------------------------------------------
select * from t where id between 123456789 and 456789123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))

2012-11-10T22:05:08.4290 (3754:0x2aaaab256b60) COMMIT_TRANSACTION
        t1 (ATT_53, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                (TRA_289, CONCURRENCY | WAIT | READ_WRITE)
     17 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)

2012-11-10T 22:05:18 .9720 (3754:0x2aaaab256b60) START_TRANSACTION /*это запуск одиночного index-поиска*/
        t1 ( ATT_53 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                ( TRA_303 , CONCURRENCY | WAIT | READ_WRITE)

2012-11-10T22:06:31.7770 (3754:0x2aaaab256068) TRACE_INIT
        SESSION_9

/* это в базу проломилось второе isql-окно, ожидавшее минуту(!) */
2012-11-10T22:06:31.7770 (3754:0x2aaaab256068) ATTACH_DATABASE
        t1 ( ATT_55 , SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2184

2012-11-10T22:06:31.7790 (3754:0x2aaaab256068) START_TRANSACTION
        t1 (ATT_55, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2184
                (TRA_304, CONCURRENCY | WAIT | READ_WRITE)

2012-11-10T 22:08:40 .0550 (3754:0x2aaaab256b60) PREPARE_STATEMENT /*только здесь наступает prepare одиночного index-поиска! */
        t1 ( ATT_53 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                ( TRA_303 , CONCURRENCY | WAIT | READ_WRITE)

Statement 41:
-------------------------------------------------------------------------------
select * from t where id=789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))
 201067 ms

2012-11-10T22:08:40.0550 (3754:0x2aaaab256b60) EXECUTE_STATEMENT_START
        t1 (ATT_53, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                (TRA_303, CONCURRENCY | WAIT | READ_WRITE)

Statement 41:
-------------------------------------------------------------------------------
select * from t where id=789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))

2012-11-10T22:08:40.0980 (3754:0x2aaaab256b60) EXECUTE_STATEMENT_FINISH
        t1 (ATT_53, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                (TRA_303, CONCURRENCY | WAIT | READ_WRITE)

Statement 41:
-------------------------------------------------------------------------------
select * from t where id=789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))
1 records fetched
      42 ms, 7 read(s), 7 fetch(es) 

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

2012-11-10T22:08:40.0980 (3754:0x2aaaab256b60) CLOSE_CURSOR
        t1 (ATT_53, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249

Statement 41:
-------------------------------------------------------------------------------
select * from t where id=789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))
Прошу обратить внимание на два момента времени:
1) старт транзакции, в которой отдана команда одиночного index-поиска: 2012-11-10T 22:05:18 .9720
2) выполнение prepare этого index-запроса: 2012-11-10T 22:08:40 .0550
Разница между ними равна 3 мин 21 сек, т.е. около 201 секунды.
Можно, конечно, изо всех сил не поверить своим глазам и сказать себе "я ошибся".
Однако, в isql того окна, где был одиночный index-поиск, вижу то же самое - общее время более трёх минут:
 
isql stats
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SQL> select * from t where id=789456123;

PLAN (T INDEX (T_ID))
Current memory = 3939480
Delta memory = 11144
Max memory = 260690296
 Elapsed time= 201.12 sec 
Cpu = 0.00 sec
Buffers = 768
Reads = 29897
Writes = 0
Fetches = 29901
Прошу также обратить внимание на совершенно "удивительные" 42 мс и 7 фетчей , которые якобы потребовались для этого запроса.

PS. Файловый кеш линуха сильно мешает чистоте замеров. Выключу-ка его: поставлю FileSystemCacheThreshold = 75 при кеше коннекта = 768, "пущай полетает"
...
Рейтинг: 0 / 0
10.11.2012, 22:41:20
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033261
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Пардон муа, опечатался при правке предыдущего поста. Вот эта цитата:вот это фигня какая-то, не должно такого быть- принадлежит не Владу, а Дмитрию.
...
Рейтинг: 0 / 0
10.11.2012, 22:43:12
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033264
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrтрейс должен это время показывать в строке, относящейся к prepareОн там показываает какой-то момент времени, но не длительность этого самого препаре. См. выше, повторю на всякий случай еще раз:Таблоид
Код: plaintext
1.
2.
3.
2012-11-10T 22:08:40 .0550 (3754:0x2aaaab256b60) PREPARE_STATEMENT /*только здесь наступает prepare одиночного index-поиска! */
        t1 ( ATT_53 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                ( TRA_303 , CONCURRENCY | WAIT | READ_WRITE)
где тут видно временн ы е затраты ?
...
Рейтинг: 0 / 0
10.11.2012, 22:46:40
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033276
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Таблоидгде тут видно временн ы е затраты ?Отбой, глаза замылены уже. Вижу :-)

Выключил использование кеша операционки (поставил fileSystemCacheThreshold = 0), рестартовал ФБ.
Запустил снова isql с одиночным index-запросом.
В соседнем окне выполнял батник, выводящий время (echo %time%) и натравливающий isql на простенький скрипт: select current_timestamp from rdb$database; commit;
Длительность установки коннектов в этом окне составляет 2-3 сек (причём в первый запуск isql - 10 сек, второй - 7 сек).

Затраты на прераре в окне с одиночным index-поиском составили 121 сек.
...
Рейтинг: 0 / 0
10.11.2012, 22:57:34
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033287
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Итак, загадочная пауза вызвана затратами на prepare.
Тогда вопрос: что там скрывается, в этих затратах ?

Запрос, который надо выполнить:
Код: sql
1.
select * from t where id = :a_id

- для разбора тривиален и должен ( вроде бы ) привести к мгновенному рождению плана его выполнения. Именно в виду эвристик, которые заложены в нынешний код ФБ.

Тогда что еще включено в "препарирование" ?
...
Рейтинг: 0 / 0
10.11.2012, 23:05:57
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033297
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидИтак, загадочная пауза вызвана затратами на prepare.
я ж сразу сказал...

ТаблоидТогда что еще включено в "препарирование" ?
просчет кардинальности, т.е. скан pp. Он самый долгий на больших базах. Вернее, на больших базах более заметен, чем на мелких.
И, чем больше таблиц в запросе, тем дольше будет просчет, т.к. кардинальность считается для всех таблиц (вроде). Подробнее разве что в

http://firebird.svn.sourceforge.net/viewvc/firebird/firebird/tags/R2_5_2/src/jrd/Optimizer.cpp?revision=57336&view=markup
...
Рейтинг: 0 / 0
10.11.2012, 23:22:01
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033300
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdv prepare читает PP таблицы для определения ее кардинальности (хочет понять, сколько там записей).Ну так я снова хочу поинтересоваться: сколько можно читать PP единственной таблицы, если база имеет такую статистику:
 
gstat -r
Код: 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.
Database "t1.fdb"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              98
        Page size               4096
        ODS version             11.2
        Oldest transaction      6
        Oldest active           84
        Oldest snapshot         84
        Next transaction        87
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      10
        Implementation ID       24
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Nov 6, 2012 0:38:41
        Attributes              force write

    Variable header data:
        *END*


Database file sequence:
File t1.fdb is the only file

Analyzing database pages ...
T (132)
    Primary pointer page: 169, Index root page: 170
    Average record length: 71.99, total records: 1000000000
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 28567997, data page slots: 28567997, average fill: 76%
    Fill distribution:
         0 - 19% = 0
        20 - 39% = 0
        40 - 59% = 0
        60 - 79% = 28567997
        80 - 99% = 0

    Index T_ID (0)
        Depth: 4, leaf buckets: 1745793, nodes: 1000000000
        Average data length: 1.01, total dup: 0, max dup: 0
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 0
            40 - 59% = 0
            60 - 79% = 0
            80 - 99% = 1745793

Как хотя бы примерно оценить размер этой PP ?
...
Рейтинг: 0 / 0
10.11.2012, 23:23:49
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033301
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидТогда что еще включено в "препарирование" ?
тьфу. кроме кардинальности еще наличие индексов и их селективность. Но с индексами проще, в том смысле, что найти их все и вытащить селективность - это быстро делается.
Хотя, была какая-то штука, при большом количестве таблиц и индексов был долгий перебор вариантов. Но вроде это давно починили.
...
Рейтинг: 0 / 0
10.11.2012, 23:24:10
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033309
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvросчет кардинальности, т.е. скан pp . <...>
Подробнее разве что в

http://firebird.svn.sourceforge.net/viewvc/firebird/firebird/tags/R2_5_2/src/jrd/Optimizer.cpp?revision=57336&view=markup гы... и где ТАМ искать пресловутый "скан PP" ?
(по словам `pp` и `pointer`, кстати, ничего релевантного там нету!)
...
Рейтинг: 0 / 0
10.11.2012, 23:33:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033323
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидНу так я снова хочу поинтересоваться: сколько можно читать PP единственной таблицы, если база имеет такую статистику... Как хотя бы примерно оценить размер этой PP ?
28567997 страниц данных, это примерно 3 млн pointer pages. Столько случайных дисковых чтений нужно для оценки кардинальности таблицы. Ты же специально выбрал самый поганый сценарий, с минимальным размером страницы. Вот и огребай.
...
Рейтинг: 0 / 0
10.11.2012, 23:44:01
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033327
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
dimitr28567997 страниц данных, это примерно 3 млн pointer pages
пардон, 30 тыс конечно же. Пиво мешает арифметике :-) Но отмечу, что эти 30 тыс равномерно размазаны по 118ГБ.
...
Рейтинг: 0 / 0
10.11.2012, 23:46:45
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033346
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
kdvкардинальность считается для всех таблиц (вроде)Нет конечно.

А вот при аттаче выполняются некоторые служебные запросы, плюс читается rdb$pages.
...
Рейтинг: 0 / 0
11.11.2012, 00:07:58
| Ответить | Цитировать | Написать  
25 сообщений из 189, страница 1 из 8
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&tid=1564260]:
 0ms
get settings:
 6ms
get forum list:
 25ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 215ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 76ms
get tp. blocked users:
 1ms
others: 206ms
total:  552ms
созд. / загр.: 552ms
x
x
Закрыть


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