Очень хорошо, что мы в регилиозных войнах. Есть у меня следующее имхо.

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

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

 чо?   
он данные не обрабатывает. СОВСЕМ НИКАК не робрабатывает. Он чистит. И вообще уже не нужен в последних версиях.

    ухо горло нос сиська писька хвост. Я прочитал старинную мантру по изгнанию демона, уничтожающего орфографию   

В постгресе есть массивы. А еще там есть питон, и он живет прямо в хранимых процедурах   

нет, vacuum для очистки нужен... и даже если он делается автоматом, на это СУБД затрачивает время и ресурсы... эта плоха... =))))

IlyaDipl, у тебя есть бенчмарки, которые показывают, что это плохо?
А тебе не кажется, что оно может накапливать цели для вакуума, экономя m на запросе, где n количество запросов, а vacuum делается за v времени.
В итоге получаем, что vacuum ускоряет процесс при значении v < m*n   

Такой вариант не думал? )

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

В 8-ке не нужен вакум или он там выполняется автоматически? Дай ссылку где об этом можно почитать.

А вообще постгрес оставляет сильно ощущение недоделанности. Такое ощущение, что ребята гонятся за количеством фишек, а про то, что это еще все надо качественно реализовать забывают. Простой пример, есть у них такой тип интервал, разность двух дат дает интервал, и к дате можно прибавлять интервал, весьма удобно. Но вот реализовать его по человечески они так и не смогли. Есть таблица с сессиями пользователей в которой есть две колонки: начало сессии и конец сессии, делаем запрос:

и получаем наши законные 57:43:12, до тех пор пока среди интервалов не окажется интервала более суток и пот тогда мы получим замечательное: 2 days 76:12:32. Мне вот просто интерестно они как вообще эти интервалы суммируют, по компонентно что ли.
Или например разная политика объеденения колонок в union, одна версия объединяет их по именам, другая по порядку следования, если совпадают типы иначе вообще каким-то непостижимым образом.
Или невозможность изменить поведение каскадов в foreign key, только удалить и создать заново. Со всеми прелестями создания индексов заново.
Хранимые процедуры можно писать на 10 различных языках, но основной PL/pgSQL неразвит.
Может быть конечно это дело не в постгресе, а я зажрался после Oracle.


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

да. причем, если не ошибаюсь, UDF были уже задолго до 5 версии

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

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

Про это речи я не видел 


Так пусть так и напишет, а не придумывает отмазки.

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

Не знаю точно, это минус самого PostgreSQL или кривая реализация JDBC драйвера: нельзя сделать большую выборку (~100 000 строк), вылетает OutOfMemoryError. Судя по всему, он пытается сразу весь курсор загнать в память. В том же Oracle курсор находился на сервере, и по мере скролинга подгружался на клиента.

выгружал из Postgre большие выборки (несколько сотен тыс. строк) на клиент... правда работал через Зеос. Нормально, хоть и жрало память.
Постранично - это конечно хорошо, но что делать, когда нужно дофига данных в кубе обработать?  

Если мне не изменяет склероз, в статемент в postgres jdbc можно указать размер буфера для считывания записей из курсора. Что то типа

statemet.setFetchSize(100); чтобы считывать по 100 записей из курсора. Ну и соответственно resultset надо при этом делать типа ResultSet.TYPE_FORWARD_ONLY