|
|
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Yo.!я потрясен. точно так ? неважно какой RANGE заставит прочесть весь индекс !? мы видимо по-разному поняли процитированную фразу. Конечно же, читается только часть индекса -- от lower bound до upper bound. Это же range scan, в конце концов :-) В цитате имеется ввиду, что читаются все ключи диапазона за единый скан и только потом читаются записи в порядке хранения. А не идти по циклу "ключ->запись". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2008, 18:48 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
fynda пишет: > Все они. И не надо говорить, что кто-то знает, как писать абсолютно > безглючный код. Безглючный код - одно, а куча глобальных переменных в многопоточном приложении - совсем другое. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2008, 22:56 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
MasterZiv Безглючный код - одно, а куча глобальных переменных в многопоточном приложении - совсем другое. Это ничего, что страницей ранее мы говорили про баги, а теперь уже - про глобальные переменные? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2008, 23:20 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
dimitr мы видимо по-разному поняли процитированную фразу. Конечно же, читается только часть индекса -- от lower bound до upper bound. Это же range scan, в конце концов :-) В цитате имеется ввиду, что читаются все ключи диапазона за единый скан и только потом читаются записи в порядке хранения. А не идти по циклу "ключ->запись". хм ... так блоки листьев вроде как на HDD не обязательно лежат последовательно, т.е. вы спуститесь до нижнего блока и начнете ходить по ссылкам рандомно читая связаные листовые блоки, откуда возьмется "sequential I/O" ? постгресовый bitmap index scan мне показалось походит на fast full index scan из оракла, где оракл читает с помощью scattered i/o весь индекс, а потом выкидывает ненужное. я ошибся ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2008, 18:42 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Yo.!хм ... так блоки листьев вроде как на HDD не обязательно лежат последовательно, т.е. вы спуститесь до нижнего блока и начнете ходить по ссылкам рандомно читая связаные листовые блоки, откуда возьмется "sequential I/O" ? блоки листьев тут не причем. Речь о блоках, на которые ссылаются эти листья. Ключ индекса 1 ссылается на страницу данных 5, ключ 2 на страницу 56, ключ 3 снова на страницу 5, ключ 4 на страницу 32 и т.д. PGSQL и FB буду читать страницы данных в порядке 5-32-56, а не 5-56-5-32. Есс-но, на эффективность тут влияет еще и фрагментация БД, но даже в худшем случае два чтения со страницы 5 пройдут подряд когда она в кэше, а не через неопределенных интервал времени, когда она уже может быть вытеснена. Yo.!постгресовый bitmap index scan мне показалось походит на fast full index scan из оракла, где оракл читает с помощью scattered i/o весь индекс, а потом выкидывает ненужное. я ошибся ? он работает именно так, как я описал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2008, 22:30 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
другими словами, считайте что в PGSQL/FB индексный скан (именно скан, а не индекс) всегда имеет идеальный clustering factor (в терминах оракла). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2008, 22:49 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
как работает теперь ясно, конечно способность оттянуть нужность фулскана аж до 70-80% от выборки (если учесть, что в оракле ~12%, наверно за счет мультиблочного чтения) мягко говоря вызывает сомнения, но тут думаю упаришься мерять все варианты... к стате такой оптимзацией и котроллер сам может заниматся (оптимизируя очередь сказийных команд). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2008, 13:28 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Yo.!как работает теперь ясно, конечно способность оттянуть нужность фулскана аж до 70-80% от выборки (если учесть, что в оракле ~12%, наверно за счет мультиблочного чтения) мягко говоря вызывает сомнения, но тут думаю упаришься мерять все варианты... к стате такой оптимзацией и котроллер сам может заниматся (оптимизируя очередь сказийных команд).Угу и мультиблочным чтенем он тоже может сам заняться, и b-tree тоже сам строит, да и партиционировать (по цилиндрам ?) правильные контроллеры давно сами умеют... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2008, 15:59 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
dimitr это может говорить и об относительной неторпливости ораклового парсера :-) Дело не в парсере, а в оптимизаторе (если только вы не имели в виду тоже самое). Поскольку у Оракла он более совершенный, процесс построения плана занимает больше времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2008, 19:25 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Yo.!как работает теперь ясно, конечно способность оттянуть нужность фулскана аж до 70-80% от выборки (если учесть, что в оракле ~12%, наверно за счет мультиблочного чтения) мягко говоря вызывает сомнения, но тут думаю упаришься мерять все варианты... к стате такой оптимзацией и котроллер сам может заниматся (оптимизируя очередь сказийных команд). 1. не 12%, а 15% 2. это очень усредненная оценка, случаи бывают разные, где-то в оракловой ветке "Я и Ежик" показывал, как Index Range Scan 50% хорошо кластеризованной таблицы выигрывал у Full Scan той же таблицы 3. при Index Range Scan Оракл пинит последний прочитанный блок, как раз на случай он вдруг понадобиться; это конечно не так эффективно как у Жарптицы (доступ к записям в порядке их расположения в страницах), но зато не надо тратить время и память на сортировку 4. у Оракла есть альтернативные способы борьбы с плохим фактором кластеризации - IOT, Cluster. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2008, 19:51 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
авторНо каково по-вашему соотношение времени оптимизации к времени исполнения пусть даже коротких запросов в реальной жизни http://www.sql.ru/forum/actualthread.aspx?tid=518669#5203350 авторPrepare time = 20ms Execute time = 10ms ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 09:37 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
p.s. не флейма ради а истины для. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 09:38 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
dimitrстраницу 32 и т.д. PGSQL и FB буду читать страницы данных в порядке 5-32-56, а не 5-56-5-32. умарил :) тут уже дело не в субд а в винтах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 09:45 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Чендлер dimitrстраницу 32 и т.д. PGSQL и FB буду читать страницы данных в порядке 5-32-56, а не 5-56-5-32. умарил :) тут уже дело не в субд а в винтах От вы тупые, ей богу... Разные записи разных листовых блоков индекса могут ссылаться на строки находящиеся в одном блоке данных таблицы. Так вот смысл предварительной сортировки в том, чтобы избежать многократного чтения один и тех же блоков данных таблицы. Причем тут винты? Речь о логическом доступе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 10:36 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Apex 1. не 12%, а 15% 2. это очень усредненная оценка, случаи бывают разные, где-то в оракловой ветке "Я и Ежик" показывал, как Index Range Scan 50% хорошо кластеризованной таблицы выигрывал у Full Scan той же таблицы 3. при Index Range Scan Оракл пинит последний прочитанный блок, как раз на случай он вдруг понадобиться; это конечно не так эффективно как у Жарптицы (доступ к записям в порядке их расположения в страницах), но зато не надо тратить время и память на сортировку 4. у Оракла есть альтернативные способы борьбы с плохим фактором кластеризации - IOT, Cluster. 1. This threshold percentage varies greatly, however, according to the relative speed of a table scan and how clustered the row data is about the index key. The faster the table scan, the lower the percentage; the more clustered the row data, the higher the percentage. 2. а кеш он догодался сбрасывать перед замерами ? Кайт утверждает, что для чтение 25% от таблички как раз и понадобится поднять все блоки таблицы. 3. эфективней !? мелкие таблицы будут в кеше, ФБ - проигрывает занимаясь лишней сортировкой, большие таблицы оракл мультиблочно в разы, если не порядок быстрее справится с i/o. Fast index scan по сути и есть подход ФБ, но в оракле никому в голову не пришло шагать по ссылкам листьев отказываясь от мультиблочного чтения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 11:22 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
To ScareCrow : Пользуй процедуры, раз уж так приспичило ScareCrowp.s. не флейма ради а истины для.угу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 12:36 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
>Пользуй процедуры, раз уж так приспичило а процедуры мы таки кэшируем? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 13:02 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
ScareCrow >Пользуй процедуры, раз уж так приспичило а процедуры мы таки кэшируем? И даже триггеры ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 15:33 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Yo.! ФБ - проигрывает занимаясь лишней сортировкой, большие таблицы оракл мультиблочно в разы, если не порядок быстрее справится с i/o. Fast index scan по сути и есть подход ФБ, но в оракле никому в голову не пришло шагать по ссылкам листьев отказываясь от мультиблочного чтения. Сортировкой? Там нет никакой сортировки. Обычная битовая маска. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 23:05 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Apex От вы тупые, ей богу... Разные записи разных листовых блоков индекса могут ссылаться на строки находящиеся в одном блоке данных таблицы. Так вот смысл предварительной сортировки в том, чтобы избежать многократного чтения один и тех же блоков данных таблицы. Причем тут винты? Речь о логическом доступе. когда блок считывается он попадает в кеш, прежде чем считать след. блок проверяется есть ли он в кеше, если нет то считываем если есть то берём из кеша. Где сортировка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2008, 04:25 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Чендлер когда блок считывается он попадает в кеш, прежде чем считать след. блок проверяется есть ли он в кеше, если нет то считываем если есть то берём из кеша. Где сортировка? Это вообще к чему все было? Алгоритм работы для Postgres описан здесь. Следующим постом идет подтверждение того, что FB работает аналогично. К чему был ваш пост? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2008, 09:52 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
dimitrдругими словами, считайте что в PGSQL/FB индексный скан (именно скан, а не индекс) всегда имеет идеальный clustering factor (в терминах оракла). Кстати, Дмитрий, идеальный фактор кластеризации - это безусловно прекрасно... но что, если из все выборки мне понадобиться только первые N строк? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2008, 10:00 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Чендлер Apex От вы тупые, ей богу... Разные записи разных листовых блоков индекса могут ссылаться на строки находящиеся в одном блоке данных таблицы. Так вот смысл предварительной сортировки в том, чтобы избежать многократного чтения один и тех же блоков данных таблицы. Причем тут винты? Речь о логическом доступе. когда блок считывается он попадает в кеш, прежде чем считать след. блок проверяется есть ли он в кеше, если нет то считываем если есть то берём из кеша. Где сортировка?А кто сказал, что он всё ещё в кеше ? Бывают таблицы, многократно превосходящие размеры кешей, да и не все запросы обращаются только к одной таблице. И параллельно таких запросов может быть более одного, как ни странно. Ась ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2008, 10:31 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
Apexчто, если из все выборки мне понадобиться только первые N строк? это цена битмап скана, увы. Это мы уже как-то обсуждали тут с оракловыми ребятами. Но обычно на практике FIRST используется в паре с ORDER BY и тогда, при наличии индекса, подходящего под условие сортировки, будет выбран именно не-битмап скан индекса. Хотя если ORDER BY отсутствует и вы просто хотите закрыть курсор после фетча первых нескольких записей, тады ой -- тут вы FB обманули :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2008, 10:59 |
|
||
|
Firebird (Interbase) vs MS SQL 2005
|
|||
|---|---|---|---|
|
#18+
pkarklin TaulerНасчет многоаользователей и т.д. - знаю реально работающее производство совсем немалых размеров с 200-ми филиалами, колво юзверей от 100 до 500, филиалы по все России, разбер БД 39 гектар. FB 2.0. Одно? и фсё? Читал где-то(источник не помню), была зафиксирована приемлемая работа FB c БД в 200Гб! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2008, 18:10 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=35154427&tid=1553158]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 13ms |
| total: | 163ms |

| 0 / 0 |
