LINUX.ORG.RU

PostgreSQL 8.0


0

0

NY, NY: 19 января 2005 г. - Международная команда разработчиков PostgreSQL выпустила версию 8.0 объектно-реляционной системы управления базами данных, закрепив позицию PostgreSQL как самой передовой в мире СУБД с открытым исходным кодом. Версия включает такие возможности, которые ранее были доступны только в самых дорогих закрытых СУБД. Это значительно повышает интерес к PostgreSQL и среди пользователей, и среди производителей программного обеспечения.

Кроме новых возможностей и значительного улучшения производительности, PostgreSQL 8.0 демонстрирует не имеющий равных темп разработки открытого программного обеспечения. Более десятка компаний, включая Red Hat, Fujitsu, Afilias, Software Research Associates, Inc., 2nd Quadrant, и Command Prompt Inc., вместе с сотнями разработчиков, внесли свой вклад в реализацию идей, количество которых значительно больше, чем у любой из предшествующих версий.

Новые возможности включают:

"Родная" поддержка Windows: PostgreSQL теперь работает в ОС Windows без дополнительных "прослоек" для эмуляции системных вызовов. Это значительно улучшает производительность по сравнению с предыдущими версиями, и предоставляет реальную альтернативу закрытому программному обеспечению баз данных для независимых производителей программного обеспечения, корпоративных пользователей и индивидуальных разработчиков для Windows.

Точки сохранения (savepoints): Эта возможность, которая есть в стандарте SQL, позволяет выполнять откат отдельных частей транзакций, не прерывая транзакцию в целом. Это полезно для разработчиков бизнес-приложений, требующих сложных транзакций с восстановлением после ошибок.

Восстановление на определенный момент (point in time recovery) : Эта функция дает возможность полностью восстанавливать данные из непрерывно архивируемых журналов транзакций, что является давно востребованной альтернативой ежечасному или ежедневному резервному копированию критичных данных.

Табличные пространства (tablespaces): Критически важные для администраторов многогигабайтных хранилищ данных, табличные пространства позволяют размещать большие таблицы и индексы на отдельных дисках или массивах, что повышает производительность запросов.

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



Проверено: maxcom ()

Ответ на: комментарий от sad_spirit

Напиши мне плиз на vvtk собака mail.ru

>> предлагаю провести совместный бенчмарк используя TPC-C тест от OSDL (http://sourceforge.net/projects/osdldbt/). Я берусь настроить и сконфигурить MySQL 4.0.23. Есть желающие сделать тоже самое с PostgreSQL ? >готов поучаствовать...

bizon
()
Ответ на: комментарий от geekkoo

> скорость мускуля на InnoDB значительно ниже

Откуда такая (дез)информация? Где твои цифры?

annonymous ★★
()
Ответ на: комментарий от sad_spirit

> готов поучаствовать...

А я готов быть судьёй. :) ну и ещё на постгресе потестить...

SKYRiDER ★★★
()
Ответ на: комментарий от anonymous

> Далее: "Both databases were configured with a 24 MB buffer pool (called shared cache in PostgreSQL) and a 4 MB log buffer" Угу. У постгресса 4 мегабайта на лог.

Кстати, а что имеется ввиду под словами "log buffer"? Каким параметром в postgresql.conf это настраивается? Может это wal_buffers?

SKYRiDER ★★★
()
Ответ на: комментарий от SKYRiDER

> Может это wal_buffers?

Скорее всего именно так. Непонятно, что так не понравилось товарищу.
4 мб - очень неплохое значение. Рекомендованное значительно меньше.

annonymous ★★
()
Ответ на: комментарий от annonymous

> Показательно здесь только то, как здорово оптимизировали ядро 2.6
> для работы с бд. Именно оно выдаёт эти разы преимущества.

Извините, вы это всерьез насчет того, что переход на ядро версии 2.6 с 2.4 даст такие результаты? Как насчет бенчмарков, где MySQL увеличивает свое быстродействие на порядок на новом ядре?

Как бы то ни было - показательно в моем случае именно то, что требуемый уровень быстродействия PostgreSQL задается прежде всего железом и показывает уровень реализации масштабируемости в Постгресе. Также некоторый прирост в быстродействии, на мой взгляд, дал переход с PostgreSQL версии 7.2 на 7.4 (смотрите бенчмарки http://benchw.sourceforge.net/benchw_results_postgres_history.html).

Mammoth
()

Давайте потестируем по тестам с http://benchw.sourceforge.net/ Кто хочет? Я уже начал тестировать. Между прочим csv файлы с данными (суммарный обьём 1.1 Гб) загрузились в постгресовскую базу менее чем за 11 минут на простом Duron 750 и IDE винте. Кто там рассказывал басни о 2.5 дней для загрузки данных в постгрес? :-<

P.S. я сначала хотел погонять OSDL тест на постгресе, но его хрен соберёшь нормально. :( К тому же он хочет пересобраные постгрес(!!!) с небольшой правкой какого-то #define'а. Нунах.

SKYRiDER ★★★
()
Ответ на: комментарий от Mammoth

> вы это всерьез насчет того, что переход на ядро версии 2.6 с 2.4 даст такие результаты?

Абсолютно.

> Как насчет бенчмарков, где MySQL увеличивает

Такие показатели есть только по постгресу. Mysql спроектирован более
правильно. У него результаты тоже пмовышаются, но не настолько.

> требуемый уровень быстродействия PostgreSQL задается прежде всего железом

Глупость. Мощь железа увеличилась вдвое. Производительность постгреса
в 11 раз. Каким местом думаем?

annonymous ★★
()
Ответ на: комментарий от annonymous

> Скорее всего именно так. Непонятно, что так не понравилось товарищу. 4 мб - очень неплохое значение. Рекомендованное значительно меньше.

Мне вот интересно откуда ты знаешь рекомендованое значение? Кто его рекомендует? Насколько я знаю, в постгресе дефолтное значение wal_buffers = 8 (т.е. 64 kb), но дефолтное != рекомендованое.

Все (надеюсь) знают, что те параметры которые стоят в дефолтном постгресовском конфиге не годятся для production, обычно значения многих параметров нужно увеличить на порядок, а то и на два(!) чтобы добиться хорошей производительности.

SKYRiDER ★★★
()
Ответ на: комментарий от SKYRiDER


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

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

bizon
()
Ответ на: комментарий от bizon

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

В постгресе тоже самое. :)

Кстати, я уже benchw на постгресе погонял, если интересно могу выложить результаты. Ещё хочу погонять этот тест на mysql, но это уже наверно завтра.

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