Вы конечно, меня извините,

[metaclass]

но PostgreSQL с первого взгляда выглядит более правильной СУБД чем Firebird.

1) Логи, много понятных логов. Небо и земля, по сравнению с ничего не значащим бредом, которым firebird.log заполнен чуть более чем полностью. Т.е. там даже нет возможности включить что нибудь вроде "протоколирование доступа к базе", не говоря уже о запросах, итд.

2) Читабельный вывод консольных утилит. Posix-командная строка этих самых утилит. Вменяемые параметры их же.

3) Несколько вариантов аутентификации, управление аутентификацией c детализацией по адресам-маскам, именам базы, юзеров

4) доступ через ssl.

5) И наконец, ключевой аспект: документация. 2100 страниц нормальной понятной хорошо структурированной документации, доступной в виде PDF с официального сайта. В отличие от, блядь, документации по Interbase 6 на которую до сих пор ссылаются на сайте FB и потока сознания разработчиков в виде quick start quide и release notes.

Comments

[theiced.livejournal.com]

такс - а вот на что стоит обратить пристальное внимание:

1. при смене мажора придётся делать дамп/рестор. увы.
2. твикинг перфоманса под конкретный случай - довольно нетривиальная задача. с ним лучше идти на #postgres@freenode
3. _иногда_ оптимизатору запросов евойному сносит напрочь крышу (ну я стабильно раз в год натыкаюсь на случай когда вполне себе приличный запрос работает на порядки медленее чем должен, непонятно почему).

[alexott.livejournal.com]

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

[metaclass.livejournal.com]

Оптимизатор это фетишистская тема, оно везде плющится.

[theiced.livejournal.com]

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

[denisioru.livejournal.com]

Кстати, а в IB/FB можно посмотреть планы запросов оптимизатора? А то не припомню, давно уже не использую его.

[metaclass.livejournal.com]

Вообще API возвращает после prepare.
Если в консольной утилите isql - то что-то вроде SET PLAN ON или SET PLANONLY ON

[norguhtar.livejournal.com]

2. твикинг перфоманса под конкретный случай - довольно нетривиальная задача. с ним лучше идти на #postgres@freenode

Ручек маловато будет. Но основная проблема у нас не поместились необходимые индексы в память.

[a-sure.livejournal.com]

3. а кто не? Вчера СВО решил, что nested loop это негламурно, и решил, что cartesian join over TEMP будет крчЕе. Ага, запрос отожрал 80Гиг темпа, темп кончился.
Металинк сказал - "ага, знаем-знаем! в 9.2.0.5 патчили (я помню), потом в 9.2.0.6, но в 10.2.0.3 еще раз надо патчить. Ну, есть еще _параметр=врешь"...

Оно обычно либо до бениной мамы всяких ручек(ОРАКЛ), либо "коробка-автомат". промежуточные варианты почему-то не приживаются.

Девелоперы тоже отжигают - запросы в аксапте "сочинялись" из кусков. Вариантов хинтов было аж два - либо first row, либо all rows. Устанавливалось глобально.