I eto horosho.
PostgreSQL 4eva.

Long Live Postgresql!
Пусть конкуренция будет вечной!

а где подробный список фиксов посмотреть можно? и где взять пакеты для rh7 :)?

srpm-s voz'mi. na moj rh7.1 postavilsja bez osobyh problem. tol'ko autoconf > 2.53 hotel..

Вечный глюк и тормоз.

gw128 угу, я так и сделал в конечном итоге)

> Вечный глюк и тормоз.

Ну ты еще аватару к подписи забыл.

а что, позвольте спросить, не "Вечный глюк и тормоз" ? варианты, с комментариями и цена/производительность", в студию

ой, шаз начнется... или стерпят

"Вечный глюк и тормоз" это IBM DB2.

Николай Куликов.

Точно. Вечный глюк и тормоз. Не используй его. Используй свой XXXsql. Он безусловно лучше, надежнее и быстрее. А на нас не обращай внимания, мы тупые, нам религия не позволяет использовать другие СУБД.

Все SQL-серверы хороши, каждый для своей задачи и своих условий. Мне PostgreSQL очень нравится. Этакий маленький бесплатный Oracle :)

Интересно, а базу данных нашего предприятия он потянет? Таблиц около 2500, но 95% маленькие, всё вместе весит около 500М. Клиентов около сотни. Много качают около 10, остальные эпизодически. Хотелось бы отрабатывать связи и вести историю (кто чего изменил), ну и надёжность уровня 9999 (железо хорошее есть)....

Oracle не предлагать, он есть (старенький 7.3).... Просто хочется недорого и красиво.

P.S. Так достал этот фокспро досовый, всех на линукс пересажу ;)

Должен потянуть.. Вроде в ваших описаниях нет ничего страшного для postgresql.

Канэшно потянет!

Должен потянуть

Для примера, у нас PostgreSQL 7.0.3 версии, база 7Gb в 25 таблицах, довольно сложные и связи и выборки. Железо - обычный PC от Compaq, K7 - 550Mhz/500Mb, uptime - 295 дней. Я даже подходить к нему боюсь -  пока работает.

>>база 7Gb в 25 таблицах
ну и что за база?? OLTP??? сколько активных паралельных коннектов??

Сложные запросы это какие?? пример дать можешь??

Разумееться все это не наезд..так, сбор информации вдобавок к своей..

Мне тоже постгрес в последнее время немного нравистя стал.. кой ккие вещи просты, но ой как много еще не хватает %(.. Да и скорость ... особенно вьюверов..

так что он кнечно не маленький оракл, скорее крошечный, но всеже....

База работает на пользу науки.
Главные требование были: стабильность (данные собираются с удалённых машин постоянно), дешевизна, и наличие мех-ма поддержки целостности данных.
Запросы к базе:
1) простые вставки (но постоянно)
2) выборки типа такой, (самая типичная, есть много проще)
("select distinct on (G.id_event) G.id_event,S.time, E.description
from groups G, sdata S, events E
where ((G.id_data = S.id_data) and (E.id_event = G.id_event)))
INTERSECT
(select G.id_event, S.time, E.description
from groups G, sdata S, events E
where ((G.id_data = S.id_data) and (E.id_event = G.id_event))
group by S.time,G.id_event,E.description)
order by G.id_event DESC,S.time ASC");

Запросы, кстати пишут совсем не SQl программеры

или вот ещё часто используемая view

SELECT s.name, avg(d.time_error) AS avg, max(d.time_error) AS max, min(d.time_error) AS min, "interval"(text((max(d."time") - min(d."time")))) AS "interval" FROM debug_inf d, stations s WHERE (s.id_station = d.id_station) GROUP BY s.name;

> 1) простые вставки (но постоянно)
> 2) выборки типа такой, (самая типичная, есть много проще)
("select distinct on (G.id_event)

Нечего мудрить. Это самая типичная работа, на которую рассчитан mysql. Лучше не придумаешь.

2last anonymoys
когда база создавалась в mysql даже foreign keys не было...

а кто? что скажет про существенные глюки объекта обсуждения. желательно на фактах, без пальцев т.с.

Добрый день

В смысле, что глюков не замечено :)

