Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
ASCRUS
Но вот зачем человеку рекомендовать то, что заведомо ему неподходит
Уверен ?
"Это отдает фанатизмом, а не здравым смыслом" (c) ASCRUS
14 янв 05, 17:31    [1246291]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Александр Гoлдун
Никак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком. И при этом придумывают протоколирования действий на триггерах, какие-то исскуственные схемы для реализации наката.


Саш, ну ты-то хоть не путай народ. Ты ведь говоришь про redo log, а фанаты - про undo. Необходимость второго в версионнике - нонсенс. А вот первый весьма бы не помешал для incremental recovery. И с этим никто не спорит, собственно.
14 янв 05, 17:36    [1246308]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
hvlad
ASCRUS
Но вот зачем человеку рекомендовать то, что заведомо ему неподходит
Уверен ?
"Это отдает фанатизмом, а не здравым смыслом" (c) ASCRUS

Во первых мы на "ТЫ" вроде как не переходили. Во вторых переход на личности осуществляется участниками за недостатком аргументов (это к слову о предыдущих на меня выступлениям по поводу пенсии). В третьих полностью уверен благодаря приведенным в данном топике примерам. В четвертых цитировать кого либо мало - необходимо вдумываться. Ну и в последних - я не очень понимаю, чего так реагировать, вроде как никто интербейсников в ущербности продукта не обвинял, всего лишь перечислили факты и каждый для себя сделал соотвествующие выводы, откуда такой возник комплекс неполноценности лично у Вас - ведь другие специалисты Interbase в этом топике вроде как адекватно реагируют на все высказывания, признают недостатки и подчеркивают его достоинства.
14 янв 05, 17:52    [1246393]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
dimitr
Александр Гoлдун
Никак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком. И при этом придумывают протоколирования действий на триггерах, какие-то исскуственные схемы для реализации наката.


Саш, ну ты-то хоть не путай народ. Ты ведь говоришь про redo log, а фанаты - про undo. Необходимость второго в версионнике - нонсенс. А вот первый весьма бы не помешал для incremental recovery. И с этим никто не спорит, собственно.


Сам прочитал и ужаснулся, как сгустил краски ;)))

Да, я про redo, а не undo. Но undo - это чисто технический момент и он меня, как пользователя сервера БД, не очень интересует, как он откатит транзакцию - лишь бы откатил. А вот без практического потребительского использования redo жить не могу.

IMHO у FB главное преимущество - местное сообщество его пользователей и свои же родные разработчики, с которыми можно тут же пообщаться, как вот с тобой, например ;) И которые, как ни странно, наиболее критично из всего FB-сообщества относятся к этому серверу.
Но это в первую очередь потенциал на будущее. А пока FB еще есть куда расти.

Кстати, вопрос: в FB2 уже будет распараллеливание запросов при общем кэше?
14 янв 05, 17:57    [1246418]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
ASCRUS
Во первых мы на "ТЫ" вроде как не переходили.
imho это общепринято, ок, будем на Вы (если вообще будем)

ASCRUS
Во вторых переход на личности осуществляется участниками за недостатком аргументов (это к слову о предыдущих на меня выступлениям по поводу пенсии).
Это Вы про что ?

ASCRUS
В третьих полностью уверен благодаря приведенным в данном топике примерам.
Ок

ASCRUS
В четвертых цитировать кого либо мало - необходимо вдумываться.
Так же как и вдумываться в смысл\отсутствие смысла тех самых "примеров"

ASCRUS
Ну и в последних - я не очень понимаю, чего так реагировать, вроде как никто интербейсников в ущербности продукта не обвинял
Мне что - опять цитировать ? ;)
И где с моей стороны "такая" реакция ?

ASCRUS
всего лишь перечислили факты и каждый для себя сделал соотвествующие выводы
Фактов практически не было

ASCRUS
откуда такой возник комплекс неполноценности лично у Вас - ведь другие специалисты Interbase в этом топике вроде как адекватно реагируют на все высказывания, признают недостатки и подчеркивают его достоинства.
У Вас ещё и диплом психоаналитика ?

Все вопросы - риторические, можно не отвечать
14 янв 05, 18:12    [1246496]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Страшен пятничный флейм, бессмысленный и беспощадный (с)

