LINUX.ORG.RU

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

 , , ,


0

0

Появился небольшой тест, свидетельствующий о серьезном улучшении производительности PostgreSQL при переходе на версию 8.3

>>> Подробности

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

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

jcd ★★★★★ ()

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

Ебилды ждемс

anonymous ()

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

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

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

shahid ★★★★★ ()

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

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

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

anonymous ()

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

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

shahid ★★★★★ ()

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

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

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

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

anonymous_incognito ★★★★★ ()

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

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

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

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

anonymous ()

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

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

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

Casus ★★★★★ ()

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

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

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

anonymous ()
Ответ на: Re: PostgreSQL 8.3: улучшение производительности в разы от anonymous_incognito

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

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

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

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

anonymous ()

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

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

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

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

girla ()

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

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

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

anonymous ()

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

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

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

anonymous ()

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

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

UrbanSerj ()

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

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

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

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

girla ()

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

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

maxcom ★★★★★ ()

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

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

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

maxcom ★★★★★ ()

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

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

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

maxcom ★★★★★ ()

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

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

girla ()

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

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

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

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

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

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

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

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

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

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

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

anonymous ()

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

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

redbaron ★★ ()

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

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

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

girla ()

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

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

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

girla ()

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

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

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

anonymous ()

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

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

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

KRoN73 ★★★★★ ()

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

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

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

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

girla ()

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

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

MiracleMan ★★★★★ ()

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

>А что народ скажет про 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 не поможет.

girla ()

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

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

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

KRoN73 ★★★★★ ()

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

>На самом деле вопрос шкурный и офтопичный. Надеюсь услышать какие-нибудь реальные отзывы о 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.

girla ()

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

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

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

xtron ()

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

> На этот счет есть флеймоопасная статья в СисАдминистраторе, в которой авторы бенчмаркили их блогохостинг на 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.

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

anonymous ()

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

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

mirage ()

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

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

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

anonymous ()

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

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

anonymous ()

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

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

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

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

fdn ()

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

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

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

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

maxcom ★★★★★ ()

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

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

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

maxcom ★★★★★ ()

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

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

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

anonymous ()

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

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

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

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.