С уважением Евгений

P.S. PostgreSQL три года (база данных калибровок детектора КЕДР, ускорительный комплекс ВЭПП-4М), около 300 таблиц, вставки до раз в пять минут, число записей до нескольких десятков тысяч в таблице, размер базы около полутора гигобайт, бэкап каждый день, работает на Pentium II 300 Mhz (все три года). Основные проблемы были связаны с неправильной организацией самой БД - то есть "кривизна рук". Глюков БД не отмечено. Пишется не только с писишки, но и с VAX/VMS. Использование БД позволило уменьшить систематику в измерении массы J/Psi примерно на 20%, да и вообще просто оценить её.

Глюк или может непонимание - не смог заставить его (в 7.3.2) делать левый джойн сортировкой и слиянием. Все норовит перебор устроить - зараза.

Ну науки или торговли наркотиками это не важно..

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

По поводу MySQL.. Ребята, не начинайте флейм, всему сове место, не тащите MySQL в те ниши, где ему делать нечего. Гл себя в Вебе замечательно чувствует.

то что активно начал использовать это вставнка порциями по 10 блоков, в каждом 7 инсертов по условию (через функции) в 7 таблиц, после чего делается коммит.. Размер базы около базы около 600М.. 7 таблиц, из них одна большая, повязаная ключами на маленькие..
так вот, скорость такой операции приблизительно 16 блоков в минуту на Сel500/128M. Мягко говоря, я ожидал лучше...

Есть правда другие моменты,
1) тюнинг никто не делал, тоесть после стандартной сборки (7.3.2).
2) распаралеливание запросов весьма сносно, тоесть при полностью загруженой базе я в разумном реалтайме делал достаточно сложные селекты (гораздо сложнее тех что приведены)
3) Ничто не умерло и не упало..

вобщем есть еще куда работать, как мне, так и создателям постгреса..

ну и кончено о наболевшем %)) (во всем свои минусы)
1) ужасная работа с датами.
2) не самый удобный синтаксис.
3) отсутвие (пока) многих удобных фич.

>>паралельных запросов коннектов.
сорри, просто коннектов разумееться..

Народ, а можно где нибудь нарыть тесты его производительности по отношению к FireBird???

Добрый день Может оказаться, что так и надо. Посмотри explain, посмотри как тоже делается под другими БД. При всей своей тривиальность SQL может выкидывать самые разные коленца.

С уважением Евгений

я знаю точно что нельзя поручать mysql -- stream of inserts starves select (insert delayed не спасает). Как это нормально сказать по-русски я не знаю :) Хотелось бы знать что у постгреса нет такого косяка. Всё что я пока о нём знаю -- он весьма нетороплив. Требуемый уровень -- порядка 100+ инсертов/сек (это минимум). Приведённые тут примеры селектов сложными назвать нельзя :) Щас покажу свой.

select count(*), return_time_group(max_time - prev_time) from (select cs.cookie, max(show_time) as prev_time, max(max_time) as max_time from count_show cs, (select cookie, max(show_time) as max_time from count_show where show_time < $some_next_date and id_client_site = ? and cookie is not null group by cookie) m1 where show_time < m1.max_time and cs.cookie = m1.cookie and id_client_site = ? group by cs.cookie) group by return_time_group(max_time - prev_time)

попробуйте такое на посгресе...

Должен потянуть - я гонял postgresql на базах объемом до 20 гигов, таблиц в районе 200, но некоторые большие - несколько миллионов записей. Ну и связи между ними

> Интересно, а базу данных нашего предприятия он потянет? Таблиц около 2500,

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

> ну и кончено о наболевшем %)) (во всем свои минусы) > 1) ужасная работа с датами.

с датами он не так уж и плохо - разве что на каждом шагу требует конверсию типов, да и компатабилита дат (в текстовом формате) со старшими версиями совсем никуда не годится. %(

ifconfig (*) (2003-05-29 09:28:47.119):

> 1) тюнинг никто не делал, тоесть после стандартной сборки (7.3.2).

ну так сделайте:

1) Размер кэша в четверть памяти (32 Мб сталбыть)

