PostgreSQL 8.3: улучшение производительности в разы

хм... посмотрим, посмотрим.

Ебилды ждемс

Клёво. Прирост действительно впечатляет.

зы: По ссылке цвеные графики и описалово, так что рекомендую сходить по.

Мля, я вот удивляюсь.... В каждом релизе какой-либо проги все время пишут про увеличение производительности. А на деле всё только тормозит с каждым релизом все больше и больше. Помню я в инет лазил спокойно и с гафикой работал 2D/3D на Pentium 100MHz RAM: 32Mb и видео S3 Virge 2Mb под WinNT... А сейчас мне мало 2-х ядреного проца 2.6GHz и 4Gb RAM'a Куда катиться этот мир......

по теме - НЕ ВЕРЮ!!!!!!!

только я не понял одного: На графиках сравнивается нагрузка на сервер до 21:00 до обновления и после 21:00 после обновления базы. Но многократный прирост производительности можно свалить на окончание рабочего дня и ночь, в то время как версия 8.2 отражает загрузку в рабочее время после 12:00. Очень хотелось бы увидеть график 8.3 в будни с 12:00 до 22:00.

> А сейчас мне мало 2-х ядреного проца 2.6GHz и 4Gb RAM'a

Vista?

> Ебилды ждемс

Уже давно есть в багзиле.

> Помню я в инет лазил спокойно и с гафикой работал 2D/3D на Pentium 100MHz RAM: 32Mb и видео S3 Virge 2Mb под WinNT... А сейчас мне мало 2-х ядреного проца 2.6GHz и 4Gb RAM'a Куда катиться этот мир......

А ты попробуй сейчас на той же машине поработать с теми же программами.

Мне кажется, психологически комфортная когда-то скорость ныне уже некомфортна.

там написано:

> Нагрузка на сервер баз данных в дневное время (приблизительно с 7:00 до 23:00) слева и справа одинакова — 130-150 TPS

так что предполагается сравнивать с 7 утра имеющийся справа кусок с предыдущем днем. ну а так я попросил автора добавить туда еще картинку с TPS, чтобы нагляднее было

> ... улучшении производительности PostgreSQL ...

Я в каждой новости о PostgrSQL об этом читаю. Он так плохо работал раньше?

> Я в каждой новости о PostgrSQL об этом читаю. Он так плохо работал раньше?

ну что значит так плохо да, были неэффективные алгоритмы, например, checkpoint-ы, для тех кто знает. вот щас они стали гораздо лучше. а вообще-то вы в чем-то правы: производительность (не говоря уж о возможностях) postgresql 7.4 и 8.3 не сравнить, слон щас стал реактивным по сравнению со старыми версиями

>Vista?

Типа гном на Pentium 100MHz RAM: 32Mb и видео S3 Virge 2Mb летает...

>А ты попробуй сейчас на той же машине поработать с теми же программами.

>Мне кажется, психологически комфортная когда-то скорость ныне уже некомфортна.

http://forum.ixbt.com/topic.cgi?id=15:46970

>Куда катиться этот мир......

+1 :)

>Я в каждой новости о PostgrSQL об этом читаю. Он так плохо работал раньше?

Нет предела совершенству :).

ЗЫ. В разы, не в разы, а шустрее стал, факт. Хотя обошлось не без проблем, из-за некоторого, более строгого отношения к систаксису что-ли(я из ответа с pgsql-bugs так и не понял, баг это, или фича), пришлось вносить коррективы в код храненок и клиентских запросов и пересоздать пару гин-индексов, а то некоторые запросы впадали в жесткий сегскан.

>>> Куда катиться этот мир......

понятное дело куда - в биореактор. вот только скорости побольше наберем

> Хотя обошлось не без проблем, из-за некоторого, более строгого отношения к систаксису что-ли(я из ответа с pgsql-bugs так и не понял, баг это, или фича), пришлось вносить коррективы в код храненок и клиентских запросов и пересоздать пару гин-индексов, а то некоторые запросы впадали в жесткий сегскан

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

Кстати, а есть бенчмарки оного по сравнению с MySQL, MS SQL, Firebird и Oracle? На одинаковом железе и с описанием того на чем бенчмаркили и как тюнили? А в идеале сравнительный анализ какие вещи на каких БД дорогие, а что оптимизировано.

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

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

>Кстати, а есть бенчмарки оного по сравнению с MySQL, MS SQL, Firebird и Oracle?

на гетзефак загляни, там точно есть :)

>Потому что пытался банально почитать интернеты и вижу радикально расходящиеся мнения — половина источников говорит что Postgres дикий тормоз, половина говорит что он очень быстр.

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

