ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / FireBird 1.5.2 vs PostgreSQL 7.4
113 сообщений из 113, показаны все 5 страниц
  все  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32864915
Фотография mef
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mef
Участник
Ну вот, решился на свой первый топик на этом сайте. Итак.
Стою сейчас на распутье перед началом нового своего проекта - дошёл до выбора БД. Поэтому необходима помощь людей имеющих опыт работы в указанных в сабже системах.
Будущая база будет заточена в основном на работу с матетматикой. Каждая транзакция - статистический (несложный но большой по объёму данных - матожидание, СКО, и т.д.) анализ по уже накопленным данным - вычисление некоего ответа и добавление небольшого объёма по результатам вычислений. Будут, понятно, и другие типы - более пространные отчёты, затейливые выборки - но время их выполнения некритично.
Точную структуру описать не готов, но примерно в части, критичной ко времени обработки - не более десятка таблиц. Данные - в большинстве своём числовые типа int. В каждой таблице не более миллиона записей, полей - не более 5.
Пользование услугами данной системы будет платное (это важно) поэтому вопрос по стоимости лицензионной чистоты тоже важен. То есть сколько денег будет стоить лицензия с правом коммерческого использования.
Пиковая нагрузка - не более 5 запросов в секунду.
Итак, интересует у кого выше/лучше:
-устойчивость
-производительность при описанных условиях
-масштабируемость (обработка нитями - грубо говоря типовая конфигурация железа - на 500 ниток, если надо 600 - докупаем ещё один сервак, регистрируем в системе - и вперёд)
-удобство разработки (в идеале - визуальные среды разработки запросов и ХП)

Да работать будет под Linux при разработке и под FreBSD (возможно) после запуска
заранее спасибо за ответы. если чего не написал - спрашивайте
...
Рейтинг: 0 / 0
14.01.2005, 13:08
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32864991
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, mef!
Ты пишешь:

mefm> Пиковая нагрузка - не более 5 запросов в секунду.
m> Итак, интересует у кого выше/лучше:
m> -устойчивостьдостаточная
mefm> -производительность при описанных условияхтут сложно что-либо сказать,
ибо ты привёл мало информации.
Если исходить из размеров таблиц, то вполне.
mefm> -масштабируемость (обработка нитями - грубо говоря типовая конфигурация железа -
m> на 500 ниток, если надо 600 - докупаем ещё
m> один сервак, регистрируем в системе - и вперёд)Это кластер.
Ни PostgreSQL, ни FireBird, кластеры не поддерживают.
У FireBird есть 2 архитектурных варианта: CS и SS.
SS - многопоточный, но однопроцессный.
CS - для каждого коннекта порождает отдельный процесс.
Тебе больше подходит вариант CS.
Он почти линейно масштабируется на SMP.
mefm> -удобство разработки (в идеале - визуальные среды разработки запросов и ХП)
IBExpert. Для юзеров ExUSSR, у которых локаль 1251, он бесплатен.

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 13:36
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865000
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
1. FB это rule based оптимизатор, postgres - cost based
2. FB не гарантирует атомарность транзакции даже в пределах запроса, postgres помоему подерживает все уровни изолированости транзакций, кроме dirty read (sql92)
отсюда:

-устойчивость
у FB обещают инкрементный бэкап в 2.0, что у postgres незнаю.

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

см оптимизатор + в postgres можно нормально раскидывать нагрузку по файлам/дискам, так что все зависит скорее от ручек. у FB с этим (раскидыванием) кажется проблема. условия не жестокие думаю современный сервер такое легко вытянет.

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

это вам не oracle RAC, хотя наверно можно в организовать репликацию и на уровне апп-сервера балонсировать нагрузку. в postgres репликация отдельная, платная фича.

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

ХЗ
...
Рейтинг: 0 / 0
14.01.2005, 13:38
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865020
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, Yo!!
Ты пишешь:

Yo!FB не гарантирует атомарность транзакции даже в пределах запросаНе 3.14зди

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 13:44
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865041
Фотография mef
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mef
Участник
Мимопроходящий и Yo - спасибо за быстрый ответ!
Насколько я понял, по Вашему мнению, приописанных мной условиях особой разницы между постгресом и firebird не будет, так как задачка незатейливая. Но вот замечание о транзакциях в FB меня насторожила - почитаю доки.
Тип лицензии мне больше нравится у postgreSQL, у FB я так и не понял - надо им платить или нет при комм использовании - надо подробнее изучить на досуге. Ситуация со средой разработки у Poastres меня приводит в уныние, так как лет 10 пишу под форточками. Видимо со временем пристрадаюсь.
Ещё раз спасибо всем
...
Рейтинг: 0 / 0
14.01.2005, 13:52
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865050
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, mef!
Ты пишешь:

mefm> Насколько я понял, по Вашему мнению, приописанных мной условиях особой разницы между постгресом и firebird не будет,
так как
m> задачка незатейливая. Но вот замечание о транзакциях в FB меня насторожила - почитаю доки.
Больше слушай бредни этого "специалиста".
mefm> Тип лицензии мне больше нравится у postgreSQL, у FB я так и не понял -
m>надо им платить или нет при комм использовании - надо подробнее изучить на досуге.
Не надо никому ничего платить. FB полностью бесплатен для любого использования .

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 13:56
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865087
Фотография mef
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mef
Участник
а IBExpert - онт только под Windows? на http://www.ibexpert.com/ только виндовая версия доступна ...
...
Рейтинг: 0 / 0
14.01.2005, 14:08
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865093
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
>Не 3.14зди

типа не пизди и не пиздим будешь :)

http://rsdn.ru/Forum/?mid=573511

>Ситуация со средой разработки у Poastres меня приводит в уныние, так как лет 10 пишу под форточками.

сурово :) т.е. слабость оптимизатора, проблемы транзакций, невозможность нормально использовать >1 проца, существенная разница в возможностях sql и stored процедур на вас производит меньшее впечатление ?
...
Рейтинг: 0 / 0
14.01.2005, 14:10
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865094
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, mef!
Ты пишешь:

mef m> а IBExpert - онт только под Windows?
m> на http://www.ibexpert.com/ только виндовая версия доступна ...
Да. Качай оттуда полный триал. http://www.ibexpert.com/download/ibet_2004.12.14.1_full.exe
А почему спросил про Windows?

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 14:11
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865107
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, Yo!!
Ты пишешь:

Yo!Y> типа не пизди и не пиздим будешь :)
Y> http://rsdn.ru/Forum/?mid=573511
И что?
Ты в суть дискуссии то вник, или выдернул только одну фразу?

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 14:15
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865115
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
просвети :) какая суть может оравдать зависимость ответа от порядка подзапрса в sql ?
...
Рейтинг: 0 / 0
14.01.2005, 14:17
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865130
Фотография mef
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mef
Участник
Yo!>
сурово :) т.е. слабость оптимизатора, проблемы транзакций, невозможность нормально использовать >1 проца, существенная разница в возможностях sql и stored процедур на вас производит меньшее впечатление ?
Я не совсем понял, кто на ком стоял :) Эти ужасы Вы про постгрес или про FB написали?
...
Рейтинг: 0 / 0
14.01.2005, 14:22
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865148
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, Yo!!
Ты пишешь:

Yo! Y> просвети :) какая суть может оравдать зависимость ответа от порядка подзапрса в sql ?
Речь идёт он конкретном, известном косяке DELETE FROM T WHERE IN (SELECT FROM T).
Ты же заявляешь вообще про атомарность транзакций.

Иди и дальше ори Оракл-форева.

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 14:27
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865149
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
про FB, но вообще вы сами должны бы сравнить, я просто указываю на что стоит обратить особое внимание при сравнении ...

ЗЫ. если, что FB это опен соурс interbase 6.5 с небольшими дополнениями.
...
Рейтинг: 0 / 0
14.01.2005, 14:27
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865154
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, Yo!!
Ты пишешь:

Yo!ЗЫ. если, что FB это опен соурс interbase 6.5 с небольшими дополнениями.
Если что, то хорошо бы знать предмет о котором высказываешься.
Опять триндишь.

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 14:28
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865173
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
Мимопроходящий

Речь идёт он конкретном, известном косяке DELETE FROM T WHERE IN (SELECT FROM T).
Ты же заявляешь вообще про атомарность транзакций.


прием тут delete ? вы уважаемый в курсе что такое ACID ?
...
Рейтинг: 0 / 0
14.01.2005, 14:33
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865201
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, Yo!!
Ты пишешь:

Yo! Мимопроходящий
Y> Речь идёт он конкретном, известном косяке DELETE FROM T WHERE IN (SELECT FROM T).
Y> Ты же заявляешь вообще про атомарность транзакций.
Y> прием тут delete ? вы уважаемый в курсе что такое ACID ?
От тока не надо в позу становиться.
Повторяю для упёртых. Это известный косяк IB/FB.
Ты можешь указать другой?

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 14:41
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865209
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
МимопроходящийПовторяю для упёртых. Это известный косяк IB/FB.
Ты можешь указать другой?
Ничего себе косяк. Честно говоря я в шоке от такого косяка.
...
Рейтинг: 0 / 0
14.01.2005, 14:43
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865219
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, ASCRUS!
Ты пишешь:

ASCRUSA> Ничего себе косяк. Честно говоря я в шоке от такого косяка.
Не ты один
Разработчики FB тоже.
Но таково уж наследство IB.
Приходится обходить, пока не пофиксили.

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 14:45
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865274
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
Мимопроходящий
Привет, Yo!!
Ты пишешь:

Yo! Y> просвети :) какая суть может оравдать зависимость ответа от порядка подзапрса в sql ?
Речь идёт он конкретном, известном косяке DELETE FROM T WHERE IN (SELECT FROM T).
Ты же заявляешь вообще про атомарность транзакций.


Совсем утрированые примеры:

Неатомарность update:

UPDATE table_name
SET a=b, b=a
(кстати, четко регламентировано в ANSI - значения после "=" вычисляются ДО внесения любых изменений)

Неатомарность INSERT:

INSERT INTO table_name
SELECT * FROM table_name
...
Рейтинг: 0 / 0
14.01.2005, 14:57
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865337
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
Не ты один
Разработчики FB тоже.
Но таково уж наследство IB.
Приходится обходить, пока не пофиксили.


Это не косяк, а фича. Как сказал dimitr: "as designed" особенность сервера. Если знать про это то такой функционал даже полезен.

to Yo!
Оракле конечно форева, но там тоже косяков достаточно.
Просто привычка к определённому серверу провоцирует определённое мышление и когда в других серверах что-то не так начинается истерика и крики: отстой, сакс и т.д.