2) Разнести (если можно) базы и pg_xlog на разные физические диски --- в вашем случае должно сильно помочь

3) Не забывайте vacuum analyze время от времени.

Casus, можно уже давно это поручать MySQL, InnoDB версионник, и с stream of inserts starves select там не бывает

Casus (*) (2003-05-29 11:11:33.36):

> Всё что я пока о нём знаю -- он весьма нетороплив. Требуемый уровень -- порядка 100+ инсертов/сек (это минимум).

Пихай все 100+ инсертов в одну транзакцию, на ура пройдут.

> select count(*), return_time_group(max_time - prev_time) from (select cs.cookie, max(show_time) as prev_time, max(max_time) as max_time from count_show cs, (select cookie, max(show_time) as max_time from count_show where show_time < $some_next_date and id_client_site = ? and cookie is not null group by cookie) m1 where show_time < m1.max_time and cs.cookie = m1.cookie and id_client_site = ? group by cs.cookie) group by return_time_group(max_time - prev_time)

> попробуйте такое на посгресе...

надо понимать, из MySQL запрос? :D

на самом деле, при грамотно построенных по count_show индексах тормозить не должно, сам по себе запрос не слишком страшный

А вот разведка доносит, что по последним данным ДБ2 удерживает свои позиции (причем за счет мэйнфреймов :) ) и рулит, Оракл сильно упал и уже слегка подсасывает у ИБМ, а все остальное сосет у них обоих со страшной силой. =)

http://www.esj.com/News/article.asp?EditorialsID=567

Вова :)

Я никак не найду на их сайте Changes. Уже в который раз. Кстати, упоминавшиеся здесь патчи для работы с древовидными структурами вошли?