ЗЫ. Это я вместо финала ;-) Хотя шибко сомневаюсь, что автору топика мы сильно помогли...
14 янв 05, 20:36    [1246760]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
А почему выбор именно между FireBird 1.5.2 и PostgreSQL 7.4?

mef

Пользование услугами данной системы будет платное (это важно) поэтому вопрос по стоимости лицензионной чистоты тоже важен. То есть сколько денег будет стоить лицензия с правом коммерческого использования.


Оба упомянутых сервера бесплатны. Но если проект коммерческий, то может есть смысл не ограничиваться этими серверами, а расмотреть еще и коммерческие и все тщательно взвесить?
В моей личной практике в большинстве проектов стоимость сервера компенсировалась с лихвой уменьшением стоимости разработки и сопровождения по сравнению с использованием бесплатных серверов.
14 янв 05, 21:08    [1246788]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
Странно, почему-то Sad Spirit отсутствует :), тема самая что ни на есть его! (наверное после праздников все никак не отойдет)

Картинка с другого сайта.
15 янв 05, 00:43    [1247146]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
Рыжий Кот
Странно, почему-то Sad Spirit отсутствует :), тема самая что ни на есть его! (наверное после праздников все никак не отойдет)

Спасибо за трогательную заботу о моём здоровье. ;)

На самом деле просто времени нет за развитием флейма следить, тем более тут уже профессионалы развлекаются, а я так --- любитель. ;)

Gold

Тогда получается что если Postgres и другие серверы учитывают все вышеперечисленные показатели, то подготовка запросов сильно тормозит в этих серверах? Также не понятно мне с кэшированием команд. Как кэширование команд увязывается с генерированием разных планов на каждую команду?

Угу, подготовка "тормозит", зато выполнение ускоряется. ;) А с кэшированием действительно могут быть проблемы, если для разных значений, подставляемых в закэшированный запрос, сильно отличается распределение данных, про это в доках написано

dimitr

Процент заюзанности Постгреса в реальных задачах далек от IB и всех его последователей. Тем паче в коммерческой сфере. Возможно, фанатиков-энтузиастов там тоже меньше. Поэтому и меньше воплей, как "за", так и "против". Полагаю, что отсюда же меньше информации о стабильности, багах и прочих граблях.

Слова насчёт процента заюзанности неплохо бы подтвержать ссылками на какую-никакую статистику. В коммерческой сфере: PostgreSQL сейчас поддерживают Red Hat, Fujitsu и совсем недавно Pervasive. Про фанатиков --- чистая правда: как в интернете не устроят опрос про "любимую OpenSource СУБД" --- с большим отрывом выигрывает Firebird. ;)

mozheyko_d

А чё за грабли?

Была куча всяких неприятных ограничений: из-за отсутствия лога транзакций данные в таблицу принудительно скидывались после каждого COMMIT'а, размер строки был ограничен 8кб, операция сборки мусора полностью блокировала таблицу. Где-то с версии 7.3 таких ограничений уже не было и продукт стал вполне пригоден к весьма серьёзной эксплуатации. Версия 7.3 вышла в конце 2002, оставим вопрос "а где тогда были остальные OpenSource СУБД" в качестве упражнения для читателей.

к исходному вопросу, скажу за PostgreSQL:
mef

-устойчивость
-производительность при описанных условиях

судя по имеющемуся описанию, на нормальном железе всё это будет работать вполне нормально.


-масштабируемость (обработка нитями - грубо говоря типовая конфигурация железа - на 500 ниток, если надо 600 - докупаем ещё один сервак, регистрируем в системе - и вперёд)

полноценной multi-master репликации нету и вряд ли будет до версии 8.1.
Но вертикальная масштабируемость хорошая, так что можно просто поставить более мощный сервер.


-удобство разработки (в идеале - визуальные среды разработки запросов и ХП)

Это вряд ли. :)

Кроме того, я где-то что-то слышал про процедурный язык pl/r для PostgreSQL, он вроде бы специально приспособлен для такой обработки, о которой шла речь в исходном сообщении.
15 янв 05, 12:59    [1247423]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
nik_x
Member