Просто мыслите категориями сервера и всё будет ОК.

to mef
По классу эти сервера примерно одинаковы. Однака PstgreSQL под винду вроде как работает только через Жопу, так что если сервер виндовый, то однозначно FB, если линух то ХЗ.
PS to ALL: Учите матчасть и относитесь к всему филосовски.





Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 15:15
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865348
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
я удивлен тем, что используется RBO, INSERT/UPDATE/DELETE - просто в шоке.
...
Рейтинг: 0 / 0
14.01.2005, 15:19
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865376
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
protectorPS to ALL: Учите матчасть и относитесь к всему филосовски.
Давайте возьмем неисправный калькулятор и будет филосовски относиться к тому, что выдает 2+2=5. Есть стандарт SQL и если СУБД заявляет что она его поддерживает, то она должна его поддерживать. Если же она не поддерживает такие примитивные вещи, если ее разработчики называют "это" косяком и в оправдание говорят: типа зачем это нужно, мы все равно все в циклах (курсорах) гоняем, если СУБД до сих пор не в состоянии обзавестить нормальным стоимостным оптимизатором и народ ручками впихивает планы запросов ... не знаю, может быть для примитивных задач ее и можно использовать, но я пожалуй и в таких случаях уж лучше возьму Access MDB - там во всяком случае все работает так, как описано стандартом.
...
Рейтинг: 0 / 0
14.01.2005, 15:30
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865428
Фотография mef
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mef
Участник
2 protector
Сервер точно будет крутиться под линуксом или юниксом. И писАть тоже буду под ними. Правда, составлять запросы в командной строке или текстовом редакторе меня ломает (но не сильно) так что буду искать приемлимый для себя вариант с GUI
Из сред разработки нарыл пока только knoda - на досуге попробую, и напишу.
Плюс напишу, если не лень будет, историю установки для новичков типа меня - может кому потом пригодится.
...
Рейтинг: 0 / 0
14.01.2005, 15:42
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865441
Фотография mef
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mef
Участник
2All
Может у кого ещё другие варианты решений будут, чтобы потом мне локти не кусать? Если не трудно, конечно...
...
Рейтинг: 0 / 0
14.01.2005, 15:45
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865455
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
слушайте я в этом топике кул как те слоны и указывал на конкретные технические фичи, хотя очень хотелось перейти на личности. ;)

автор
Просто привычка к определённому серверу провоцирует определённое мышление и когда в других серверах что-то не так начинается истерика и крики: отстой, сакс и т.д.


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

P.S. вроде в течении месяца зщыепкуы должны выпустить 8рку, она вроде должна работать прямо под вынь.
...
Рейтинг: 0 / 0
14.01.2005, 15:49
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865465
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
ASCRUS
Давайте возьмем неисправный калькулятор и будет филосовски относиться к тому, что выдает 2+2=5.

Давайте возьмём С++
for(i=0;i <10;i++) i--;

ASCRUS
Есть стандарт SQL и если СУБД заявляет что она его поддерживает, то она должна его поддерживать.

СУБД заявлять ничего не может - она вещь неодушевлённая. Заявлять могут люди. Кто такое сказал? В той или иной мере соответствует, здесь не соответствует. Ни одна из известных мне СУБД стандарта строго не придерживается, так уж повелось, что тут поделать.

ASCRUS
Если же она не поддерживает такие примитивные вещи, если ее разработчики называют "это" косяком и в оправдание говорят: типа зачем это нужно, мы все равно все в циклах (курсорах) гоняем,

Осторожнее с курсорами, а то как ораклоиды набегут.
Не разу не наблюдал в FB чтобы курсор в ХП был быстрее селекта. Всегда пользовался советом Кайта:
"пишите в ХП только то, что нельзя сделать запросом". Хотя увлечение ХП с сервером не связано. Это скорее сдвиг фазы у разработчика начём бы он не писал...

ASCRUS
если СУБД до сих пор не в состоянии обзавестить нормальным стоимостным оптимизатором и народ ручками впихивает планы запросов ...

Никогда таким онанизмом как написание планов руками не занимался. Хотя есть грех, планы не всегда оптимальны. Тут соглашусь.

ASCRUS
не знаю, может быть для примитивных задач ее и можно использовать, но я пожалуй и в таких случаях уж лучше возьму Access MDB - там во всяком случае все работает так, как описано стандартом.

Это каким же таким стандартом? Вы сами дано на Акцесе писали? Не смешите меня...
К тому же я Вам не запрещаю брать Акцесс: пользуйтесь на здоровье, только как же Вы без любимой Sybase ASA? Ломка не начнётся?

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 15:53
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865472
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold
Участник
Я с постгресом не работал реально, но способности его себе представляю.
В совокупности серверные возможности постгреса шире чем FB, причё значительно.
По всяким клиентским библиотекам и инструментам разработчика всё наоборот.
Для меня у FB есть огромное преимущество: костяк его разработчиков - "наши" люди, т.е. с простор СНГ. Поэтому получить квалифицированную помощь или ускорить фиксинье бага намного проще - в этом я уже убеждался неоднократно.

Что касается RAD-средств средств разработки под иксы - выбор не велик. Из OpenSource наиболее продвинутый lazarus (клон дельфи). Есть компоненты UIB, позволяющие работать с FB. Для постгреса нормальных не видил.

PS А чем отличаются rule based оптимизатор и cost based. Какие преимущества и недостатки кратко?
...
Рейтинг: 0 / 0
14.01.2005, 15:57
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865482
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Тяжелый случай. СУБД не соблюдает релляционную алгебру и меня тут пытаются убедить, что это вполне нормально.

авторЭто каким же таким стандартом? Вы сами дано на Акцесе писали? Не смешите меня...
К тому же я Вам не запрещаю брать Акцесс: пользуйтесь на здоровье, только как же Вы без любимой Sybase ASA? Ломка не начнётся?
Не так эмоционально пожалуйста. Для того круга задач, где я использую она ASA - она супер-любимая моя. Для случаев, где будет достаточно примитивной, но бесплатной СУБД спокойно можно использовать проверенные MySQL, Access, MSDE, но уж явно не Interbase при таких раскладах. Я слишком стар для таких приколов.
...
Рейтинг: 0 / 0
14.01.2005, 16:01
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865491
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
автор
PS А чем отличаются rule based оптимизатор и cost based. Какие преимущества и недостатки кратко?


cost based опирается на статистику и раставляет cost для каждой операции, далее выбирает запрос у которого наименьший cost. rule based просто по зашитым правилам пашет. если коротко, то в оракле есть RBO но его не юзают как только появился CBO (кажется в 7.3), разница в поведении просто огромна, если интересно есть туча подробностей в оракловой ветке.
...
Рейтинг: 0 / 0
14.01.2005, 16:05
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865501
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
GoldPS А чем отличаются rule based оптимизатор и cost based. Какие преимущества и недостатки кратко?
Если сказать примитивно, то rule действует по принципу - если в запросе есть поля, на которые построены индексы, то используем их, иначе используем перебор таблицы.

Cost оптимизаторы ведут статистику по таблицам и индексам, и при построении плана запроса интеллектуально рассматривают в зависимости от значений данных по статистике, нагрузке сервера, доступности свободного кэша, наличия разнообразных индексов множество вариантов построения плана запроса, учитывая различные алгоритмы соединений, фильтров и группировок и такие различные характеристики, как время доступа к накопителю, памяти, кол-во чтений, записей и т.д., фактически присваивая каждой операции стоимость и в итоге выбирают тот план запроса, который имеет наименьшую стоимость и соотвествующе наиболее выгоден для выполнения запроса. В итоге оптимизатор адекватно реагирует на запросы и в зависимости от ситуации спокойно может генерить при выполнении различные планы запросов для одного и того же запроса, наиболее выгодные на момент его выполнения.
...
Рейтинг: 0 / 0
14.01.2005, 16:09
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865517
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
GoldPS А чем отличаются rule based оптимизатор и cost based. Какие преимущества и недостатки кратко?
Кратко - rule based оптимизатор опирается на структуру данных. Cost based оптимизатор опирается на данные.

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

Cost-based оптимизатор гибко реагирует, подстраиваясь к разным значениям параметра. Rule-based оптимизатор покажет ту же стоимость в хорошем случае, но выбранный им план неудачен для второго запроса - тот нагрузит сервер в полтора раза больше.

Можно привести и более яркие примеры, но я попытался сделать максимально простой, максимально рядовой случай.

Код: 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.
SQL> create table stat (i integer, j integer, k integer);

Table created.

SQL> insert into stat select rownum, rownum, rownum
   2   from dba_objects, dba_objects where rownum <=  1000000 ;

 1000000  rows created.

SQL> create index stat_i on stat (i);

Index created.

SQL> select max(j) from stat where i<= 10 ;

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 4  Card= 1  Bytes= 10 )            
    1      0    SORT (AGGREGATE)                                                    
    2      1      TABLE ACCESS (BY INDEX ROWID) OF 'STAT' (Cost= 4  Card= 10            
          Bytes= 100 )                                                            
                                                                                
    3      2        INDEX (RANGE SCAN) OF 'STAT_I' (NON-UNIQUE) (Cost= 3  Ca          
          rd= 10 )                                                                

Statistics
----------------------------------------------------------                      
           4   consistent gets                                                    

SQL> select max(j) from stat where i<= 900000 ;

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 169  Card= 1  Bytes= 10 )          
    1      0    SORT (AGGREGATE)                                                    
    2      1      TABLE ACCESS (FULL) OF 'STAT' (Cost= 169  Card= 900001  Byte          
          s= 9000010 )                                                            
                                                                                
Statistics
----------------------------------------------------------                      
        2753   consistent gets                                                    

SQL> select /*+ RULE */ max(j) from stat where i<= 900000 ;

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=HINT: RULE                                 
    1      0    SORT (AGGREGATE)                                                    
    2      1      TABLE ACCESS (BY INDEX ROWID) OF 'STAT'                           
    3      2        INDEX (RANGE SCAN) OF 'STAT_I' (NON-UNIQUE)                     

Statistics
----------------------------------------------------------                      
        4477   consistent gets