Не читайте за обедом советские интернеты. Других нет? Вот никакие и не читайте...

Некоторые изменения должны неплохо ускорить скорость выполнения некоторых запросов движка lor'а. Впрочем мы пока подождем релиза федоры с 8.3 на борту

> Потому что пытался банально почитать интернеты и вижу радикально расходящиеся мнения — половина источников говорит что Postgres дикий тормоз, половина говорит что он очень быстр.

PostgreSQL надо уметь готовить. Если MySQL-приложение портировать на постгресс не меняя методов работы с БД, то результат будет медленным. С другой стороны можно довольно легко придумать ситуацию, на которой MySQL будет тормозить, а постгресс летать.

> Я в каждой новости о PostgrSQL об этом читаю. Он так плохо работал раньше?

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

На этот счет есть флеймоопасная статья в СисАдминистраторе, в которой авторы бенчмаркили их блогохостинг на MySQL и PostgreSQL. Так и называется: "PostgreSQL vs MySQL", http://www.samag.ru/cgi-bin/go.pl?q=articles;n=07.2007;a=02 (авось).

> на гетзефак загляни, там точно есть :)

А Балмер танцующий там есть? Тогда зайду, непременно. Когда с проивзодительностью Postgres разберусь.

> А пресвятой Стоунбрейкер вообще считает что "один размер неподходит всем", и "пришла пора переписывать субд".

Так кто же был бы против, переписать это всегда дело. Тем более что, к слову, свободных истинно реляционных БД как-то и не особо есть, а Третий Манифест сулит благодать и мир во всем мире.

> Не читайте за обедом советские интернеты. Других нет? Вот никакие и не читайте...

Вдоль я пока не планирую. Вещества не использую. От быдланства, стараюсь убегать — опасаюсь биореактора. Так что никак без чтения интернетов нельзя обойтись.

> Если MySQL-приложение портировать на постгресс не меняя методов работы с БД, то результат будет медленным.

Большое спасибо.

> http://www.samag.ru/cgi-bin/go.pl?q=articles;n=07.2007;a=02

Посмотрел... Какое-то оно, как подмечают там в комментариях, и правда, странное у MySQL поведение... Но, учту, спасибо.

Мне вот всегда было интересно, как постгря работает в вебе? Она ж стартует по процессу на каждое соединение - это ж безумно дорого, если разом привалит тысяча-другая человек?

>Мне вот всегда было интересно, как постгря работает в вебе? Она ж стартует по процессу на каждое соединение - это ж безумно дорого, если разом привалит тысяча-другая человек?

Для этого и существуют пулы подключений. Кстати, это не только постгрес так работает.

>Так кто же был бы против, переписать это всегда дело. Тем более что, к слову, свободных истинно реляционных БД как-то и не особо есть, а Третий Манифест сулит благодать и мир во всем мире.

А что, где то вообще существуют, пусть проприетарные, истинно реляционные БД?

> А что, где то вообще существуют, пусть проприетарные, истинно реляционные БД?

FOSS — Rel. Проприетарное — Dataphor. Там, соответственно, реализации D — D4 в Dataphor и Tutorial D в Rel.

Может PostgreSQL и лучше, но баблос пилить на MSSQL намного эффективней. Факт.

А что народ скажет про http://www.h2database.com/html/performance.html ? :)

>PostgreSQL надо уметь готовить. Если MySQL-приложение портировать на постгресс не меняя методов работы с БД, то результат будет медленным.

Хм. Т.е. если у меня основная нагрузка - банальный "select * from table where id=NNN order by date desc limit xxxxx, yy;", который, как бы, портировать уже дальше некуда, то Постгрес будет хуже? :D

> anonymous (*) (21.02.2008 0:31:11) Соглсен, бабульки собираются лучше на офтопичной СУБД

>> А что, где то вообще существуют, пусть проприетарные, истинно реляционные БД?

>FOSS — Rel. Проприетарное — Dataphor. Там, соответственно, реализации D — D4 в Dataphor и Tutorial D в Rel.

Спасибо. Значит таки есть. Хотя статус альфы у одних, и реализация в виде прослойки над SQL-СУБД у других, не дают пока повода говорить о победе коммунизма :)

Приятная новость.. Надеюсь, что так оно и будет..

>А что народ скажет про http://www.h2database.com/html/performance.html ? :)

>Version 8.1.4 was used for the test. The following options where changed in postgresql.conf: fsync = off, commit_delay = 1000. PostgreSQL is run in server mode. It looks like the base performance is slower than MySQL, the reason could be the network layer.