Откуда:
Сообщений: 1887
[quot Sad Spirit]
...
Но вертикальная масштабируемость хорошая, так что можно просто поставить более мощный сервер.

[quot ]

А что, уже выпустили Embedded Posgres, такой как в FB?
15 янв 05, 14:03    [1247467]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mv
Member

Откуда:
Сообщений: 8876
Уважаемый mef !
Описанные в начале ветви требования эмулируются с вполне допустимыми трудозатратами.
Впрочем, может быть, спросивший mef больше интересуется психоанализом, чем техническими особенностями выбираемого инструментального средства.

Я активно использовал совсем немного СУБД - FoxPro (ну, не СУБД, но очень похоже), Access, InterBase и MS SQL. Несмотря на сегодняшнюю мою приверженность к InterBase не могу сказать, что хотя бы одна из перечисленных система не удовлетворяла моих потребностей на момент ее использования.

Совсем несложно прочитать документацию и написать несколько тестов (пусть в дальнейшем они окажутся не вполне адекватными - зато на данный момент они будут отражать Ваши возможности по использованию СУБД - хуже скорее всего не будет, т.к. обычно в процессе разработки находишь возможность "обходить углы"), хотя, конечно, гораздо приятнее наблюдать за спором о реализации механизма транзакций.

Более того, если здесь Вы спросите по поводу того, что один из результатолв тестов не удовлетворяют Вас в чем-то, то здесь Вы моментально получите совет и рекомендацию. Только спрашивать об InterBase нужно в разделе InterBase, а о MS SQL - в разделе MS SQL.
16 янв 05, 20:35    [1248292]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
hvlad.
+++++++++++++++++++++++++
На SQL.ru принято обращаться на "Вы". За исключением форумов Просто Треп и AREA-51.
16 янв 05, 22:55    [1248384]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32882

Привет, Cat2!
Ты пишешь:

Cat2
C> На SQL.ru принято обращаться на "Вы".
За исключением форумов Просто Треп и AREA-51.

Опять, Кот, самодурствуешь?!
Где это в правилах?!
Нету?
Ну и нех!

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

17 янв 05, 10:53    [1248908]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
Cat2
hvlad.
+++++++++++++++++++++++++
На SQL.ru принято обращаться на "Вы". За исключением форумов Просто Треп и AREA-51.
Это не отражено в правилах форума, посему каждый выбирает форму обращения по своему разумению.
Если собеседник возражает, это его право. Ничего оскорбительного я в этом не вижу.
17 янв 05, 10:55    [1248921]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Кстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я понял, что версионность в нем означает, что на DML команды нет понятия эклюзивной блокировки, то есть поддерживается версионность для изменений записи ? Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?

Я понимаю версионность Оракла в том плане, что она позволяет во время изменения записи читателям работать с ее оригинальной версией, но писатели там друг друга блокируют (что есть правильно). Но вот зачем делать версионность писателей и из за этого получать такую сложную модель физической реализации движка я понять не могу. Буду очень признателен, если просветите по этому вопросу или же поправите меня там, где я ошибаюсь. Как говорится учиться ни когда не вредно, во всяком случае меня интересуют различные модели реализации поддержки уровней изоляции в блокировочниках и версионниках, их механизмы работы и достоинства и недостатки. Пока вот для меня модель версионности Interbase загадка, хотя я честно почитал на эту тему различную литературу, выложенную на ibase.ru и вроде как чего то понял.
17 янв 05, 11:06    [1248983]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32882

Привет, ASCRUS!
Ты пишешь:

ASCRUS
A> Кстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я
понял, что
A> версионность в нем означает, что на DML команды нет понятия эклюзивной блокировки, то есть поддерживается версионность для
A> изменений записи ? Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?

http://www.ibase.ru/devinfo/versions.htm

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

17 янв 05, 11:13    [1249021]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
ASCRUS
Кстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я понял, что версионность в нем означает, что на DML команды нет понятия эклюзивной блокировки
В том смысле, как в MS - нет такого понятия, ибо оно не нужно.

ASCRUS
то есть поддерживается версионность для изменений записи ?
Нет.

ASCRUS
Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?
Ага