...
Рейтинг: 0 / 0
14.01.2005, 16:16
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865526
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold
Участник
авторCost оптимизаторы ведут статистику по таблицам и индексам,
и при построении плана запроса интеллектуально рассматривают в зависимости от значений данных по статистике, нагрузке сервера, доступности свободного кэша, наличия разнообразных индексов множество вариантов построения плана запроса, учитывая различные алгоритмы соединений, фильтров и группировок и такие различные характеристики, как время доступа к накопителю, памяти, кол-во чтений, записей и т.д., фактически присваивая каждой операции стоимость и в итоге выбирают тот план запроса, который имеет наименьшую стоимость и соотвествующе наиболее выгоден для выполнения запроса. В итоге оптимизатор адекватно реагирует на запросы и в зависимости от ситуации спокойно может генерить при выполнении различные планы запросов для одного и того же запроса, наиболее выгодные на момент его выполнения.

Ну многое из вышеперечисленного FB также использует.

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

PS Не всё так плохо в FB как может показаться из этого обсуждения. :-)
...
Рейтинг: 0 / 0
14.01.2005, 16:20
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865546
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold
Участник
В общем по оптимизатору FB я не спец. Может кто-то из гуру FB или разработчиков замолви слово за оптимизатор? Он в FB какой?
...
Рейтинг: 0 / 0
14.01.2005, 16:27
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865548
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
В IB\FB оптимизатор комбинированный. Изначально был чисто стоимостный, но в Борланде его перехерили.
...
Рейтинг: 0 / 0
14.01.2005, 16:27
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865562
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
спецам по FB: а как там лог транзакций выглядет, как можно ли его защитить (продублировать) и как выглядет бэкап и рековери ? еще есть ли репликация? если да то двунаправленая или только в одну сторону ?
...
Рейтинг: 0 / 0
14.01.2005, 16:33
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865563
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Самое начало никто из присутствующих уже не помнит, допустим. Но мои наблюдения показывают, что он всегда был смешанным. Только за последние годы в борланде его "смешали" еще сильнее ;-)
...
Рейтинг: 0 / 0
14.01.2005, 16:33
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865568
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
ASCRUS
Тяжелый случай. СУБД не соблюдает релляционную алгебру и меня тут пытаются убедить, что это вполне нормально.

СУБД это не мат модель, а реальная система хранения данных. Тут уже неоднократно возникали такие споры реляцинные СУБД на самом деле или нет. Толку от этого никакого. СУБД в первую очередь должна справляться с посталенными задачами, а не соблюдать абстрактную РА, которая кстати и так не соблюдаются. А как же ваш любимый WITH RECURSIVE в ASA или CONNECT BY в Оракуле? Их нет в реляционной алгебре. Индексы вообще какое отношение имеют к РА? Навигационный метод, который так любят ораклоиды вообще к математике никакого отношения не имеет?
Я не пытаюсь Вас убедить, убедить можно не каждого, просто треплюсь по теме.
Да считаю такое положение вполне нормальным. Пока сервер справляется с поставленными задачами и удовлетворяет заказчика, то пусть хоть вместо SQL у него будет матерная брань. а вместо таблиц кубики 3X3.

ASCRUS
Не так эмоционально пожалуйста.

NP всё в порядке. Спасибо, что так волнуетесь о моём душевном сосотоянии...

ASCRUS Для того круга задач, где я использую она ASA - она супер-любимая моя.

"Любимая"?.... хм... значит Вы признаёте, что не объективны?

ASCRUS
Для случаев, где будет достаточно примитивной, но бесплатной СУБД спокойно можно использовать проверенные MySQL, Access, MSDE, но уж явно не Interbase при таких раскладах.

Во первых Акцесс не бесплатен - это раз. Если Вы проверяли MySQL и MSDE и они подходят для таких случаев, опять же повторю: пользуйтесь на здоровье. К сожалению, когда я выбирал СУБД не удосужился сравнить MSDE с FireBird. Отпугнула непереносимость на Linux. Но ничего, выберу время сравню. Если MSDE действительно лучше то что мешает взять манатки и махнуть туда.
ASCRUS
Я слишком стар для таких приколов.

Юмор продлевает жизнь! (c)
А может на пенсию? А? Отдохнёте, подлечитесь...

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
14.01.2005, 16:36
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865607
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
protectorЮмор продлевает жизнь! (c)
А может на пенсию? А? Отдохнёте, подлечитесь...
Ну как вот появиться достойная замена, пойду на пенсию :)
...
Рейтинг: 0 / 0
14.01.2005, 16:49
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865611
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
2 protector
Во первых Акцесс не бесплатен - это раз.
Не пи***те чего не знаете. Как БД - вполне себе бесплатен.
Это во первых.

Во-вторых. Никто не запрещает поддерживать какие-либо расширения стандартного SQL (всякие там Connect By и прочее). С ограниченной поддержкой стандарта также приходится мириться, действительно в полной мере никто не поддерживает. Но реализовывать что-то неправильно - это уже полная жопа. Уж лучше пусть калькулятор не будет уметь умножать и делить, чем будет бред выдавать.
...
Рейтинг: 0 / 0
14.01.2005, 16:53
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865622
mozheyko_d
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mozheyko_d
Участник
Кстати тема была Postgre vs Firebird.

Я тут пару недель назад тоже пришёл к этой вилке, пока ещё не выбрал, но судя обилию ругани в адрес ЖарПтицы и отсутствию в адрес Постгре, начинаю склоняться к последнему.
Или кто-то может поругаться на него ?
...
Рейтинг: 0 / 0
14.01.2005, 16:56
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865635
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Yo!спецам по FB: а как там лог транзакций выглядет, как можно ли его защитить (продублировать) и как выглядет бэкап и рековери ? еще есть ли репликация? если да то двунаправленая или только в одну сторону ?Парень, ты вообще в курсе - что такое FB и как он работает ?
Сильно вопросы твои пахнут... как твои же утверждения в этом топике выше ;)

Лог никак не выглядит - нет его. Читай про версионность.
Соответственно защищать\дублировать нечего ;)
Бекап - до FB 2 только полный онлайн бекап. В FB2 - ещё и инкрементный страничный.
Рековери - если ты про накат лога после сбоя, то такого процесса нет, т.к. см выше
Репликация - встроенной нет. Есть отдельные продукты, её обеспечивающие
...
Рейтинг: 0 / 0
14.01.2005, 17:00
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865643
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ASCRUSЕсть стандарт SQL и если СУБД заявляет что она его поддерживает, то она должна его поддерживать. Если же она не поддерживает такие примитивные вещи, если ее разработчики называют "это" косяком и в оправдание говорят: типа зачем это нужно, мы все равно все в циклах (курсорах) гоняем...

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

Насчет DELETE (впрочем, и INSERT тоже) - это косяк, заложенный в движок изначально. Нет в IB/FB поддержки statement stability. Впрочем, тут некоторые ругались на тему ACID и кривой поддержки уровней изоляции... это оставляю на их совести. Насчет UPDATE - затрудняюсь сказать. Вроде есть спецификация, но ИМХО когда-то это запросто могло быть vendor defined. Самое страшное, что на обе багофичи завязаны народные массы. Ну, чтож, значит опять ключики :-(

А насчет запоминать такие "страшные" вещи - это проблема для мигрантов и мультисерверников. Ты ведь в своем ASA знаешь почти все "от и до"... вот и в IB точно также помнят про эти грабли и не наступают... ибо жить они практически не мешают.

Закончу тем, что "разработчики" эти проблемы не особо и оправдывали. И не вижу ничего плохого в том, чтобы называть известные проблемы "косяками" ;-)
...
Рейтинг: 0 / 0
14.01.2005, 17:05
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865648
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
>Или кто-то может поругаться на него ?

поругать ? да легко :)
1. главная фишка что его нельза поставить по дефолту и начать работать, придется почитать мануал и хотябы одэкватно настроить память и привыкать к command line.
2. нет человеческого админского тула, зато есть некая RedHat database это тот же postgres но с графической тулзой для администрирования. дают ее вместе с RHEL, но на меня она произвела удручающее впечатление уж лучше command line.
...
Рейтинг: 0 / 0
14.01.2005, 17:07
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865657
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
Yo!спецам по FB: а как там лог транзакций выглядет,

Никак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком.
И при этом придумывают протоколирования действий на триггерах,
какие-то исскуственные схемы для реализации наката.
(см http://www.ibase.ru/devinfo/doc_calford_1.htm )
Yo!
как можно ли его защитить (продублировать) и как выглядет бэкап и рековери ?

Есть утилита для бэкапа gbak. Делает только полный бэкап. При этом крайне рекомендуется после
бэкапа сделать контрольное восстановление, ибо в FB есть такое понятие, как
Невосстановимый бэкап (sic!)


Инкрементальный бэкап будет только в FB 2.
Yo!
еще есть ли репликация? если да то двунаправленая или только в одну сторону ?

Штатных средств репликации нет. Есть великое множество сторонних репликаторов, но количество не означает качество.

Для более подробной информации рекомендую
http://ibase.ru
- главный российский сайт по IB/FB/Ya
...
Рейтинг: 0 / 0
14.01.2005, 17:10
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865664
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
hvladЛог никак не выглядит - нет его. Читай про версионность.
А если есть лог - то это блокировочник что-ли получается?
Мои поздравления ораклоидам

Александр ГoлдунНикак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком.
Мдя... Ну и многим фанатам IB тоже поздравления
...
Рейтинг: 0 / 0
14.01.2005, 17:13
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865665
mozheyko_d
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mozheyko_d
Участник
Yo!1. главная фишка что его нельза поставить по дефолту и начать работать, придется почитать мануал и хотябы одэкватно настроить память

Ну это IMHO относится ко всем СУБД. Особенно к хвалёному Oracle.

Yo! и привыкать к command line.
2. нет человеческого админского тула, зато есть некая RedHat database это тот же postgres но с графической тулзой для администрирования. дают ее вместе с RHEL, но на меня она произвела удручающее впечатление уж лучше command line.

Ну это не пугает. Кстати FB тоже GUI встроенного не имеет. IBExpert под Линух не видел, а все найденные под Линух тулзы это слёзы.
...
Рейтинг: 0 / 0
14.01.2005, 17:14
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865671
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
mozheyko_dсудя обилию ругани в адрес ЖарПтицы и отсутствию в адрес Постгре, начинаю склоняться к последнему. Или кто-то может поругаться на него ?

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

Если объективно, то самым серъезным недостатком Постгреса является отсутствие до недавнего времени родного win32-порта. В 8-ке он вроде наконец-то сделан, но релиза пока нет. В остальном неплох. Раньше про него много дурного писали, но вроде в различных подверсиях 7-ки потихоньку грабли правятся.

С FB можно отлично жить, если его умеешь готовить. У меня ни один проект не был загублен из-за "гиперстрашных косяков" или обилия ругани ;-)
...
Рейтинг: 0 / 0
14.01.2005, 17:21
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865687
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Да жить можно с чем угодно, если знать что это и как бороться. Но вот зачем человеку рекомендовать то, что заведомо ему неподходит (возвращаясь к теме топика) и который судя по всему не знает как бороться с "косяками" (раз поднял такую тему) - я не понимаю. Это отдает фанатизмом, а не здравым смыслом.
...
Рейтинг: 0 / 0
14.01.2005, 17:26
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865692
mozheyko_d
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mozheyko_d
Участник
dimitr
Если объективно, то самым серъезным недостатком Постгреса является отсутствие до недавнего времени родного win32-порта. В 8-ке он вроде наконец-то сделан, но релиза пока нет.