Сто раз уже писалось, что у постгреса политика, что субд должна запускаться и работать на минимальной дефолтной конфе, там параметры детские выставлены по умолчанию, в 8.2 их немного увеличили, "по многочисленым просьбам тружеников села и промышленности", потому как это первейшая причина утверждения о сливе MySQL. Тут и fsync = off не поможет.

>Сто раз уже писалось, что у постгреса политика

На самом деле вопрос шкурный и офтопичный. Надеюсь услышать какие-нибудь реальные отзывы о H2. Есть идея прикрутить её в embedded виде в один проект, который сейчас базируется на внешнем mysql.

>На самом деле вопрос шкурный и офтопичный. Надеюсь услышать какие-нибудь реальные отзывы о H2. Есть идея прикрутить её в embedded виде в один проект, который сейчас базируется на внешнем mysql.

Так если нужен embedded, то другое дело. Решение, судя по тестам, как раз на ембедед точится, значит будет хорошо. Это уже если вам оно надо, то пожалуйста. Стоунбрейкер прямо прописывает ембедед для систем обработки потоковых данных, например информации фондовых бирж. Вот что про это думает команда разработкт Постгреса:

Features We Do Not Want

... Embedded server (not wanted)

While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliabily and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases.

>Т.е. если у меня основная нагрузка - банальный "select * from table where id=NNN order by date desc limit xxxxx, yy;", который, как бы, портировать уже дальше некуда, то Постгрес будет хуже? :D

Лучше будет потому что mysql что-то тупит с order by desc и limit из за чего приходиться делать дублирующую таблицу и туда сливать данные периодически.

> На этот счет есть флеймоопасная статья в СисАдминистраторе, в которой авторы бенчмаркили их блогохостинг на MySQL и PostgreSQL. Так и называется: "PostgreSQL vs MySQL", http://www.samag.ru/cgi-bin/go.pl?q=articles;n=07.2007;a=02 (авось).

Там автор тысячу раз прав в последнем комментарии:

> Для конкурентного read/write доступа это показывает совершенно ожидаемые результаты для MyISAM и InnoDB. > Сравнивать скорость работы в read-only или write-only режиме работы СУБД лично я не вижу ни малейшего смысла.

В общем случае (если не планируется например рид-онли базы) - выхолощенные до элементарных операций тесты бессмыссленны. А на комплексных подобно приведенному по ссылке соснёт не только MySQL, но и MsSQL.

В этом плане было бы любопытно посмотреть на сравнение постгреса с ораклом.

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

с каких пор fork() стал «безумно дорогим»? на винфак!

>Надеюсь услышать какие-нибудь реальные отзывы о H2. Есть идея прикрутить её в embedded виде в один проект, который сейчас базируется на внешнем mysql.

KRoN73 - для embedded есть SQLite и хорошо так есть :)
Кстате - to любителю "померить скорость" - этот малыш порвет всех!

PostgreSQL может и хороша, но блин, до чего муторна в установке. От дистрибутива к дистрибутиву - все разное, от конфигов до до мест их хранения. До ли дело ms access - все интуитивно понятно.

>KRoN73 - для embedded есть SQLite и хорошо так есть :)

>Кстате - to любителю "померить скорость" - этот малыш порвет всех!

Ну ну. "Тормоз перестройки" (с) это, как только доходит дело до более менее серёзных запросов.

> Хм. Т.е. если у меня основная нагрузка - банальный "select * from table where id=NNN order by date desc limit xxxxx, yy;", который, как бы, портировать уже дальше некуда, то Постгрес будет хуже? :D

SELECT с LIMIT'ом постгресс только относительно недавно научился быстро выполнять, старые версии делали полную выборку и отрезали от нее лишнее. Большие запросы при этом еще и на диск сохранялись во временные файлы.

Впрочем я имел ввиду не это, а другую логику работы с UPDATE и блокировками.

> Мне вот всегда было интересно, как постгря работает в вебе? Она ж стартует по процессу на каждое соединение - это ж безумно дорого, если разом привалит тысяча-другая человек?

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

> Постгресс имеет очень большой движек, содержащий много функциональности которая не особенно оптимизирована, но качественно работает.

Неоптимально, но качественно? :) сильно сказано.

> SELECT с LIMIT'ом постгресс только относительно недавно научился быстро выполнять, старые версии делали полную выборку и отрезали от нее лишнее. Большие запросы при этом еще и на диск сохранялись во временные файлы.

Это пример качественной, но неоптимальной работы? :) тогда легко поверить что у постгреса большой потенциал в плане увеличения скорости работы.

> 1000 процессов постгрессов выжрут всю память и будут работать не эффективно.

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