LINUX.ORG.RU

Новая версия PostgreSQL - 8.3.0

 ,


0

0

4 февраля 2008 года вышла новая версия свободной СУБД PostgreSQL - 8.3.0.

Основные изменения:

* миграция модуля для полнотекстового поиска (contrib/tsearch2) в ядро системы;
* реализация Heap Only Tuples (HOT);
* теперь autovacuum включён по умолчанию;
* возможен запуск сразу нескольких процессов autovacuum;
* заметное уменьшение дискового пространства, занимаемого базами данных;
* выполнение транзакций, не модифицирующих данные, не приводит к увеличению значения счётчика транзакций (xid);
* реализован механизм автонастройки параметров процесса bgwriter;
* оптимизирован механизм получения результата для запросов с использованием « …ORDER BY … LIMIT…» (т. н. Top-N sorting);
* поддержка XML, в том числе новый тип данных - xml;
* автоматическая инвалидация кэша плана запросов для PL/pgSQL-функций;
* конструкции «CREATE FUNCTION … RETURNS TABLE» и «RETURN TABLE…» для создания функций, результатом которых является таблица;
* поддержка операции обновления для курсоров;
* стандартная (ISO/ANSI SQL) конструкция «ORDER BY … NULLS FIRST/LAST» для упрощения установки порядка следования NULL-значений (также помогает при миграции с других СУБД);
* индексация NULL-значений в GiST-индексах.

Подробное описание на русском языке: http://postgresmen.ru/articles/view/78

>>> Скачать

anonymous

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

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

>Если владеешь великим буржуйским языком - то матвъю легко реализовать и руками - поддержка в ядре не особенно то и нужна. Более подробно, для начала, используй как отправную точку: http://www.benjaminarai.com/benjamin_arai/index.php?display=/postgresql_mater.. .

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

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

> системы бизнес аналитики

Ололо, оналитик ты наш. Когда же это бизнес-быдло научится пользоваться дефисом?

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

>Ололо, оналитик ты наш. Когда же это бизнес-быдло научится пользоваться дефисом?

Дефис есмь перст диавольский, особо рядом с премерзким словом "бизнес". Не нам угодно его использовать, безблагодатно это.

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

> Это называется костыль, а не реализация матвью

Прикрутить RULES на INSERT, DELETE, UPDATE к представлению не подходит?

anonymous
()

А когда сделают чтото на подобие пакетов для процедур. Ну как в oracle. Ато если их там очень много то както невкусно получается. В oracle вкуснее.

Может оно уже есть да я незнаю, подскажите пожалуста

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

> А когда сделают чтото на подобие пакетов для процедур.

Дадад, и менеджер пакетов с зависимостями, и debconf туда же портировать, чо там.

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

оболдуйство какоето. Ты видно не понимаешь сути.

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

>>> * миграция модуля для полнотекстового поиска (contrib/tsearch2) в ядро системы;

> Отлично!

> А как его сделать case-insensitive для русского в utf-8 кто-нибудь может сказать?

Ты бы лучше рассказал, как его сделать case-sensitive :)

Если локаль базы настроена - то поиск case-insensitive.

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

> кроме того, что мешает вместо tsearch2 ... использовать любой xapian или sphinx? латентная любовь к "интегрированным системам"?

ACID

teodor
()

Автар уверенно лажает:

> * индексация NULL-значений в GiST-индексах.

Перевод: постгрес теперь может использовать Btree и GiST индексы в запросах типа column is NULL.

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

> В дереве портов FreeBSD ports/databases/postgresql83-server/ уже есть.

Да кому нафиг эта фря сдалась.. Да и все равно никто не будет на ней сервер БД делать.

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

> sphinx - говноподелие, имеющее к настоящему полнотекстовому поиску отношение не более чем hello_world.с к ядру Linux.

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

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

>можно с этого места поподробней? почему sphinx говноподелие и почему он так плох для полнотекстового поиска? кстати а чем так хорош xapian ? по официальному списку фич я не увидел значительных преимуществ.

Не xapian, а lucene. Плох - алгоритмом вычисления релевантности документа (хинт: искать быстро - не значит "искать правильно").

Чем так хорош xapinan, который рекламировал другой анонимус, я не знаю.

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

>> В дереве портов FreeBSD ports/databases/postgresql83-server/ уже есть.

>Да кому нафиг эта фря сдалась.. Да и все равно никто не будет на ней сервер БД делать.

За себя говори, тупое быдло. Большая чать РУнета живет на FreeBSD.

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

> Не xapian, а lucene. Плох - алгоритмом вычисления релевантности документа (хинт: искать быстро - не значит "искать правильно").

Это единственный его минус? А если алгоритм вычисления релевантности заменить на свой, который будет устраивать, то тогда это уже не говноподелие? Опенсорс все-таки. Про lucene я знаю, но так и не попробовал в деле.

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

>> В дереве портов FreeBSD ports/databases/postgresql83-server/ уже есть.

>Да кому нафиг эта фря сдалась.. Да и все равно никто не будет на ней сервер БД делать.

Дурень - постгре на фре уделывает всех!
И только придуки типа тебя угюмо кликают в PostgreSQL_installer.msi :)

anonymous
()

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

anonymous
()