Windows не интересует.

dimitrВ остальном неплох. Раньше про него много дурного писали, но вроде в различных подверсиях 7-ки потихоньку грабли правятся.

А чё за грабли?
...
Рейтинг: 0 / 0
14.01.2005, 17:28
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865694
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ASCRUSНо вот зачем человеку рекомендовать то, что заведомо ему неподходитУверен ?
"Это отдает фанатизмом, а не здравым смыслом" (c) ASCRUS
...
Рейтинг: 0 / 0
14.01.2005, 17:31
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865701
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Александр ГoлдунНикак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком. И при этом придумывают протоколирования действий на триггерах, какие-то исскуственные схемы для реализации наката.

Саш, ну ты-то хоть не путай народ. Ты ведь говоришь про redo log, а фанаты - про undo. Необходимость второго в версионнике - нонсенс. А вот первый весьма бы не помешал для incremental recovery. И с этим никто не спорит, собственно.
...
Рейтинг: 0 / 0
14.01.2005, 17:36
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865726
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
hvlad ASCRUSНо вот зачем человеку рекомендовать то, что заведомо ему неподходитУверен ?
"Это отдает фанатизмом, а не здравым смыслом" (c) ASCRUS
Во первых мы на "ТЫ" вроде как не переходили. Во вторых переход на личности осуществляется участниками за недостатком аргументов (это к слову о предыдущих на меня выступлениям по поводу пенсии). В третьих полностью уверен благодаря приведенным в данном топике примерам. В четвертых цитировать кого либо мало - необходимо вдумываться. Ну и в последних - я не очень понимаю, чего так реагировать, вроде как никто интербейсников в ущербности продукта не обвинял, всего лишь перечислили факты и каждый для себя сделал соотвествующие выводы, откуда такой возник комплекс неполноценности лично у Вас - ведь другие специалисты Interbase в этом топике вроде как адекватно реагируют на все высказывания, признают недостатки и подчеркивают его достоинства.
...
Рейтинг: 0 / 0
14.01.2005, 17:52
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865731
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
dimitr Александр ГoлдунНикак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком. И при этом придумывают протоколирования действий на триггерах, какие-то исскуственные схемы для реализации наката.

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

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

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

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

Кстати, вопрос: в FB2 уже будет распараллеливание запросов при общем кэше?
...
Рейтинг: 0 / 0
14.01.2005, 17:57
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865761
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ASCRUSВо первых мы на "ТЫ" вроде как не переходили. imho это общепринято, ок, будем на Вы (если вообще будем)

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

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

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

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

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

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

Все вопросы - риторические, можно не отвечать
...
Рейтинг: 0 / 0
14.01.2005, 18:12
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865892
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Страшен пятничный флейм, бессмысленный и беспощадный (с)

ЗЫ. Это я вместо финала ;-) Хотя шибко сомневаюсь, что автору топика мы сильно помогли...
...
Рейтинг: 0 / 0
14.01.2005, 20:36
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32865915
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
А почему выбор именно между FireBird 1.5.2 и PostgreSQL 7.4?

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


Оба упомянутых сервера бесплатны. Но если проект коммерческий, то может есть смысл не ограничиваться этими серверами, а расмотреть еще и коммерческие и все тщательно взвесить?
В моей личной практике в большинстве проектов стоимость сервера компенсировалась с лихвой уменьшением стоимости разработки и сопровождения по сравнению с использованием бесплатных серверов.
...
Рейтинг: 0 / 0
14.01.2005, 21:08
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32866058
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
Странно, почему-то Sad Spirit отсутствует :), тема самая что ни на есть его! (наверное после праздников все никак не отойдет)

...
Рейтинг: 0 / 0
15.01.2005, 00:43
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32866262
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
Рыжий КотСтранно, почему-то 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, он вроде бы специально приспособлен для такой обработки, о которой шла речь в исходном сообщении.
...
Рейтинг: 0 / 0
15.01.2005, 12:59
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32866296
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nik_x
Участник
[quot Sad Spirit]
...
Но вертикальная масштабируемость хорошая, так что можно просто поставить более мощный сервер.

[quot ]

А что, уже выпустили Embedded Posgres, такой как в FB?
...
Рейтинг: 0 / 0
15.01.2005, 14:03
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32866807
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mv
Участник
Уважаемый mef !
Описанные в начале ветви требования эмулируются с вполне допустимыми трудозатратами.
Впрочем, может быть, спросивший mef больше интересуется психоанализом, чем техническими особенностями выбираемого инструментального средства.

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

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

Более того, если здесь Вы спросите по поводу того, что один из результатолв тестов не удовлетворяют Вас в чем-то, то здесь Вы моментально получите совет и рекомендацию. Только спрашивать об InterBase нужно в разделе InterBase, а о MS SQL - в разделе MS SQL.
...
Рейтинг: 0 / 0
16.01.2005, 20:35
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32866838
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
hvlad.
+++++++++++++++++++++++++
На SQL.ru принято обращаться на "Вы". За исключением форумов Просто Треп и AREA-51.
...
Рейтинг: 0 / 0
16.01.2005, 22:55
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867213
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, Cat2!
Ты пишешь:

Cat2C> На SQL.ru принято обращаться на "Вы".
За исключением форумов Просто Треп и AREA-51.
Опять, Кот, самодурствуешь?!
Где это в правилах?!
Нету?
Ну и нех!

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
17.01.2005, 10:53
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867225
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Cat2hvlad.
+++++++++++++++++++++++++
На SQL.ru принято обращаться на "Вы". За исключением форумов Просто Треп и AREA-51. Это не отражено в правилах форума, посему каждый выбирает форму обращения по своему разумению.
Если собеседник возражает, это его право. Ничего оскорбительного я в этом не вижу.
...
Рейтинг: 0 / 0
17.01.2005, 10:55
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867273
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Кстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я понял, что версионность в нем означает, что на DML команды нет понятия эклюзивной блокировки, то есть поддерживается версионность для изменений записи ? Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?

Я понимаю версионность Оракла в том плане, что она позволяет во время изменения записи читателям работать с ее оригинальной версией, но писатели там друг друга блокируют (что есть правильно). Но вот зачем делать версионность писателей и из за этого получать такую сложную модель физической реализации движка я понять не могу. Буду очень признателен, если просветите по этому вопросу или же поправите меня там, где я ошибаюсь. Как говорится учиться ни когда не вредно, во всяком случае меня интересуют различные модели реализации поддержки уровней изоляции в блокировочниках и версионниках, их механизмы работы и достоинства и недостатки. Пока вот для меня модель версионности Interbase загадка, хотя я честно почитал на эту тему различную литературу, выложенную на ibase.ru и вроде как чего то понял.
...
Рейтинг: 0 / 0
17.01.2005, 11:06
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867299
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, ASCRUS!
Ты пишешь:

ASCRUS A> Кстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я
понял, что
A> версионность в нем означает, что на DML команды нет понятия эклюзивной блокировки, то есть поддерживается версионность для
A> изменений записи ? Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?
http://www.ibase.ru/devinfo/versions.htm

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
17.01.2005, 11:13
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867416
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ASCRUSКстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я понял, что версионность в нем означает, что на DML команды нет понятия эклюзивной блокировкиВ том смысле, как в MS - нет такого понятия, ибо оно не нужно.

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

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

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

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

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

PS Ничего, что я цитирую ? ;)
...
Рейтинг: 0 / 0
17.01.2005, 11:51
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867464
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторPS Ничего, что я цитирую ? ;)
Наоборот, спасибо. Приведенную выше ссылку я уже читал, но решил, что лучше уточнить, чем делать выводы исходя из того, что понял :) Все таки тяжеловатый механизм - версионность индексов это конечно круто, кстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?
...
Рейтинг: 0 / 0
17.01.2005, 12:10
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867490
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ASCRUS версионность индексов это конечно круто, кстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?
Хм. Боюсь, я не очень понимаю, в чем разница. Разница с архитектурой Oracle, судя по указанной статье - "старая версия записи" пишется куда-то в data file, в то время как Oracle использует rollback segment. А Oracle спокойно использует "кластерные индексы" - соответственно, механизм работает. Как именно - сходу не скажу, надо смотреть доки.
...
Рейтинг: 0 / 0
17.01.2005, 12:20
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867496
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Кластерный индексов действительно нет и их действительно сделать затруднительно. Да и насчет обычных индексов есть неприятные ограничения. Сейчас хранится один ключ индекса на все версии записи (ID транзакции в ключ не входит). Отсюда невозможность index-only scan, ибо для каждого выбранного ключа придется читать запись с диска и определять видимость для текущей транзакции. Можно сделать полную версионность в индексе, введя в ключ txn ID, но это приведет к модификации всех индексов при каждом изменении записи, даже если затронуты неиндексированные поля. Пока считается, что это слишком большая цена. Да и последующая сборка мусора в таком "загаженном" индексе будет заметно тяжелее, чем сейчас. Вот такова селяви насчет индексов в версионнике.
...
Рейтинг: 0 / 0
17.01.2005, 12:24
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867568
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ASCRUSВсе таки тяжеловатый механизм - версионность индексов это конечно крутоА кто тут говорил про версионность индексов ? ;)
Индексы - отдельная песня. Версий там нет. Когда появляется новый ключ (insert\update ключевых полей), он вставляется в b-tree. И всё.
Любой индексный метод доступа должен, после построения списка номеров записей-кандидатов, посетить запись и убедиться что она все ещё удовлетворяет критерию отбора и может быть видна читающей тр-ции.

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

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

ASCRUSкстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?Их нет потому что они не дадут столь большого выигрыша в призводительности, как у других серверов.
В FB любой индексный метод доступа сначала сканирует индекс, а потом читает таблицу. Причём таблица читается в порядке номеров страниц, т.е. как кластерная таблица у MS.
...
Рейтинг: 0 / 0
17.01.2005, 12:51
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867583
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
softwarerХм. Боюсь, я не очень понимаю, в чем разница. Разница с архитектурой Oracle, судя по указанной статье - "старая версия записи" пишется куда-то в data file, в то время как Oracle использует rollback segment.

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

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

Мне кажется, тут проблема в производительности. Перелопачивать index organized table при каждом незакоммиченном изменении ключа... а потом перелопачивать обратно при сборке мусора после роллбека...
...
Рейтинг: 0 / 0
17.01.2005, 12:55
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867608
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
hvladПричём таблица читается в порядке номеров страниц, т.е. как кластерная таблица у MS.

Кстати, этот нюанс - вроде как один из плюсов IB/FB против Оракла. Я специально делал замеры и вышел на вывод, что сортировку битмапа с DBKEY-кандидатами Оракл не производит. Сканирование с INDEX-планом на неуникальном индексе FB выполняет в два-три раза быстрее (при неполном кешировании данных сервером, есс-но), чем оракловый RANGE INDEX SCAN. Возможно, отсюда сильная нелюбовь ораклового оптимизатора к RANGE SCAN - обычно выбирается либо UNIQUE SCAN (при возможности), либо HASH JOIN. Возможно, кто-либо здесь подтвердит или опровергнет это наблюдение.
...
Рейтинг: 0 / 0
17.01.2005, 13:03
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867726
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
dimitrОракл хранит не версии записей, а версии блоков, насколько я в курсе.
Это так. Но я не вижу тут идеологически существенной разницы - имхо это технический момент. Плюс такого подхода, по моим представлениям, в том, что версионность получается как бы автоматической для всех объектов данных - ну и еще в том, что когда-то, до знакомства с Oracle, я писал движок на том же принципе :) Но версионность по записям вроде бы не мешает сделать то же.

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

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

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

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

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

Итог: разумеется, при неудачном использовании будут тормоза. Сделать вроде как можно, и использовать во благо - тоже.
...
Рейтинг: 0 / 0
17.01.2005, 13:38
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867779
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
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-сортировке в дополнение к существующим - не знаю и сходу не вижу способа найти однозначный ответ.
...
Рейтинг: 0 / 0
17.01.2005, 13:53
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867798
DimaR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DimaR
Участник
to dimitr
Пусть меня поправят, но

RANGE SCAN - обычно выбирается либо UNIQUE SCAN
и
либо HASH JOIN.

вроде как разные вещи, первое это метод доступа к данным,
а второе способ объединения таблиц???
...
Рейтинг: 0 / 0
17.01.2005, 14:01
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867823
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
DimaRвроде как разные вещи, первое это метод доступа к данным,
а второе способ объединения таблиц???
Имеется в виду следующее: A JOIN B может быть выполнено как FULL TABLE SCAN (A) -> INDEX RANGE/UNIQUE SCAN (a->b) -> TABLE SCAN BY INDEX ROWID (B), а может - как FULL TABLE SCAN (A) -> HASH/MERGE JOIN <- FULL TABLE SCAN (B).
...
Рейтинг: 0 / 0
17.01.2005, 14:07
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867837
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
softwarer- В первую очередь, проблемы долгого rollback-а относительно неважны. То есть я не видел систем, где был бы удобен регулярный rollback - и я бы назвал такое неправильным дизайном даже в отрыве от архитектуры конкретной БД.

Согласен. Но мусор может накопиться не только от роллбеков. А его сборка - самый неприятный момент.

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

Тоже согласен.

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

Если цепочек нет, то объем I/O при изменении IOT значительно больше, чем в случае изменения листа b-tree. Даже если ширина IOT небольшая.

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

Если ключевое поле не менялось, то IB/FB индексы не перестраивает. А для версионного индекса это придется делать всегда. Насчет IOT - надо делать и тестить. Но, как уже Влад написал, офигительного преимущества на чтении не ожидается. Отсюда и скепсис.

softwarerИтог: разумеется, при неудачном использовании будут тормоза. Сделать вроде как можно, и использовать во благо - тоже.

Это относится почти к любой фиче любого сервера ;-)
...
Рейтинг: 0 / 0
17.01.2005, 14:11
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867893
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
softwarerВ Oracle довольно много написано по поводу CLUSTERING_FACTOR - полагаю, это именно то, что Вы искали. Так и есть - документация подчеркивает, что индексный доступ может привести к многократному чтению одного блока таблицы.

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

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

Я правила не рискну формулировать, уж шибко много факторов. Это были наблюдения. Даже при выборке из одной большой таблицы, оракл очень часто выбирает FULL SCAN вместо INDEX RANGE SCAN, даже для относительно неплохой селективности индекса и наличия менее десятка искомых значений в индексе (статистика свежая). При этом стоило выбрать значение из уникального поля, как сразу появлялся INDEX UNIQUE SCAN. Т.е. разница в 10-20 логических чтений уже заметно меняет картину.

softwarerНужен ли механизм доступа по rowid-сортировке в дополнение к существующим - не знаю и сходу не вижу способа найти однозначный ответ.

Тут я тоже не знаю ответа. Все таки у Оракла много альтернативных методов доступа к данным и вероятность подобрать более-менее хороший вариант довольно высока. У IB/FB с этим много хуже, поэтому качество индексного сканирования имеет бОльшее значение.
...
Рейтинг: 0 / 0
17.01.2005, 14:28
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867929
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
dimitrДа и насчет обычных индексов есть неприятные ограничения. Сейчас хранится один ключ индекса на все версии записи (ID транзакции в ключ не входит). Отсюда невозможность index-only scan, ибо для каждого выбранного ключа придется читать запись с диска и определять видимость для текущей транзакции."Невозможность index-only scan" имеет место и в постгресе. :(

А как в FB производится сборка мусора, статистики? Нам в постгресе пршлось запускать ежедневно 1) vacuum (помечает удаленные и измененные строки, как пригодные к повторному использованию), 2) vacuum analyze (сбор статистики), еженедельно - 3) reindex (перестраивает индексы), 4) vacuum full (удаляет из db-файла удаленные/измененные строки).
...
Рейтинг: 0 / 0
17.01.2005, 14:38
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867982
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
dimitrСогласен. Но мусор может накопиться не только от роллбеков. А его сборка - самый неприятный момент.
Пожалуй, я не готов предметно рассуждать о мусоре в Oracle без консультации с документацией. Насколько я помню, основной фактор мусора - пометки о блокировках в блоках (независимо от того, блоки ли это таблицы, IOT итп), и их очистка сделана максимально плавно - так, чтобы она не тормозила транзакцию, но сколь возможно выполнялась в фоне.

dimitrЕсли цепочек нет, то объем I/O при изменении IOT значительно больше, чем в случае изменения листа b-tree. Даже если ширина IOT небольшая.
Можно пояснить поподробнее?

dimitrЕсли ключевое поле не менялось, то IB/FB индексы не перестраивает. А для версионного индекса это придется делать всегда.
Боюсь, снова не понял. Если ключевое поле не меняется - я не вижу никаких причин перестраивать индекс. Если хотите - могу вечером провести эксперимент, но почти уверен, что Oracle такого не делает.

dimitrНасчет IOT - надо делать и тестить. Но, как уже Влад написал, офигительного преимущества на чтении не ожидается. Отсюда и скепсис.
Хм. Насколько я понимаю, "первичный" фактор преимущества IOT - замена двух чтений (индекс + данные) одним. Дело тут не только в кластеризации, но и в элементарном хранении одних и тех же данных в двух экземплярах; в том, что IOT занимает меньше места, нежели table+index. Ожидаемый эффект от этого можно попробовать оценить, хотя я не слишком удивлюсь, если оценка будет "слишком мало, чтобы тратить на это силы".

Другой момент - IOT/кластеризация избравляет от необходимости постоянно сортировать индекс в памяти. Полагаю, это не такая уж дешевая операция; по поводу выигрыша в этом месте я более оптимистичен.

dimitrЭто относится почти к любой фиче любого сервера ;-)
На это и намек ;-)
...
Рейтинг: 0 / 0
17.01.2005, 14:49
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32867993
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
LeXa NalBatА как в FB производится сборка мусора, статистики? Нам в постгресе пршлось запускать ежедневно 1) vacuum (помечает удаленные и измененные строки, как пригодные к повторному использованию), 2) vacuum analyze (сбор статистики), еженедельно - 3) reindex (перестраивает индексы), 4) vacuum full (удаляет из db-файла удаленные/измененные строки).

Сборка мусорных версий происходит автоматически - либо во время чтения цепочки версий, либо отложенно (в фоне). Если слот на странице данных освободился (мусорные версии удалены), это место сразу помечается как свободное (доступное к новой записи). Т.е. никаких ручных операций выполнять не надо. Единственное исключение - глобальная сборка всего мусора в базе и продвижение состояния транзакций в TIP (transacton inventory page) - может выполняться или автоматом по мере замусоривания (порог настраивается для каждой базы) или вручную, отдельной программой (ночью, например).

Сбор статистики выполняется отдельной SQL-командой. Перестройка индексов возможна тоже через SQL, но на практике применяется крайне редко.

Реальное уменьшение размера базы (shrink/compact в терминологии других СУБД, т.е. перепаковка данных на страницах) не выполняется никогда. Единственный путь - полный backup/restore.
...
Рейтинг: 0 / 0
17.01.2005, 14:51
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868005
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
К моему предыдущему посту - ни одна из описанных операций не блокирует работу других коннектов.
...
Рейтинг: 0 / 0
17.01.2005, 14:54
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868011
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
LeXa NalBatА как в FB производится сборка мусора, статистики? Нам в постгресе пршлось запускать ежедневно 1) vacuum (помечает удаленные и измененные строки, как пригодные к повторному использованию), 2) vacuum analyze (сбор статистики), еженедельно - 3) reindex (перестраивает индексы), 4) vacuum full (удаляет из db-файла удаленные/измененные строки).Сборка мусора выполняется (вкратце)
- в фоне самим сервером или при чтении "удалённых" записей (зависит от архитектуры сервера SS\CS, механизм не очень эффективен, в FB2 есть улучшения)
- Принудительно, по желанию пользователя - sweep

Рекомендуется делать ежедневный sweep, это 1) + 4) в вышеназванных терминах, если я их правильно понял.

Сбор статистики - по желанию. SET STATISTICS INDEX <index_name>

Перестройка индексов - никогда, а зачем ? ;)
Обычно, если БД сильно фрагментирована физически, делают бекап\рестор. Не чаще чем раз в 6-12 месяцев. Естественно, это зависит от интенсивности работы с БД.

Если кто-нибудь даст ссылку на документацию PostgreSQL'а о внутренних механизмах (или приведёт сюда русскоговорящего разработчика ;), можно будет сравнивать более предметно.
...
Рейтинг: 0 / 0
17.01.2005, 14:55
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868063
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold
Участник
А какие-такие улучшения есть в FB 2 ?
Также мне не понятно будут ли в FB 2 двунаправленные индексы.
Ещё интересно узнать по поводу внедрения аналогичных улучшений, которые в IB 7 или 7.1 сильно ускоряют массовые удаления. Будет ли такое в 2.0 ?
...
Рейтинг: 0 / 0
17.01.2005, 15:08
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868084
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
softwarer dimitrЕсли ключевое поле не менялось, то IB/FB индексы не перестраивает. А для версионного индекса это придется делать всегда. Боюсь, снова не понял. Если ключевое поле не меняется - я не вижу никаких причин перестраивать индекс. Если хотите - могу вечером провести эксперимент, но почти уверен, что Oracle такого не делает.Данные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс.

softwarerДругой момент - IOT/кластеризация избравляет от необходимости постоянно сортировать индекс в памяти. Полагаю, это не такая уж дешевая операция; по поводу выигрыша в этом месте я более оптимистичен.Индекс не сортируется в памяти - он отсортирован на диске ;) На самом деле строится битовая карта физических номеров записей. Она по-определению упорядоченна, занимает относительно немного места (разреженный битмап) и достаточно дёшево строится
...
Рейтинг: 0 / 0
17.01.2005, 15:15
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868100
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
GoldА какие-такие улучшения есть в FB 2 ? Всяческие ;) imho, здесь это оффтоп ;)

GoldТакже мне не понятно будут ли в FB 2 двунаправленные индексы.Нет

GoldЕщё интересно узнать по поводу внедрения аналогичных улучшений, которые в IB 7 или 7.1 сильно ускоряют массовые удаления. Будет ли такое в 2.0 ?Да, и даже лучше ;)
...
Рейтинг: 0 / 0
17.01.2005, 15:20
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868113
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
dimitrЯ правила не рискну формулировать, уж шибко много факторов. Это были наблюдения. Даже при выборке из одной большой таблицы, оракл очень часто выбирает FULL SCAN вместо INDEX RANGE SCAN, даже для относительно неплохой селективности индекса и наличия менее десятка искомых значений в индексе (статистика свежая). При этом стоило выбрать значение из уникального поля, как сразу появлялся INDEX UNIQUE SCAN. Т.е. разница в 10-20 логических чтений уже заметно меняет картину.
Полагаю, именно UNIQUE тут малосущественно - что собственно видно в приведенном ниже примере. CLUSTERING_FACTOR же - действительная существенная в Oracle причина неиспользования индексов.

Код: 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.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
SQL> create table clustered as select rownum a, rownum b, rownum c
   2   from dba_objects ;

SQL> create index clustered_i on clustered (a);

SQL> create table badclustered as select rownum a, rownum b, rownum c
   2   from dba_objects order by dbms_utility.get_hash_value(rownum, 0 , 65536 );

SQL> create index badclustered_i on badclustered (a);

SQL> select index_name, clustering_factor 
   2   from dba_indexes
   3   where owner = 'TEST' and index_name like '%CLUSTER%';

INDEX_NAME                     CLUSTERING_FACTOR
------------------------------ -----------------
BADCLUSTERED_I                              47520 
CLUSTERED_I                                   129 

SQL> select * from clustered where a between  0  and  1500 ;

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=CHOOSE
    1      0    TABLE ACCESS (FULL) OF 'CLUSTERED'

Statistics
----------------------------------------------------------                      
         233   consistent gets                                                    
        1500   rows processed                                                     

SQL> select * from clustered where a between  0  and  1200 ;

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=CHOOSE
    1      0    TABLE ACCESS (BY INDEX ROWID) OF 'CLUSTERED' 
    2      1      INDEX (RANGE SCAN) OF 'CLUSTERED_I' (NON-UNIQUE)

Statistics
----------------------------------------------------------                      
         167   consistent gets                                                    
        1200   rows processed                                                     

SQL> select * from badclustered where a between  0  and  5 ;

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=CHOOSE 
    1      0    TABLE ACCESS (BY INDEX ROWID) OF 'BADCLUSTERED'  
    2      1      INDEX (RANGE SCAN) OF 'BADCLUSTERED_I' (NON-UNIQUE)

Statistics
----------------------------------------------------------                      
           8   consistent gets                                                    
           5   rows processed                                                     

SQL> select * from badclustered where a between  0  and  8 ;

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=CHOOSE  
    1      0    TABLE ACCESS (FULL) OF 'BADCLUSTERED' 

Statistics
----------------------------------------------------------                      
         134   consistent gets                                                    
           8   rows processed                                                     

SQL> drop index badclustered_i;

SQL> create unique index badclustered_i2 on badclustered (a);

SQL> select * from badclustered where a between  0  and  8 ;

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=CHOOSE  
    1      0    TABLE ACCESS (FULL) OF 'BADCLUSTERED'              
                                                                                
Statistics
----------------------------------------------------------                      
         134   consistent gets                                                    
           8   rows processed                                                     

SQL> select * from badclustered where a between  0  and  5 ;

Execution Plan
----------------------------------------------------------                      
    0       SELECT STATEMENT Optimizer=CHOOSE 
    1      0    TABLE ACCESS (BY INDEX ROWID) OF 'BADCLUSTERED' 
    2      1      INDEX (RANGE SCAN) OF 'BADCLUSTERED_I2' (UNIQUE)

Statistics
----------------------------------------------------------                      
           8   consistent gets                                                    
           5   rows processed
...
Рейтинг: 0 / 0
17.01.2005, 15:25
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868129
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
softwarerПожалуй, я не готов предметно рассуждать о мусоре в Oracle без консультации с документацией.

Я тем более не готов, применительно к Ораклу ;-) Хотя было бы познавательно.

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

softwarer dimitrЕсли цепочек нет, то объем I/O при изменении IOT значительно больше, чем в случае изменения листа b-tree. Даже если ширина IOT небольшая.
Можно пояснить поподробнее?

Свои слова про "значительно" беру обратно. Зависимость существует только от ширины IOT. Я почему-то сначала подумал не про b-tree хранение, а про непосредственное (последовательное) физическое упорядочивание данных в блоках.

softwarerБоюсь, снова не понял. Если ключевое поле не меняется - я не вижу никаких причин перестраивать индекс. Если хотите - могу вечером провести эксперимент, но почти уверен, что Oracle такого не делает.

Мы говорили про "чисто версионный индекс", который бы позволил index-only scan. Для этого в ключ индекса надо внести transaction ID, который бы позволил определить видимость данной записи без чтения самой записи. Отсюда вывод - если меняется запись другой транзакцией даже без изменения ключевых полей, то нужно добавить ключ во все существующие индексы - со старым значением и новым txn ID. Иначе поиск будет бессмысленным.

Я не сомневаюсь, что Оракл этого не делает ;-) У него все же заметно другая схема версионности.

softwarerХм. Насколько я понимаю, "первичный" фактор преимущества IOT - замена двух чтений (индекс + данные) одним. Дело тут не только в кластеризации, но и в элементарном хранении одних и тех же данных в двух экземплярах; в том, что IOT занимает меньше места, нежели table+index. Ожидаемый эффект от этого можно попробовать оценить, хотя я не слишком удивлюсь, если оценка будет "слишком мало, чтобы тратить на это силы".

Согласен.

softwarerДругой момент - IOT/кластеризация избравляет от необходимости постоянно сортировать индекс в памяти. Полагаю, это не такая уж дешевая операция; по поводу выигрыша в этом месте я более оптимистичен.

Хммм. Теперь я прошу пояснить, что есть "постоянная сортировка индекса в памяти" и для чего это надо.
...
Рейтинг: 0 / 0
17.01.2005, 15:28
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868157
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
hvladДанные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс.
Это совершенно не обязательно. То есть я вполне верю, что IB работает именно так, но глобальной необходимости в этом я не вижу.

Исходные данные - у нас есть индекс, в котором хранится некий "адрес записи". Запись изменилась. В результате у нас где-то есть старая версия записи, где-то есть новая версия записи. Как минимум одна из этих записей лежит по старому адресу (иное глупо). Таким образом, достаточно иметь операцию "получить версию записи X, соответствующую контексту Y", чтобы не нуждаться во включении контекста - "версионного ключа" в индекс.

hvladНа самом деле строится битовая карта физических номеров записей.
Это и есть сортировка - индекс, отсортированный по данным, пересортировывается в порядке адресов. Относительная цена этой операции - непростой вопрос, который вряд ли можно оценить на пальцах.
...
Рейтинг: 0 / 0
17.01.2005, 15:36
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868215
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
softwarer hvladДанные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс.Это совершенно не обязательно. То есть я вполне верю, что IB работает именно так, но глобальной необходимости в этом я не вижу.Как раз IB так не работает, т.к. нет такого понятия, как версионный индекс

softwarerИсходные данные - у нас есть индекс, в котором хранится некий "адрес записи". Запись изменилась. В результате у нас где-то есть старая версия записи, где-то есть новая версия записи. Как минимум одна из этих записей лежит по старому адресу (иное глупо). Таким образом, достаточно иметь операцию "получить версию записи X, соответствующую контексту Y", чтобы не нуждаться во включении контекста - "версионного ключа" в индекс.Не понято. В индексе хранятся ключи + указатели на записи. "Адрес" записи при редактировании не меняется.
Что такое "версионный ключ" и "версионный индекс" мне (и IB\FB) неизвестно.

softwarer hvladНа самом деле строится битовая карта физических номеров записей.
Это и есть сортировка - индекс, отсортированный по данным, пересортировывается в порядке адресов. Относительная цена этой операции - непростой вопрос, который вряд ли можно оценить на пальцах.Нет! Данные индекса (ключи записей) не сортируются. "Сортируются" только номера записей. Строго говоря самой сортировки при этом не происходит, разве что поиск (двоичный) в массиве (р-р которого меньше, чем кол-во эл-тов в нём ;). Цена, по сравнению с затратами на собственно сканирование индекса, - весьма невелика
...
Рейтинг: 0 / 0
17.01.2005, 15:56
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868251
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
hvladПерестройка индексов - никогда, а зачем ? ;) REINDEX в PostgreSQL 7.4 , REINDEX в PostgreSQL 7.3 . По прошествии примерно года эксплуатации системы на PostgreSQL 7.3 (без регулярного reindex-а), объемы файлов некоторых индексов стали занимать в сотни раз больше места, чем требуется.

hvladЕсли кто-нибудь даст ссылку на документацию PostgreSQL'а о внутренних механизмахВот дока по версии 7.4 . "Внутренние механизмы", которые обсуждались в этом топике, и раздел доки "VII. Internals" наверное коррелируют, но не совпадают. :)
...
Рейтинг: 0 / 0
17.01.2005, 16:09
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868291
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
softwarerТаким образом, достаточно иметь операцию "получить версию записи X, соответствующую контексту Y", чтобы не нуждаться во включении контекста - "версионного ключа" в индекс.

Эта информация лежит в версиях записей ;-) Т.е. либо приходим к тому, с чего начали (надо читать сами записи), либо осознаем необходимость дополнительно кешировать цепочку backversions вместо с их txn ID.

softwarerЭто и есть сортировка - индекс, отсортированный по данным, пересортировывается в порядке адресов. Относительная цена этой операции - непростой вопрос, который вряд ли можно оценить на пальцах.

Сортируются только адреса. Цена может стать заметной на определенном (весьма немаленьком) размере битмапа. Полагаю, что IOT действительно покажет себя лучше на больших выборках. Вот только насколько велик процент задач с большим объемом данных и неуникальными выборками только по кластерному ключу?
...
Рейтинг: 0 / 0
17.01.2005, 16:21
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868359
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
LeXa NalBatПо прошествии примерно года эксплуатации системы на PostgreSQL 7.3 (без регулярного reindex-а), объемы файлов некоторых индексов стали занимать в сотни раз больше места, чем требуется.

Чудно как-то. Скорее всего, имеется недоработка в PG.

LeXa NalBatВот дока по версии 7.4 . "Внутренние механизмы", которые обсуждались в этом топике, и раздел доки "VII. Internals" наверное коррелируют, но не совпадают. :)

Немного там описано. Впрочем, официальная дока по IB содержит еще меньше информации ;-)
...
Рейтинг: 0 / 0
17.01.2005, 16:34
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868375
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
dimitrПричем после коммита нашей транзакции старая версия остается на диске, ибо ее может читать конкурирующая snapshot-транзакция, например. И убрать эту версию как мусор можно только по завершении всех заинтересованных транзакций.
Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment. При завершении транзакции блок становится "мусорным" - id транзакции позволяет другой транзакции перезаписать этот блок, когда ей потребуется место в RB. Другие транзакции могут читать этот блок до тех пор, пока он не будет перекрыт другой транзакцией; после этого попытка прочитать старый блок приведет к ошибке "snapshot too old" (по ней также легко найти много материала).

На практике, если этот механизм отстроен адекватно требованиям, проблем не возникает. То место, где его стоит иметь в виду - очень длинные fetch-и. То есть задание типа "создали курсор - профетчили запись - долго ее обрабатываем - профетчили следующую запись - долго ее обрабатываем - и так всю ночь" имеет реальные шансы напороться на эту ошибку. Но в этом случае ее несложно обработать; в других же контекстах я ее даже не встречал. Теоретически, видимо, она должна возникать при выполнении тяжелых аналитических запросов над OLTP-базой; практически в известных мне случаях вполне удавалось выделить под RB достаточно места, чтобы проблем не возникало.

dimitrМы говорили про "чисто версионный индекс", который бы позволил index-only scan. Для этого в ключ индекса надо внести transaction ID, который бы позволил определить видимость данной записи без чтения самой записи.
Вот здесь и кроется прелесть ораклового подхода. Индекс ничего не знает про какие-то версии. Механизм блоков просто умеет вернуть версию блока, соответствующую транзакции; соответственно, транзакция получает актуальный для нее индекс практически так же, как получает актуальные для себя данные. Transaction ID же учитывается в более внутренних, нежели индекс, структурах.

Но даже если не говорить об этом - я все же не вижу, для чего перестраивать индекс. Рассматриваю самые разные варианты - и не вижу.

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

dimitrХммм. Теперь я прошу пояснить, что есть "постоянная сортировка индекса в памяти" и для чего это надо.
Полагаю, ответ уже стал ясен. Насколько я понимаю, IB работает следующим образом

- получает из индекса адреса необходимых записей
- сортирует их (упоминалась битовая карта)
- забирает записи.

Вот это, полагаю, и есть неприятный момент при оптимизации FIRST_ROWS.
...
Рейтинг: 0 / 0
17.01.2005, 16:38
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868490
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
hvladДанные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс

hvladЧто такое "версионный ключ" и "версионный индекс" мне (и IB\FB) неизвестно.
Вы уж выберите что-нибудь одно :) А то я стараюсь подладиться под Вашу терминологию - а оказывается, что Вы сами ее не знаете :)

hvlad"Сортируются" только номера записей. Строго говоря самой сортировки при этом не происходит,
Битовая карта - это стандартный алгоритм сортировки :)

hvladЦена, по сравнению с затратами на собственно сканирование индекса, - весьма невелика
Сканирование индекса - это "поточная" операция. Она не тормозит выполнение в целом; сервер может сканировать индекс и одновременно возвращать клиенту данные по уже прочитанному индексу. Здесь же требуется сначала целиком прочитать, потом отсортировать, и только потом можно возвращать записи.
...
Рейтинг: 0 / 0
17.01.2005, 17:10
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868545
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
dimitrСортируются только адреса. Цена может стать заметной на определенном (весьма немаленьком) размере битмапа.
Или на большом количестве обращений, требующих этой операции. А кэшировать результаты сортировки вряд ли удастся - они транзакционно-зависимы.

dimitrПолагаю, что IOT действительно покажет себя лучше на больших выборках. Вот только насколько велик процент задач с большим объемом данных и неуникальными выборками только по кластерному ключу?
Сложно сказать. Снова возвращаемся к уже сказанному "слишком много факторов, чтобы оценивать на пальцах".

Но я не об этом. Я не собираюсь утверждать, что IOT будут полезны IB - местным виднее. Я скорее обратил внимание на эту сортировку как на потенциальное узкое место. IOT + несортируемые индексы дают возможность управлять этим моментом, хотя, бесспорно, управление грубовато. Оправданно ли более тонкое - не знаю; тут я послушал бы специалистов покруче себя.
...
Рейтинг: 0 / 0
17.01.2005, 17:22
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868567
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
softwarerДля этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment. При завершении транзакции блок становится "мусорным" - id транзакции позволяет другой транзакции перезаписать этот блок, когда ей потребуется место в RB. Другие транзакции могут читать этот блок до тех пор, пока он не будет перекрыт другой транзакцией; после этого попытка прочитать старый блок приведет к ошибке "snapshot too old" (по ней также легко найти много материала).

В курсе, натыкался я на нее. И не могу сказать, что был рад. В IB же она в принципе не может возникнуть.

К слову - как Оракл определяет, откуда брать блок? Есть какая-то внутренняя таблица txn ID, принадлежащих RS? И еще - размер RS фиксирован админом или может динамически расширяться?

softwarerТо место, где его стоит иметь в виду - очень длинные fetch-и. То есть задание типа "создали курсор - профетчили запись - долго ее обрабатываем - профетчили следующую запись - долго ее обрабатываем - и так всю ночь" имеет реальные шансы напороться на эту ошибку.

Немаленький FOR-цикл с изменением и коммитом внутри - результат гарантирован в течении десятка минут. Для бОльшего размера RS - бОльший цикл.

softwarerВот здесь и кроется прелесть ораклового подхода. Индекс ничего не знает про какие-то версии. Механизм блоков просто умеет вернуть версию блока, соответствующую транзакции; соответственно, транзакция получает актуальный для нее индекс практически так же, как получает актуальные для себя данные. Transaction ID же учитывается в более внутренних, нежели индекс, структурах.

С удовольствием бы почитал на эту тему.

softwarerСкладывается впечатление, что это требование проистекает из желания при изменении записи вставить в индекс новую строку со ссылкой на старую версию записи. Стоит от этого отказаться - и проблем не остается.

В текущем варианте хранения и обработки версий от этого отказаться не удастся.

softwarerНасколько я понимаю, IB работает следующим образом

- получает из индекса адреса необходимых записей
- сортирует их (упоминалась битовая карта)
- забирает записи.

Вот это, полагаю, и есть неприятный момент при оптимизации FIRST_ROWS.

Для выборки в миллионы записей - так точно. В остальных случаях это незаметно.
...
Рейтинг: 0 / 0
17.01.2005, 17:30
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868580
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
softwarerВы уж выберите что-нибудь одно :) А то я стараюсь подладиться под Вашу терминологию - а оказывается, что Вы сами ее не знаете :)Нет такой терминологии, её в этом обсуждении придумали и тут же показали её минусы

softwarer hvlad"Сортируются" только номера записей. Строго говоря самой сортировки при этом не происходит, Битовая карта - это стандартный алгоритм сортировки :)Ну, если так, то - да, есть сортировка ;)

softwarer hvladЦена, по сравнению с затратами на собственно сканирование индекса, - весьма невеликаСканирование индекса - это "поточная" операция. Она не тормозит выполнение в целом; сервер может сканировать индекс и одновременно возвращать клиенту данные по уже прочитанному индексу.Здесь - да, FB не умеет выдавать записи по ходу сканирования индекса, т.е. FIRST_ROWS оптимизации в нём нет

softwarerЗдесь же требуется сначала целиком прочитать, потом отсортировать, и только потом можно возвращать записи.Строго говоря, всё не совсем так. Сначала читается индекс и по-ходу сортируются полученные номера записей (сортировка здесь очень дешёвая операция), затем записи посещаются и выдаются клиенту. Но не все, а по мере фетча.

Думаю, с этим вопросом уже все разобрались :)
...
Рейтинг: 0 / 0
17.01.2005, 17:35
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868584
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
softwarerВы уж выберите что-нибудь одно :) А то я стараюсь подладиться под Вашу терминологию - а оказывается, что Вы сами ее не знаете :)

Просто мы говорим о том, чего в IB нет, но типа могло бы быть ;-)

softwarerСканирование индекса - это "поточная" операция. Она не тормозит выполнение в целом; сервер может сканировать индекс и одновременно возвращать клиенту данные по уже прочитанному индексу. Здесь же требуется сначала целиком прочитать, потом отсортировать, и только потом можно возвращать записи.

Согласен. Чисто теоретически можно не сортировать битмап при хинте FIRST_ROWS, а выдавать адреса записей конвейерно. Вот только нету хинтов в IB ;-)
...
Рейтинг: 0 / 0
17.01.2005, 17:36
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868680
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
dimitrК слову - как Оракл определяет, откуда брать блок? Есть какая-то внутренняя таблица txn ID, принадлежащих RS?
Чтобы ответить в деталях - надо искать. Полагаю, оптимальным будет спросить на форуме Оракла - там есть несколько человек, которые постоянно копаются на этом уровне.

dimitrИ еще - размер RS фиксирован админом или может динамически расширяться?
Может. Правда, насколько я в курсе, серьезные админы предпочитают работать руками.

Другой момент - начиная с Oracle9, появился некий Automatic Undo Management. Из интересных Вам фич - в этом случае есть возможность зафиксировать время, в течение которого блок не будет повторно использован. Также в этом случае идет полностью динамическое распределение места - в чем, правда, я вижу возможность минусов. В старом варианте я мог выделить транзакции rollback segment и быть уверен, что она отработает до конца; здесь же технически существует возможность проблем в моей супертяжелой транзакции из-за суммарной нагрузки текущих транзакций. Причем написать задание так, чтобы оно "переживало" такую проблему, будет не очень легко.

dimitrНемаленький FOR-цикл с изменением и коммитом внутри - результат гарантирован в течении десятка минут.
Если изменяются те же данные, что и фетчатся - да. Но согласитесь, это сверхидиотский режим. Очевидно более правильный вариант - запросил порцию данных - изменил - закоммитил - запросил следующую порцию. Хуже другой вариант - сам ты данные только фетчишь (а меняешь, если меняешь, другие), но кто-то успел проапдейтить запись, попадающую в выборку. Но это актуально только в очень длинных операциях - и при этом тривиально обрабатывается.

В общем - это безусловно вещь, которую нужно знать. Но заметных проблем она не доставляет.

dimitrС удовольствием бы почитал на эту тему.
На уровне технической реализации - увы, не ко мне. Ключевой момент - именно версионность блоков. Полагаю, прелесть этого понятна - любые, сколь угодно сложные механизмы автоматом учитывают версионность; не надо думать, например, о расщеплении branch-узлов итп. Каждая сессия работает в своем виртуальном пространстве блоков.
...
Рейтинг: 0 / 0
17.01.2005, 18:08
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868726
tru55
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tru55
Участник
2 softwarer
Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment

Вот здесь как раз не rollback, а UNDO
...
Рейтинг: 0 / 0
17.01.2005, 18:28
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868751
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
tru55
Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment

Вот здесь как раз не rollback, а UNDO
В первую очередь, UNDO появляется только если выставить Automatic Undo Management, чего делать необязательно. Во-вторых же, UNDO Tablespace - это те же самые rollback segment-ы (их можно увидеть в системных вьюхах); просто их менеджментом (создание и прочее) занимается сервер.
...
Рейтинг: 0 / 0
17.01.2005, 18:42
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868755
tru55
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tru55
Участник

Другой момент - начиная с Oracle9, появился некий Automatic Undo Management. Из интересных Вам фич - в этом случае есть возможность зафиксировать время, в течение которого блок не будет повторно использован. Также в этом случае идет полностью динамическое распределение места - в чем, правда, я вижу возможность минусов. В старом варианте я мог выделить транзакции rollback segment и быть уверен, что она отработает до конца; здесь же технически существует возможность проблем в моей супертяжелой транзакции из-за суммарной нагрузки текущих транзакций. Причем написать задание так, чтобы оно "переживало" такую проблему, будет не очень легко.

А

SET TRANSACTION USE ROLLBACK SEGMENT

никто не отменял, вне зависимости от UNDO_MANAGEMENT

К слову сказать, UNDO_RETENTION ("зафиксировать время") - это рекомендация, а не абсолют
...
Рейтинг: 0 / 0
17.01.2005, 18:45
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868764
tru55
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tru55
Участник
softwarer tru55
Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment

Вот здесь как раз не rollback, а UNDO
В первую очередь, UNDO появляется только если выставить Automatic Undo Management, чего делать необязательно. Во-вторых же, UNDO Tablespace - это те же самые rollback segment-ы (их можно увидеть в системных вьюхах); просто их менеджментом (создание и прочее) занимается сервер.

Сорру, поспешил. Вопрос терминологии, просто в 9i используется термин "UNDO" вместо "ROLLBACK", причем вне зависимости от UNDO_MANAGEMENT, просто как понятие
...
Рейтинг: 0 / 0
17.01.2005, 18:50
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868813
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
tru55SET TRANSACTION USE ROLLBACK SEGMENT
никто не отменял, вне зависимости от UNDO_MANAGEMENT
Вы в этом уверены? ;-)

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
SQL> select * from v$rollname;

USN NAME
--- ------------------------------
   0  SYSTEM
   1  _SYSSMU1$
   2  _SYSSMU2$
   3  _SYSSMU3$
   4  _SYSSMU4$
   5  _SYSSMU5$
   6  _SYSSMU6$
   7  _SYSSMU7$
   8  _SYSSMU8$
   9  _SYSSMU9$
  10  _SYSSMU10$

 11  rows selected

set transaction use rollback segment "_SYSMU10$"

ORA- 30019 : Illegal rollback Segment operation in Automatic Undo mode

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

tru55К слову сказать, UNDO_RETENTION ("зафиксировать время") - это рекомендация, а не абсолют
Я не пытался "изнасиловать" этот параметр. Дока, однако, утверждает следующее:

Undo Retention Control

Long-running queries sometimes fail because undo information required for consistent read operations is no longer available. This happens when committed undo blocks are overwritten by active transactions.

Automatic undo management provides a way to explicitly control when undo space can be reused; that is, how long undo information is retained. A database administrator can specify a retention period by using the parameter UNDO_RETENTION. For example, if UNDO_RETENTION is set to 30 minutes, then all committed undo information in the system is retained for at least 30 minutes. This ensures that all queries running for 30 minutes or less, under usual circumstances, do not encounter the OER error, "snapshot too old."
...
Рейтинг: 0 / 0
17.01.2005, 19:25
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868816
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
softwarerКлючевой момент - именно версионность блоков. Полагаю, прелесть этого понятна - любые, сколь угодно сложные механизмы автоматом учитывают версионность; не надо думать, например, о расщеплении branch-узлов итп. Каждая сессия работает в своем виртуальном пространстве блоков.

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

Во-вторых, интересен сам механизм. При апдейте двух соседних записей разными транзакциями в RS будет две копии блока? Если да, то не слишком ли эта прелесть накладна с точки зрения ресурсов и объема I/O?
...
Рейтинг: 0 / 0
17.01.2005, 19:29
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32868844
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
dimitrВо-первых, смею предположить, что это работает не для всех блоков. Тем же сиквенсам версионность крайне вредна, например. Впрочем, хранятся ли их значения в своих собственных блоках или в системной таблице с инкрементом через блокировку, я не в курсе.
Правильнее сказать, тем же сиквенсам версионность пофиг. Сиквенсы генерятся через промежуточный серверный механизм, соответственно, изменение этих блоков идет не в пользовательской транзакции, а в своей собственной. Заодно этот механизм поддерживает "кэш сиквенсов" - крайне полезная для скорости штука.

В то же время я сейчас убедился в версионности блоков секвенсоров на следующем простом примере:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
-- Сессия 1 --
create sequence isolated;
set transaction isolation level serializable;
select last_number from dba_sequences where sequence_name = 'ISOLATED';

-- Сессия 2 --
select isolated.nextval from dba_objects where rownum <=  10 

-- Сессия 1 --
select last_number from dba_sequences where sequence_name = 'ISOLATED';
commit;
select last_number from dba_sequences where sequence_name = 'ISOLATED';

dimitrВо-вторых, интересен сам механизм. При апдейте двух соседних записей разными транзакциями в RS будет две копии блока? Если да, то не слишком ли эта прелесть накладна с точки зрения ресурсов и объема I/O?
Насколько я помню, в RBS хранится undo информация транзакции. К сожалению, эти вопросы не входят в круг моих "повседневных" знаний, поэтому не буду утверждать категорично.
...
Рейтинг: 0 / 0
17.01.2005, 20:04
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32869880
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
dimitr Во-вторых, интересен сам механизм. При апдейте двух соседних записей разными транзакциями в RS будет две копии блока? Если да, то не слишком ли эта прелесть накладна с точки зрения ресурсов и объема I/O?

Да две версии. Легко проверить, если создать очень маленький RBS и запустить несколько сессий, изменяющих записи, то экстенты в RBS кончаться намного раньше, чем в случае одной сесси. Я прверял на восьмёрке. На более поздних версиях не пробовал, но не думаю, что там что-то изменилось.
С другой стороны, если проводить просто вставку, а не изменение записей, то Оракул тоже что-то пишет в RBS. Неужели пустые блоки? Что он собирается откатывать?




Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
18.01.2005, 12:58
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32869989
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
protector
С другой стороны, если проводить просто вставку, а не изменение записей, то Оракул тоже что-то пишет в RBS. Неужели пустые блоки? Что он собирается откатывать?
Откатывать придется "занятое место" в этих блоках - заново пометить его как свободное.
...
Рейтинг: 0 / 0
18.01.2005, 13:24
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32887945
RedALIEN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RedALIEN
Гость
Если для автора топика еще актуален вопрос об GUI-инструментах для PG, могу посоветовать взглянуть сюда: http://www.sqlmanager.net. Есть версии для win и linux, последняя послабее будет. Но этот софт стоит денег после 30 дней :)
...
Рейтинг: 0 / 0
27.01.2005, 18:49
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32895299
Фотография mef
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mef
Участник
актуален, конечно!
Спасибо за ссылку...
...
Рейтинг: 0 / 0
01.02.2005, 17:12
| Ответить | Цитировать | Написать  
FireBird 1.5.2 vs PostgreSQL 7.4
    #32897184
Фотография mef
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mef
Участник
посмотрел - мне нужно было под линукс, так там какая-то допотопная версия (8.0 уж точно не поддерживает). В принципе у аквы похожая функциональнось, хотя здесь понравилось автодополнение кода при написании SQL.
...
Рейтинг: 0 / 0
02.02.2005, 14:34
| Ответить | Цитировать | Написать  
113 сообщений из 113, показаны все 5 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / FireBird 1.5.2 vs PostgreSQL 7.4
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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