В любой момент времени может быть не более одной активной версии записи. Версия активна, если создавшая её тр-ция не находится в состоянии commited. Каждая версия каждой записи помечена номером создавшей её тр-ции. Движок знает о состоянии всех тр-ций в любой момент времени.

Если кто-то пытается создать вторую активную версию записи, то он либо ждёт завершения конкурирующей активной тр-ции, либо сразу получает ошибку lock conflict on no wait transaction. Это зависит от пар-ра wait\no wait тр-ции.

Штатно можно зарезервировать (заблокировать) всю таблицу от чтения и\или записи.
Запись можно "заблокировать" от изменений, просто проапдейтив её. "Блокировка" будет снята после завершения тр-ции.
В FB1.5 ввели спец. конструкцию SELECT .. WITH LOCK, делающую холостой апдейт записи в момент её фетча и не приводящий к срабатыванию триггеров.

PS Ничего, что я цитирую ? ;)
17 янв 05, 11:51    [1249184]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
PS Ничего, что я цитирую ? ;)

Наоборот, спасибо. Приведенную выше ссылку я уже читал, но решил, что лучше уточнить, чем делать выводы исходя из того, что понял :) Все таки тяжеловатый механизм - версионность индексов это конечно круто, кстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?
17 янв 05, 12:10    [1249253]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
ASCRUS
версионность индексов это конечно круто, кстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?

Хм. Боюсь, я не очень понимаю, в чем разница. Разница с архитектурой Oracle, судя по указанной статье - "старая версия записи" пишется куда-то в data file, в то время как Oracle использует rollback segment. А Oracle спокойно использует "кластерные индексы" - соответственно, механизм работает. Как именно - сходу не скажу, надо смотреть доки.
17 янв 05, 12:20    [1249294]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Кластерный индексов действительно нет и их действительно сделать затруднительно. Да и насчет обычных индексов есть неприятные ограничения. Сейчас хранится один ключ индекса на все версии записи (ID транзакции в ключ не входит). Отсюда невозможность index-only scan, ибо для каждого выбранного ключа придется читать запись с диска и определять видимость для текущей транзакции. Можно сделать полную версионность в индексе, введя в ключ txn ID, но это приведет к модификации всех индексов при каждом изменении записи, даже если затронуты неиндексированные поля. Пока считается, что это слишком большая цена. Да и последующая сборка мусора в таком "загаженном" индексе будет заметно тяжелее, чем сейчас. Вот такова селяви насчет индексов в версионнике.
17 янв 05, 12:24    [1249307]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
ASCRUS
Все таки тяжеловатый механизм - версионность индексов это конечно круто
А кто тут говорил про версионность индексов ? ;)
Индексы - отдельная песня. Версий там нет. Когда появляется новый ключ (insert\update ключевых полей), он вставляется в b-tree. И всё.
Любой индексный метод доступа должен, после построения списка номеров записей-кандидатов, посетить запись и убедиться что она все ещё удовлетворяет критерию отбора и может быть видна читающей тр-ции.

На перый взгляд это снижает полезность индексов. Но такое построение, вместе с префиксным сжатием ключа, позволяет очень компактно хранить индексы на диске. Я как-то сравнивал с MS - выигрыш был в 2-3 раза на одних и тех же данных. Это значительно снижает потребность в дисковых операциях.

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

ASCRUS
кстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?
Их нет потому что они не дадут столь большого выигрыша в призводительности, как у других серверов.
В FB любой индексный метод доступа сначала сканирует индекс, а потом читает таблицу. Причём таблица читается в порядке номеров страниц, т.е. как кластерная таблица у MS.
17 янв 05, 12:51    [1249420]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
softwarer
Хм. Боюсь, я не очень понимаю, в чем разница. Разница с архитектурой Oracle, судя по указанной статье - "старая версия записи" пишется куда-то в data file, в то время как Oracle использует rollback segment.


Оракл хранит не версии записей, а версии блоков, насколько я в курсе. Вот в Юконе версионность ближе к IB/FB, но и там версии лежат в tempdb, а не в основной базе.

softwarer
А Oracle спокойно использует "кластерные индексы" - соответственно, механизм работает. Как именно - сходу не скажу, надо смотреть доки.