вопрос знатокам. на мускуле кажется принципиально не возможно сделать больше 1к нитей. Если постгрес создаёт нить на каждого клиента - это ведь тоже - не масштабируемо при диком количестве клиентов (хинт: а как же async IO, epolls со-товарищи?) Как у них дела со scaling-up? 10k+, типа.

как оптимайзер - такой-же "вумный" как в дб2? (хинты там тоже есть/полезны?)

Anode

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

> Если постгрес создаёт нить на каждого клиента - это ведь тоже - не масштабируемо при диком количестве клиентов (хинт: а как же async IO, polls со-товарищи?) Как у них дела со scaling-up? 10k+, типа.

Постгрес на каждый коннект форкает процесс (в его терминологии - backend), поэтому большое число коннектов для постгреса - это очень плохо. И надо использовать постоянные коннекты, поскольку fork() - это не быстро.

Используйте pgbouncer - он умеет мультиплексировать коннекции постгреса и коннект к нему намного быстрее. Т.е. это процесс, который снаружи пахнет и выглядит как постгрес и отображает N клиентов на M backend'ов.

> как оптимайзер - такой-же "вумный" как в дб2? (хинты там тоже есть/полезны?)

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

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

>Это единственный его минус? А если алгоритм вычисления релевантности заменить на свой, который будет устраивать, то тогда это уже не говноподелие? Опенсорс все-таки. Про lucene я знаю, но так и не попробовал в деле.

Если у системы полнотекстового *поиска* заменить алгоритм вычисления релевантности документа, это будет *другая* система полнотекстового поиска.

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

> Если у системы полнотекстового *поиска* заменить алгоритм вычисления релевантности документа, это будет *другая* система полнотекстового поиска.

Фига. У tsearch2 и так два независимых алгоритма счета релевантности, а можно использовать хоть черта лысого (ну если сможете сформулировать алгоритм подсчета релевантности :) )

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

>Фига. У tsearch2 и так два независимых алгоритма счета релевантности, а можно использовать хоть черта лысого (ну если сможете сформулировать алгоритм подсчета релевантности :) )

Значит, под одним названием на самом деле есть две разные поисковые системы с разнойвыдачей по одинаковым запросам. Ничего необычного.

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

> Значит, под одним названием на самом деле есть две разные поисковые системы с разнойвыдачей по одинаковым запросам. Ничего необычного.

Э-э. Интересная позиция. У меня есть Линукс. Я могу запускать X'ы и работать в них, могу не запускать и работать в консоли. Значит ли это, что у меня два компьютера? две OS?

В задачи поисковой машины входит как поиск так и релевирование - это две РАЗНЫЕ задачи. Прямая аналогия: zip и tar. Tar только объединяет файлы, сжимают результирующий файл чем-нибудь другим (gzip, bzip2, zip наконец). Zip сразу решает обе задачи, но это не значит, что у него только одна задача.

Disclaimer. Современные онлайнвые поисковые машины на миллиарды документов (типа Google) часто смешивают эти процессы. Чисто для оптимизации. Честный поиск с честным релевированием не уложится в 1 секунду на выборке в миллиард документов на современных машинах. Поэтому применяются хитрые техники, позволяющие получить topN релевантных документов и только потом их отсортировать (и то, последний шаг не всегда обязателен)

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

спасибо

>pgbouncer

это - костыль. тогда он будет узким местом. Он тоже форкает процессы, и теперь входящие запросы будут кьюится там. Потому как при 10к+ - процессов быть нигде не должно. Поэтому и написал про epoll.

оптимайзер тоже не могет быть умнее человека. Нужны механизмы управления им - если что-то не так (и если распределение объёмов данных в будущем меняться не будет) - когда он сходит с ума от десятков разных джойнов и начинает полные сканы где их можно не делать. Так в оракле и дб2 по крайней мере.

ещё раз спасибо за ответы

/Anode

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

> это - костыль. тогда он будет узким местом. Он тоже форкает процессы, и теперь входящие запросы будут кьюится там. Потому как при 10к+ - процессов быть нигде не должно. Поэтому и написал про epoll.

Блин, ты бы с ним ознакомился. Он НЕ форкающийся и даже не на тредах. Он на select'ах. И поддерживает epoll/kqueue/что-там еще

> оптимайзер тоже не могет быть умнее человека. Нужны механизмы управления им - если что-то не так (и если распределение объёмов данных в будущем меняться не будет) - когда он сходит с ума от десятков разных джойнов и начинает полные сканы где их можно не делать. Так в оракле и дб2 по крайней мере.

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

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

посмотрел (кстати в коде еполл не вижу). Да он и не нужен мультиплексору, который проблему не решает (В конце-концов ниже уровнями всё вообще выстраивается в очередь и если это делается быстро и _параллельно_ - то будет прозрачно). Проблема по-сути остаётся: транзакция не может быть не атомик и в каждый момент времени мы обслуживаем, скажем, только 1к клиентов максимум, а не 10к и не больше (дальше можно клиентов делить на базы, базы синхпонизировать итд, но это уже костыли). А клиент (код аппликации) может долго держать транзакцию по разным причинам. Клиентов можно скейлить вширь, а базу - нет - она должна быть одна (хотя бы для дебит-кредита).

Anode

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