2 beldmit. Net, drevovidnye struktury ne voshli i vrjatli vojdut :(

A changelog tuta:

                              Release Notes

                               Release 7.3.3

     Release date: 2003-05-22

   This has a variety of fixes from 7.3.2.
     _________________________________________________________________

                         Migration to version 7.3.3

   A dump/restore is *not* required for those running 7.3.*.
     _________________________________________________________________

                                  Changes

   Repair sometimes-incorrect computation of StartUpID after a crash
   Avoid slowness with lots of deferred triggers in one transaction (Stephan)
   Don't lock referenced row when UPDATE doesn't change foreign key's value
        (Jan)
   Use -fPIC not -fpic on Sparc (Tom Callaway)
   Repair lack of schema-awareness in contrib/reindexdb
   Fix contrib/intarray error for zero-element result array (Teodor)
   Ensure createuser script will exit on control-C (Oliver)
   Fix errors when the type of a dropped column has itself been dropped
   CHECKPOINT does not cause database panic on failure in noncritical steps
   Accept 60 in seconds fields of timestamp, time, interval input values
   Issue notice, not error, if TIMESTAMP, TIME, or INTERVAL precision too
        large
   Fix abstime-to-time cast function (fix is not applied unless you initdb)
   Fix pg_proc entry for timestamptz_izone (fix is not applied unless you
        initdb)
   Make EXTRACT(EPOCH FROM timestamp without time zone) treat input as
        local time
   'now'::timestamptz gave wrong answer if timezone changed earlier in
        transaction
   HAVE_INT64_TIMESTAMP code for time with timezone overwrote its input
   Accept GLOBAL TEMP/TEMPORARY as a synonym for TEMPORARY
   Avoid improper schema-permissions-check failure in foreign-key triggers
   Fix bugs in foreign-key triggers for SET DEFAULT action
   Fix incorrect time-qual check in row fetch for UPDATE and DELETE triggers
   Foreign-key clauses were parsed but ignored in ALTER TABLE ADD COLUMN
   Fix createlang script breakage for case where handler function already
        exists
   Fix misbehavior on zero-column tables in pg_dump, COPY, ANALYZE, other
        places
   Fix misbehavior of func_error() on type names containing '%'
   Fix misbehavior of replace() on strings containing '%'
   Regular-expression patterns containing certain multibyte characters failed
   Account correctly for NULLs in more cases in join size estimation
   Avoid conflict with system definition of isblank() function or macro
   Fix failure to convert large code point values in EUC_TW conversions
        (Tatsuo)
   Fix error recovery for SSL_read/SSL_write calls
   Don't do early constant-folding of type coercion expressions
   Validate page header fields immediately after reading in any page
   Repair incorrect check for ungrouped variables in unnamed joins
   Fix buffer overrun in to_ascii (Guido Notari)
   contrib/ltree fixes (Teodor)
   Fix core dump in deadlock detection on machines where char is unsigned
   Avoid running out of buffers in many-way indexscan (bug introduced in 7.3)
   Fix planner's selectivity estimation functions to handle domains properly
   Fix dbmirror memory-allocation bug (Steven Singer)
   Prevent infinite loop in ln(numeric) due to roundoff error.
   GROUP BY got confused if there were multiple equal GROUP BY items
   Fix bad plan when inherited UPDATE/DELETE references another inherited
        table
   Prevent clustering on incomplete (partial or non-NULL-storing) indexes
   Service shutdown request at proper time if it arrives while still
        starting up
   Fix left-links in temporary indexes (could make backwards scans miss
        entries)
   Fix incorrect handling of client_encoding setting in postgresql.conf
        (Tatsuo)
   Fix failure to respond to 'pg_ctl stop -m fast' after Async_NotifyHandler
        runs
   Fix SPI for case where rule contains multiple statements of the same type
   Fix problem with checking for wrong type of access permission in rule query
   Fix problem with EXCEPT in CREATE RULE
   Prevent problem with dropping temp tables having serial columns
   Fix replace_vars_with_subplan_refs failure in complex views
   Fix regexp slowness in multibyte encodings (Tatsuo)
   Allow qualified type names in CREATE CAST and DROP CAST
   Accept 'SETOF type[]', which formerly had to be written 'SETOF _type'
   Fix pg_dump core dump in some cases with procedural languages
   Force ISO datestyle in pg_dump output, for portability (Oliver)
   pg_dump failed to handle error return from lo_read (Oleg Drokin)
   pg_dumpall failed with groups having no members (Nick Eskelinen)
   pg_dumpall failed to recognize --globals-only switch
   pg_restore failed to restore blobs if -X disable-triggers is specified
   Repair intrafunction memory leak in plpgsql
   pltcl's elog command dumped core if given wrong parameters (Ian Harding)
   plpython used wrong value of atttypmod (Brad McLean)
   Fix improper quoting of boolean values in Python interface (D'Arcy)
   Added addDataType() method to PGConnection interface for JDBC
   Fixed various problems with updateable ResultSets for JDBC (Shawn Green)
   Fixed various problems with DatabaseMetaData for JDBC (Kris Jurka,
        Peter Royal)
   Fixed problem with parsing table ACLs in JDBC
   Better error message for character set conversion problems in JDBC
     _________________________________________________________________

> Пихай все 100+ инсертов в одну транзакцию, на ура пройдут.

не могу. это 100 разных клиентов. и каждый из этих клиентов ещё и select count(*) делает тут же, чтобы узнать сколько уже посетителей было.

> надо понимать, из MySQL запрос? :D

:) Нет, mysql был очень быстро заменён на oracle после обнаружения проблемы с потоком инсертов... :) запрос, понятно, был переделан под оракла.

> на самом деле, при грамотно построенных по count_show индексах тормозить не должно, сам по себе запрос не слишком страшный

Ну... он-то не страшный, просто нужно чтобы был хороший оптимизатор запросов/подзапросов. Запрос кстати был написан наспор, что я смогу уложить задачу в один запрос :)

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

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

По поводу сложности запросов я вас сейчас немного посмешу. Видел я много и такого:

select D.Queue_ID Queue,coalesce(SumO,0)-coalesce(SumI,0) Count ,Oldest from qv_queue_control D left join (select C.QUEUE_ID,sum(integer(C.total_itms)) SumO, min(timestamp(EARLIEST_RECORD_TS)) Oldest from sv_task_run_time A join sv_tsk_bat_run_tme B on B.RUN_ID=A.RUN_ID join sv_batch_ctl C on C.BATCH_ID=B.BATCH_ID where A.BUSINESS_DTE> ( select date_1(coalesce((max(date(REPORT_DTE)) ),date('1900-01-01'))) from qv_dly_q_cnt ) and c.Batch_typ=indic('O') group by C.QUEUE_ID) A on D.Queue_ID=A.queue_id left join (select C.QUEUE_ID,sum(integer(C.total_itms)) SumI from sv_task_run_time A "+ join sv_tsk_bat_run_tme B on B.RUN_ID=A.RUN_ID join sv_batch_ctl C on C.BATCH_ID=B.BATCH_ID where A.BUSINESS_DTE> ( select date_1(coalesce((max(date(REPORT_DTE))), date('1900-01-01'))) from qv_dly_q_cnt ) and c.Batch_typ=indic('I') group by C.QUEUE_ID) B on D.Queue_ID=b.queue_id where smallint(D.Queue_ID) between 1999 and 2999 or smallint(D.Queue_ID) between 9200 and 9299 order by D.Queue_ID

Угадайте, что за база ;-)

IMHO MSSQL

Petr

>не могу. это 100 разных клиентов. и каждый из этих клиентов ещё и select count(*) делает тут же, чтобы узнать сколько уже посетителей было.

Это значит - таблица локается вся на write. (IMHO) Политика - как и что локать (на чём стоит lock): где-то в пропертях базы должна устанавливаться. Часто для 'safety' (Oracle если мне память не изменяет) по умолчанию ставится TRANSACTION SERIALIZABLE (isolation level 3), то есть это для любой задачм safe но только один процесс может работать с данной таблицей в любой момент времени (читатели ждут..).

В твоём случае данние которые показываются не критичны и на них не делается другой трансакции, т.е. они не должны быть глобально синхронизированы. То есть можно снизить isolation level и разрешить писакам писать (insert into A), а читателям - читать (select from A) одновременно (из таблицы, индивидуальные записи в любом случае будут локнуты).

Не знаю как это (сколько уровней и как поменять) реализовано в postgress.

добавлю, что сказанное выше (transaction isolation shift to lower) , будет работать только если не используется внешнего к базе transaction monitor'а: внешняя аппликация содержащая бизнес-логику может иметь свои локи.

"join (select ..." итд не поддерживается MySQL

> А вот разведка доносит, что по последним данным ДБ2 удерживает свои
> позиции (причем за счет мэйнфреймов :) ) и рулит, Оракл сильно упал и
> уже слегка подсасывает у ИБМ, а все остальное сосет у них обоих со
> страшной силой. =)
Ух, какой сосучий лексикон!

На DB2 у меня уже эпитетов не осталось. Постоянно находятся мелкие недоработоки, шероховатости. Времена, когда я так же интенсивно не любил Oracle, теперь вспоминаются как добрая сказка.

а что народ слышал про Линтер

Про оптимизацию left join (2003-05-29 07:37:56.744)

Да посмотрел. И vacuum full analize и explain. На глаз видно, в двух таблицах по 6000 записей а он их по левому джойну перебирает :(. Вот если join не левый = тогда правильно работает. Когда их вообще не было заменяли объединением и вычитанием (так работает быстрее сейчас)

Опять же не использует индексы многоэлементные при внешнем join.

У меня работает связка JBOSS 3.0.3 + PostgreSQL 7.3.2 База, пока, состоит из 17 таблиц (по проекту 74) Все пока в стадии альфы, но работа этой связки радует и поражает надежностью. Уж как только я не измывался над ними своими кривыми руками. :))) Про JBOSS не буду говорить, это отдельная тема. :))

Ни в коей мере не счетаю себя экспертом. Изучаю PostgreSQL по мере появления некой проблемы, но свое субьективное мнение выскажу.

Что в PostgreSQL нравится:
- огромный набор типов данных (просто чума);
- куча опцыональных фич, которые можно откомпилировать и прикрутить;
- возможность использовать для обработки данных "любимый" язык программирования (я даже на паскале что-то прикручивал);
- вполне приличная скорость работы, если с головой подходить к построению реляционной базы, индексов, тригеров;
- соотношения цена/производительность цена/надежность цена/наличие требуемых фич очень хорошее;
- офигенный тип данных массив. Очень удобно хранить историю именений полей, например;
- очень удобен механизм автоматического построения тригеров при всязке таблиц реляциями. Избавляет разработчика от множества ошибок;
- очень удобно работать с автоинкрементными полями;
Что меня особенно привело в восторг, это возможность использования рекурсии во встроенных функциях, хотя их синтаксис и не очень удобен.

Из недостатков:
- как ifconfig отметил, ужасно неудобно работать с датами. Связка PostgreSQL + JAVA при работе с датами просто задница!!! Задрали бесконечные пребразования из обного типа в другой. Да и где-то попути периодически что-то сглюкивает. Постоянно меня пинают - "Ну не мог я закрыть задание в три часа ночи. Спал уже тогда". А мен сказать не чего. Не найти где глючит. Причем глючит периодически, и зависит от расположения звезд, или от того, пукнет бабка в соседнем доме, или нет. Вобщем, с датами (или с руками) жопа;
- потом, была замечена такая хрень, что при создании таблицы зачастую постгрес сам решает какие типы данных использовать. Может это руки, но рестор после дампа, зачастую, дает другой результат по сравнению с тем,что было раньше. Искать такие ошибки очень трудно. Один раз я остался без первичного ключа. Второй раз он CHAR махнул на VARCHAR и у меня отлаженные части программы просто перестали работать. Повторяю, может быть это проблема в моих руках, но пока я не нашел, где лажуюсь;
- потом, не нашел, как восстановить, ну например, дропнутую таблицу. Иногда руки быстрее головы работаут, что создает проблемы :))) Надеюсь, такая продлемма есть у многих, если не у всех.
- нет приличного механизма работы с XML документами. То что есть в опциональных приблудах не катит вааще. Можно только на "попробовать" использовать. Поиск по XML документу страшно медленный. Да и как иначе? Там сначала строится DOM, а потом по "домам" и поиск запускается... А если у меня документов тысячи???? Сейчас этот тип данных, и работа с ними становится все больше и больше актуальной.

А ели подвести черту под моей пургой, то PostgreSQL это действительно маленький оракл. У него даже встроенный процедурный язык как родной брат оракла.

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

2Casus (*) (2003-05-29 11:11:33.360756)

>select count(*), return_time_group(max_time - prev_time) from (select

И чего тут такого возбуждающего? :))

Вот таких запросов у меня море:

SELECT pk_orders WHERE NOT deleted AND NOT project AND fk_actoy_contractor=1 AND materials_complite is NOT null AND (((NOT is_offset) AND (NOT is_silk) AND is_postprint AND (postprint is NOT null) AND (postprint_real is NOT null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR ((NOT is_offset) AND is_silk AND (NOT is_postprint) AND (print_silk is NOT null) AND (print_silk_real is NOT null) AND (postprint is null) AND (postprint_real is null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR ((NOT is_offset) AND is_silk AND is_postprint AND (print_silk is NOT null) AND (print_silk_real is NOT null) AND (postprint is null) AND (postprint_real is null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR ((NOT is_offset) AND is_silk AND is_postprint AND (print_silk is NOT null) AND (print_silk_real is NOT null) AND (postprint is NOT null) AND (postprint_real is NOT null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR (is_offset AND (NOT is_silk) AND (NOT is_postprint) AND (print_offset is NOT null) AND (print_offset_real is NOT null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR (is_offset AND (NOT is_silk) AND is_postprint AND (print_offset is NOT null) AND (print_offset_real is NOT null) AND (postprint is null) AND (postprint_real is null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR (is_offset AND (NOT is_silk) AND is_postprint AND (print_offset is NOT null) AND (print_offset_real is NOT null) AND (postprint is NOT null) AND (postprint_real is NOT null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR (is_offset AND is_silk AND (NOT is_postprint) AND (print_offset is NOT null) AND (print_offset_real is NOT null) AND (print_silk is null) AND (print_silk_real is null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR (is_offset AND is_silk AND (NOT is_postprint) AND (print_offset is NOT null) AND (print_offset_real is NOT null) AND (print_silk is NOT null) AND (print_silk_real is NOT null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR (is_offset AND is_silk AND is_postprint AND (print_offset is NOT null) AND (print_offset_real is NOT null) AND (print_silk is null) AND (print_silk_real is null) AND (postprint is null) AND (postprint_real is null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR (is_offset AND is_silk AND is_postprint AND (print_offset is NOT null) AND (print_offset_real is NOT null) AND (print_silk is NOT null) AND (print_silk_real is NOT null) AND (postprint is null) AND (postprint_real is null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)) OR (is_offset AND is_silk AND is_postprint AND (print_offset is NOT null) AND (print_offset_real is NOT null) AND (print_silk is NOT null) AND (print_silk_real is NOT null) AND (postprint is NOT null) AND (postprint_real is NOT null) AND (job_to_stok_real is null) AND (job_to_hand_customer is null)))

Давай "мобилами" мериться, у кого запрос круче? У меня вот такие есть:

SELECT a.pk_orderentry FROM ((((((((((orderentry as a INNER JOIN invoice_orderentry AS d ON a.pk_orderentry = d.fk_orderentry) INNER JOIN invoice AS e ON d.fk_invoice=e.pk_invoice) INNER JOIN customer AS f ON a.fk_customer=f.pk_customer) INNER JOIN companyinfo AS b ON f.fk_companyinfo=b.pk_companyinfo) INNER JOIN productcat AS c ON a.fk_productcat=c.pk_productcat) INNER JOIN orderproduct AS g ON a.pk_orderentry=g.fk_orderentry) LEFT JOIN stuff_design AS h ON h.fk_orderproduct=g.pk_orderproduct) LEFT JOIN stuff_prepress AS i ON i.fk_orderproduct=g.pk_orderproduct) LEFT JOIN stuff_offset AS j ON j.fk_orderproduct=g.pk_orderproduct) LEFT JOIN stuff_silkscreen AS k ON k.fk_orderproduct=g.pk_orderproduct)WHERE a.fk_employee = 45 AND datehand2customer IS NOT NULL AND a.pk_orderentry > 2352 AND a.orderdate >= '2002-03-01 00:00' AND a.orderdate < '2002-04-01 00:00' AND b.nickname LIKE 'Pupkin%' AND a.order_id LIKE '74%' AND c.productcatname LIKE 'Буклет%' AND a.duedate >= '2002-03-20 00:00' AND a.duedate < '2002-03-21 00:00' AND e.pk_invoice LIKE '2002/%' AND e.invoicedate >= '2002-03-21 00:00' AND e.invoicedate < '2002-04-01 00:00' AND e.ammount LIKE '%' OR h.date_taken IS NOT NULL OR i.date_taken IS NOT NULL OR j.readyfilms IS NOT NULL AND h.confirmed AND i.confirmed AND j.done OR k.done ORDER BY a.pk_orderentry LIMIT 10 OFFSET 140

%))))

2 vada

А как дела с документацией по JBOSS обстоят, могли бы подсказать?

Со многим из написанного соглашусь..
но "У него даже встроенный процедурный язык как родной брат оракла." это явно не так.. Не надо выдавать желаемое за действительное..
Или ты протсо не очень хорошо знаешь PL/SQL. Для "желания подумать" пожалуй хватит двух ключевых слов (о "мелочах" типа проверки синтаксиса структр таблиц я даже не говорю)
1) дебаг (отладка)
2) пакеты и полиморфизм.
Больше врядли стоит называть...

Ну с ХМЛ ты не в ту сторону копаешь.. Если вытягивать данные в Аплликейшн сервер, прасить в DOМ то ты обречен на низкую скорость, и сам постгрес тут не причем.
У него нет, и я так понимаю скоро не появиться механизамов для того чтобы эту работу делать внутри сервера. %(

Вобщем, до маленького оракла ему пока еще не светит.


Ну а меряться запросами это ваше бред, тем более без форматирования.. Я не изврашенец, чтобы читать запросы плантекстом в десятки строк %)

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

И вопрос даже не в сложности самих запросов, а в оптимизаторе и скорости их выполнения. Ибо если база не справляеться с запросом (в рамках своего синтаксиса) это ваше не база. А вот скорсоть выполнения очень даже можно оценить.