Мне кажется, тут проблема в производительности. Перелопачивать index organized table при каждом незакоммиченном изменении ключа... а потом перелопачивать обратно при сборке мусора после роллбека...
17 янв 05, 12:55    [1249444]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
hvlad
Причём таблица читается в порядке номеров страниц, т.е. как кластерная таблица у MS.


Кстати, этот нюанс - вроде как один из плюсов IB/FB против Оракла. Я специально делал замеры и вышел на вывод, что сортировку битмапа с DBKEY-кандидатами Оракл не производит. Сканирование с INDEX-планом на неуникальном индексе FB выполняет в два-три раза быстрее (при неполном кешировании данных сервером, есс-но), чем оракловый RANGE INDEX SCAN. Возможно, отсюда сильная нелюбовь ораклового оптимизатора к RANGE SCAN - обычно выбирается либо UNIQUE SCAN (при возможности), либо HASH JOIN. Возможно, кто-либо здесь подтвердит или опровергнет это наблюдение.
17 янв 05, 13:03    [1249487]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
dimitr
Оракл хранит не версии записей, а версии блоков, насколько я в курсе.

Это так. Но я не вижу тут идеологически существенной разницы - имхо это технический момент. Плюс такого подхода, по моим представлениям, в том, что версионность получается как бы автоматической для всех объектов данных - ну и еще в том, что когда-то, до знакомства с Oracle, я писал движок на том же принципе :) Но версионность по записям вроде бы не мешает сделать то же.

dimitr
Мне кажется, тут проблема в производительности. Перелопачивать index organized table при каждом незакоммиченном изменении ключа... а потом перелопачивать обратно при сборке мусора после роллбека...

Хм. Я бы отметил так:

- В первую очередь, проблемы долгого rollback-а относительно неважны. То есть я не видел систем, где был бы удобен регулярный rollback - и я бы назвал такое неправильным дизайном даже в отрыве от архитектуры конкретной БД.

- изменение ключа и соответствующее перелопачивание - имхо, операция относительно редкая. Конечно, все зависит от профиля операций, но делать IOT, вынося в ключ, тем более в первые поля часто модифицируемое поле вряд ли разумно.

- перелопачивать index organized table или просто индекс - хм, не такая уж принципиальная разница. Единственно что IOT скорее всего в среднем значительно шире - но вопрос, какую роль это играет (я не помню сходу, делаются ли там "цепочки" или переносится полная запись).

- Перестраивать индекс при изменении данных все равно необходимо. Когда делать это - то ли при изменении данных, то ли при commit-е - вряд ли принципиально с точки зрения производительности именно этой операции. Зато версионный индекс может крайне ускорить работу, а IOT - как минимум, существенно экономит место и чтения.

Итог: разумеется, при неудачном использовании будут тормоза. Сделать вроде как можно, и использовать во благо - тоже.
17 янв 05, 13:38    [1249646]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
dimitr
Я специально делал замеры и вышел на вывод, что сортировку битмапа с DBKEY-кандидатами Оракл не производит.

В Oracle довольно много написано по поводу CLUSTERING_FACTOR - полагаю, это именно то, что Вы искали. Так и есть - документация подчеркивает, что индексный доступ может привести к многократному чтению одного блока таблицы.

dimitr
Возможно, отсюда сильная нелюбовь ораклового оптимизатора к RANGE SCAN - обычно выбирается либо UNIQUE SCAN (при возможности), либо HASH JOIN.

Хм. Это зависит от настроек и статистики, вряд ли возможно сформулировать такие простые и четкие правила. Если говорить об OLTP - RANGE SCAN лично я видел куда чаще, нежели HASH JOIN - возможно, из-за того, что последний потребляет относительно много памяти.

RANGE SCAN - операция, более тяготеющая к оптимизации FIRST_ROWS, HASH/MERGE JOIN - более тяготеющая к ALL_ROWS. С точки зрения FIRST_ROWS нежелание сортировать индекс полностью понятно, как понятно и нежелание тратить на это память. Нужен ли механизм доступа по rowid-сортировке в дополнение к существующим - не знаю и сходу не вижу способа найти однозначный ответ.
17 янв 05, 13:53    [1249724]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить