Представлена (http://www.postgresql.org/about/news.1183) четвертая альфа версия PostgreSQL 9.0 (http://developer.postgresql.org/pgdocs/postgres/release-9-0....). Напомню, что разработчики проекта приняли решение о смене нумерации будущего релиза. Вместо версии 8.5 из-за значительности изменений будет выпущен релиз PostgreSQL 9.0.
Из новшеств, появившихся в PostgreSQL 9.0-alpha4 можно отметить:- Поддержка режима потоковой репликации (Streaming Replication (http://wiki.postgresql.org/wiki/Streaming_Replication)), суть которой в организации непрерывной передачи бинарных WAL-логов нескольким запасным серверам PostgreSQL;
- Замена pg_listener на новый работающий в памяти, высокопроизводительный механизм обслуживания Listen/Notify очереди;
- Автоматический возврат числа строк, фигурирующих в выполненном SELECT-запросе. В psql данное значение не отображается, но может быть получено с использованием программного интерфейса, подобного libpq.
- Поддержка функций ROWS PRECEDING...URL: http://www.postgresql.org/about/news.1183
Новость: http://www.opennet.me/opennews/art.shtml?num=25576
Как там насчет выдирания ИБ из рухнувшего сервера?
или опять перл скриптами?
объясните плиз, я так понимаю что всякие pgbouncer теперь будут не нужны???раз EXPLAIN теперь будет в XML и JSON - где можно ожидать использования этого?
хотелось бы увидеть всякие автоподсказки по типу я смотрю твой eplain и вижу что возможно если поднять индекс такой то (прямо код создания индекса) то не факт, но возможно план выполнения запроса будет лучше.
"Использование агрегатных функций внутри блока ORDER BY одобрено в SQL стандарте, теперь не нужно прибегать к ухищрениям для получения упорядоченного набора записей на входе агрегатных функций"кто нибудь может пример привести?
>"Использование агрегатных функций внутри блока ORDER BY одобрено в SQL стандарте, теперь
>не нужно прибегать к ухищрениям для получения упорядоченного набора записей на
>входе агрегатных функций"
>
>кто нибудь может пример привести?Пример: надо получить упорядоченный массив агрегатной функцией array_agg
(Мне кстати даже где-то этого не хватало)
Когда же они добавят нормальный partionioning, чтоб убрать все костыли, которые сейчас приходится использовать?
Когда же они добавят возможность, как мускуле, использовать конструкцию ALTER TABLE ADD COLUMN BEFORE|AFTER ?
> Когда же они добавят возможность, как мускуле, использовать конструкцию ALTER TABLE ADD COLUMN BEFORE|AFTER ?Молодой человек, вы уже порядком надоели! Используйте SELECT список_полей FROM имя_таблицы, если хотите получить поля в нужном вам порядке. Над PgSQL работают не идиоты, они пилят действительно нужные вещи, а то что вы предлагает - это как в MySQL
при чем тут select вобще?
обоснуйте необходимость BEFORE|AFTER, единственное где это могло бы пригодится это для получения предсказуемых выборок, но решение описано двумя постами выше, есть другие аргументы?
>обоснуйте необходимость BEFORE|AFTERДа смотрится это лучше. Шахматисты оценивают позицию бросив взгляд, так и тут.
Стопить гигабайтные базы на неопределенное время, чтобы лучше смотрелось - тут есть о чем подумать.
Просто типичные пользователи MySQL, похоже, не видят в этом ничего необычного. Бытие определяет сознание, как говорил классик.
>Стопить гигабайтные базы на неопределенное время, чтобы лучше смотрелось - тут есть
>о чем подумать.Сразу видно что вы админ. Я например разработчик и структура базы во время разработки может меняться не раз, эта простая функция поможет улучшить нервную систему программистам...
>Стопить гигабайтные базы на неопределенное время, чтобы лучше смотрелось - тут есть
>о чем подумать.Я уж не говорю о том что будет лочиться таблица, а не останавливаться SQL сервер. И уж тем более не говорю о том что достаточно поменять местами определение столбцов а не перелопачивать всю таблицу. Эта операция должна выполняться миллисекунды.
>Эта операция должна выполняться миллисекунды.На базах любого размера
Сразу видно, что вы разработчик, а не админ. А лочить даже одну таблицу в продакшне чаще всего невозможно, ибо может привести к непредсказуемым последствиям. А что касается разработки, то эта проблема решается достаточно несложно: создание новой таблицы и INSERT SELECT, или SELECT INTO. Правда, придется повозиться с внешними ключами. Лично мне, исходя из моего опыта, гораздо легче написать программулину, которая будет воссоздавать БД для разработки с нуля, начиная с создания схемы БД и заканчивая ее начальным тестовым заполнением. Очень помогает такое при автоматизированном тестировании.
А никто не говорит, что это нужно для экспериментов на продакшене!!! С ума посходили что ли, школьники?
Данный функционал очень полезен при разработке, на стадии проектирования, не больше не меньше!
То что ты предлагаешь писать через создание новых таблиц или каких-то скриптов - бред полнейший. Видно что ты не имел дела с большими системами, где на одну таблицу идут сотни FK и индексов.
Гораздо проще иметь такую функцию в синтаксисе, которая все сделает за тебя, не нарушая индексы и foreign key.
В реальных компаниях именно скриптами, которые свежую базу еще и контрольным набором данных населяют ...
Я и не говорю, что скриптами - это плохо! Не нужно передергивать.
Но то, что данный механизм облегчил жизнь - это факт.
Что проще, запустить выполнение одной команды, где за тебя СУБД сама все сделает (перенесет индексы, fk, размещение и оптимизацию данных и пр. пр. пр.) или писать/запускать самописное поддерлие, которое будет все делать в десятки раз медленее и не рационально? Я думаю ответ очевиден.
>Лично мне, исходя из моего опыта, гораздо легче написать программулину,
> которая будет воссоздавать БД для разработки с нуля,
>начиная с создания схемы БД и заканчивая ее начальным тестовым заполнением.Именно так! Хочешь добавить \ убавить столбец - в скрипте правишь, чекаутишь и запускаешь. Для экзальтированых мышевозов - почти все современные DB IDE - генерят именно такие скриты сами.
>обоснуйте необходимость BEFORE|AFTER, единственное где это могло бы пригодится это для получения
>предсказуемых выборок, но решение описано двумя постами выше, есть другие аргументы?
>То что ты видишь в этом лишь использование в select вобще не аргумент, а лишь указывает на твое ограниченное сознание.
Как заметили выше , про select вобще никто не говорил, кроме тебя, и понятно, что человек в здравом уме не будет писать select * from table, а укажет только те колонки, которые нужны и только в той последовательности в которой они ему нужны.......
>Когда же они добавят возможность, как мускуле, использовать конструкцию ALTER TABLE ADD
>COLUMN BEFORE|AFTER ?Я осмелился написать ажно Брюсу об этом, правда я предложил использовать что то типа ALTER TABLE MOVE COLUMN BEFORE|AFTER что будет полезней для уже существующих колонок - он ответил что типа мы о том что это хотят знаем, но пока готового решения нет. Будем ждать.
>>Когда же они добавят возможность, как мускуле, использовать конструкцию ALTER TABLE ADD
>>COLUMN BEFORE|AFTER ?
>
>Я осмелился написать ажно Брюсу об этом, правда я предложил использовать что
>то типа ALTER TABLE MOVE COLUMN BEFORE|AFTER что будет полезней для
>уже существующих колонок - он ответил что типа мы о том
>что это хотят знаем, но пока готового решения нет. Будем ждать.
>Да, будем ждать. Спасибо вам за это письмо. Чем больше будет таких запросов от разных людей, тем скорее эта фича будет сделана.
Для меня функция оч. полезная. Держать таблицы не в том порядке, в котором хочется очень не удобно. :-(
Ага, с партишонингом большая засада!
Когда сделают обязательно напьюсь!
Вот только делают уже 3 года..
и не известно когда сделают.