Интересно, что такого стало в постгресе, что он вдруг лучшим стал .

будем считать авансом.

* Best Development Tool: Perl 5.8.0

Отлично! Когда же выйдет perl6 ??? Уж прямо жду-не-дождусь! :)

A WEBMIN тоже здесь!!!

> * Best Development Tool: Perl 5.8.0

Маразм крепчал, и танки наши быстры.

> Отлично! Когда же выйдет perl6 ??? Уж прямо жду-не-дождусь! :)

Точна. Вот это будет угар :-)))))))

> Интересно, что такого стало в постгресе, что он вдруг лучшим стал

Он всегда был лучшим. Просто каждый год давать награду дригие обидятся :-)

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

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

ИМХО mysql больше заслужила награды. В ней гораздо больше серьезных изменений к лучшему.

>LamerOk

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

_

> Ну объясни нам, чем он плох, попытайся еще раз.

А чего тут объяснять ?? Если кому-то нравится его синтаксис - то ради бога.. Разве я против ?? У нас свободная страна и все такое... :-)))))))

Я считаю, что здесь целых 3 темы для флейма, так что пост
очень удачный:
1. best DB: Postgresql vs. MySQL|Oracle|SQLite ...
2. best development tool: Perl vs.
Java+Eclipse(или еще что-нибудь)
|Python|Kylix|...|nano+BASIC :)
3. best browser: Mozilla vs. konqueror|lynx|[e]links|...|wine+IE

Что-то все сильно проамериканское. Ни одной европейской поделки я не увидел.

Так и есть, или я ошибаюсь?

а что за Jahshaka ? кто нибудь видел это чудо ? :)

> ИМХО mysql больше заслужила награды. В ней гораздо больше серьезных изменений к лучшему.

Эх... не писали вы большие проэкты с использованием mysql, дык там сразу все его минуса вылазят (хотя бы отсутствие вложеных запросов (решается join) и тригеров :)

Altix от SGI - действительно сила. Только бобов немерянно стоит...

Вуди, а я вот например пишу под Оракл и триггеров стараюсь вообще избезать. Потому, что всю логику на них все равно не напишеш и так и сяк придется писать процедуры, даже очень большие процедуры. Потом с этими тригерами слишком много переключения контекстов - SQL - PL/SQL. Оверхеад - процентов 30-50%. Потом при дерганьи большого ко-ва записей роу-триггеры вообще - маразм. Тормозят, понятно. Вот когда в Оракле придумают наконец чтобы триггеры дизейблились-енэйблились сессионно да еще и не ДДЛ статмэнтом - тогда я буду им (триггерам) многократно рад. Или хинтом обруливать (Наример чето типа того: INSERT /*+ NO_FUCKING_TRIGGERS */ INTO ... SELECT * FROM FUCKING_TABLE).

Ну, это скорее оффтопик. Так что извиняюсь.

Молодцы постгресовцы..

Хотя меня больше интересует reader's choice чем editor's choice.

* Best Development Tool: Perl 5.8.0 * Best Database: PostgreSQL

Обоим на свалку!

Без сомнения эта БД стоит внимания. SQL довольно мощьный. Но когда пробелма с памятью закончится к сожалению так пока и не понятно. :(

ОК.

Что там за проблема с памятью? ;) на Linux-e??
По поводу Oracle и триггеров ... в PostgreSQL есть механизм RULE, по-простому он похож на триггеры, за исключением того, что он срабатывает не на каждую запись, а на одно выражение, например UPDATE MMM SET X=10; в таблице с 10 записями:
- триггер на UPDATE сработает 10 раз;
- rule на UPDATE сработает 1 раз.
Из практики боевой эксплуатации RULE быстрее TRIGGER иногда очень значительно, нетрудно догадаться почему, в PostgreSQL они давно, работают стабильно, как и вся СУБД. :))

А вот разница между SQL и PL/pgSQL в PostgreSQL действительно ощутимая на нагруженных базах, да и на сложных одиночных процедурах тоже, хотя с 7.1 они улучшают это...

2 saper (*) (2003-07-25 00:22:44.338046)

> Что там за проблема с памятью? ;) на Linux-e?? 

Как не обидно но таки да.
model name      : Pentium III (Coppermine)
cpu MHz         : 866.480
ОЗУ 128
СВАП 512
В таблице 16 млн записей. Делаем:
update tbl set fld1='new value';
память начинает исчезать и минут через 5-10 процесс гибнет из-за
нехватки памяти (после того как заканчивается свобоная память 
ОЗУ и СВАП). Правда нужно отдать должное - гибнет отлько один
процесс (т.е. я могу тут же подконнектиться и работать дальше)
в отличии от MySQL, который на таких операциях вылетает полностью
и его приходится опять запускать.
До 3-х млн записей - работает без проблем.

Не могу сказать что такие вещи используются везде, но бывает нужно.
Такие БД как FireBird, SyBase - долго хрустят, но не валятся. Но у 
SyBase есть проблемы в другом, а в FireBird 1.0 SQL сильно 
не дотягивает до PostgreSQL.

Вобщем вопрос о легкости, силе и скорости БД можно долго обсуждать и
пока я еще не нашел ничего такого что бы могло в себе содержать все
эти вещи. Вроде как хвалят Cache - но я пока не встречал ни одного
живого человека, который реально пользовал бы ее. А у самого не 
хватает времени на изучение и тестирование оной.

Если кто знает как эта проблема с памятью борется - буду признателен
т.к. считаю эту БД действительно достояной внимания.

Спасибо

ОК.

Предыдущему анонимусу.. Вот у меня сейчас (для другой задачи) в mysql базу залито около 50 миллионов записей (обьем таблицы примерно два гига). Попробовал ваш запрос - без проблем отрабатывается.

Странные вещи вы говорите. Не знаю как насчет постгреса - а насчет mysql вы что-то похоже с потолка взяли. Кстати - как это вы перезапускаете mysql? Он однако в скрипте вертится, если вдруг подохнет, то через секунду перезапустится. Не надо его специально перезапускать.

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

> ОЗУ 128

А если поставить 64, тогда будет можно материть вообще все СУБД.

> Вот когда в Оракле придумают наконец чтобы триггеры дизейблились-енэйблились сессионно да еще и не ДДЛ статмэнтом - тогда я буду им (триггерам) многократно рад.

В постгресе можно триггеры выключать dml-командой.

> ОЗУ 128 > Если кто знает как эта проблема с памятью борется - буду признателен

Может сами догадаетесь? Не стыдно для серьезных задач держать рухлядь? Это все-таки RDMS сервер а не пукалка типа telnetd

память

> минут через 5-10 процесс гибнет
что страное у Вас творится - версии ПО? (kernel, pgsql и тд)
размер shared? сколько под буфер сортировки отведено?
как часто делается vacuum? сколько места на дисках?
у нас был случай - один программер наваял такое, что снаала кончалось ОЗУ, потом место на диске потом машина колом вставала (фришник был кстати - но я думаю это не имеет никакого значения)

2anonymous (*) (2003-07-24 18:06:42.462757)
покажи какими тестами мерял производительность?
как узнал что тормоза именно в переключении контекстов, а не в мозгах?

показывай тесты и конкретные цифры.
иначе - это все брехня, что ты сказал.