LINUX.ORG.RU

PostgreSQL 9.2

 


1

2

Вышла новая версия СУБД PostgreSQL — 9.2.

Основные изменения в этой версии:

  • «Index Only Scans» — возможность выбирать данные прямо из индекса, если в индексе они есть. До этого СУБД использовала индекс только для поиска, непосредственно данные всегда выбирались из страниц данных. Данная функция работает только в случае если страница с искомыми данными не менялась с момента последней операции VACUUM.
  • Каскадная репликация — standby сервера теперь тоже могут отправлять журнал транзакций другим узлам.
  • Поддержка типа данных JSON для хранения неструктурированных документов.
  • Добавлены типы данных для диапазонов значений.
  • Серия различных оптимизаций производительности, в том числе:
    • улучшенная работа с блокировками на системах с 32-мя и более ядрами;
    • функция сортировки в памяти ускорена на 25% в некоторых случаях;
    • простаивающий узел СУБД теперь проявляет меньше активности, что полезно при работе в виртуальной машине или при применении в embedded окружении;
    • ускорена работа команды COPY за счет уменьшения операций записи в журнал транзакций и уменьшения количества блокировок;
    • добавлен сбор статистики для массивов, благодаря чему улучшена генерация планов исполнения для запросов с массивами.

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

★★★★★

Последнее исправление: maxcom (всего исправлений: 5)
Ответ на: комментарий от special-k

Позже это оформилось в rubygems.org, rubydoc.info, bundler. Собственно рубисту осталось только писать код.

а потом долго и мучительно его деплоить, ага

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

набрать пять жава кодеров и сильного архитека к ним это один бюджет, а вот собрать pl/sql команду бюджет уже совсем другой. жава+орм не будет чемпионом, потребует больше железяк, но будет как-то работать и если проектировал нормальный архитек, систему будет возможно ее супортить другой командой. понятно что на pl/sql все будет более оптимально, но и бюджет уже другой, отсюда и мода на ОРМы.

А потом этот МЕГАархитектор приходит к админу с претензией: «че за нах? Почему все тормозит? Нужно больше серверов!». И хорошо еще если админ сображает в поддержке бд и, посмотря на этого МЕГАаритектора как на г*вно, и в тоже время с сожалением, может выдать список и статистику по времени исполнения запросов к бд.

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

Откуда у тебя возьмутся реальные нагрузки без реальных данных из реального бизнеса? Или расскажи, как мне RAC на локалхосте замутить

leave ★★★★★
()
Последнее исправление: leave (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

например от Real Application Testing :) кстати да, с жава такой фокус не пройдет

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

Та не, пхп умирает. Точнее на фоне руби пхп умирает. Средства разработки не сравнимы. Gem, Rspec, Bundler, Rdoc, Rack - нет этого в пхп. Руби разрастается с каждым днем: новый интерпретатор, новый фреймворк.. и т.д. А в пхп тупо недостаточно средств разработки. Т.е. я даже не сравниваю сами языки. Короче я бы не надеялся на то, что что-то там работает (толпы сателитов), все куда печальнее, особенно в сколь угодно малой перспективе. Я сделал ставку на эту платформу и буду стараться вытеснить остальные.

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

Расскажи-ка мне, как ты будешь деплоить свой проект на, скажем, пятую шапку, не превращая систему в слаку.

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

1) rvm + unicorn + capistrano + nginx + postgresql (это же тема про постгрес!) 2) ree + capistrano + passenger + postgresql 3) rvm + thin + capistrano + nginx + postgresql 4) ...

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

не превращая систему в слаку

отлично, с заданием не справился. Следующий!

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

«Пятая шапка» - это Redhat 5.x, выходивший в 1998-1999?

RHEL 5, конечно же. Речь же о серьезных корпоративных дистрибутивах.

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

Ненавижу сбербанк. Аж так, что кушать не могу, как ненавижу. Гниды, очередь из одного-двух человек создают.

AVL2 ★★★★★
()
Ответ на: комментарий от special-k

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

p.s. мне один из самых высокооплачиваемых руби-девелоперов Восточной Европы (заслуженно оплачиваемых) прямым текстом заявил: «На сервере должно быть развернуто точно такое же окружение, как на машине разработчика».

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

Расскажи-ка мне, как ты будешь деплоить свой проект на, скажем, пятую шапку, не превращая систему в слаку.

Ну как бы существует EPEL если вы не в курсе. Ruby там представлен, так что слаки можно избежать.

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

Так какую СУБД ботать в купе с Java EE?

от задач зависит.

Если от бд нужно только таблички и запросы к ним, то mySQL и свято блюсти стандарт SQL99. Если в проекте подразумевается серьезная работа с бд (в плане функционала: данные предполагается не только ранить и обновлять, но еще и контроль доступа, логгирование изменений записей и т.д.), то нужно брать сервер бд посерьезней. Для низко-бюджетны проектов, наверное, лучше postgresql, для долговременных корпоративных решений с большим штатом — oracle...

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

Пролистал вакансии на junior java только в паре случаев из 20 есть упоминание об Oracle, в остальных требуется знание теории бд и SQL.

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

Ну правильно. Адекватные вакансии. Нормальный junior не может знать особенности работы с Oracle, иначе бы он уже вырос до senior. А вот теорию бд знать надо, чтобы была возможность вырасти. И опять же не факт что будет работа именно на Oracle. Все-таки инструмент выбирают под проект, а не наоборот.

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

Тогда я думаю заморачиваться изначально с Oracle не стоит. Поставлю тогда Postgresql и потыкаю его из Java. Все таки мне кажется что Oracle крепкий орешек по сравнению с Postgresql в плане количества костылей, дубинок и ножей, которые могут встретиться.

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

ты про MERGE штоле?

UPDATE tbl1 t1 SET fld1 = sq.fld1 FROM (тут_идет_большой_селект) sq WHERE t1.id=sq.id

Saloed (11.09.2012 0:05:06)

rtfm oracle merge + update t1 set t1.col = (select t2.col from t2 where t1.x = t2.x)

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

Из того, с чем сталкивался - поиск правильно версии гема скулайта для руби 1.8.3. Даже по сравнению с cpan'ом оно убого.

leave ★★★★★
()
Ответ на: комментарий от special-k

Вообще, проблема в том, что я не хочу использовать rvm. Я хочу yum install ruby ruby-sqlite3, и чтобы оно работало. Но оно работать не будет, потому что у девелопера на машине версия рубей была не 1.8.3, а 1.8.7, а про обратную совместимость мы не знаем. Поэтому мы изобретаем гемы и прочие рвмы.

Справедливости ради, у питона в этом плане все тоже достаточно тоскливо.

leave ★★★★★
()

Мой дежурный вопрос профи PostgreSQL

Обстоятельства:
При работе 1С-сервера с базой данных potgresql наблюдаются блокировки, которые «разруливаются» использованием «управляемых блокировок» в «конфигурации 1С».
При тех же условиях, но с использование MSSQL «блокировок» не заметно.
Вопросы:
Почему такое наблюдается и можно ли ожидать изменения ситуации? PS Сам я не «адинэсник»

Pronin ★★★★
()
Последнее исправление: Pronin (всего исправлений: 1)
Ответ на: комментарий от leave

Ты говоришь совсем не зная о чем)

Там все элементарно, ставится rvm https://rvm.io/rvm/install/, можно в домашнюю директорию, можно в usr.. Или так же весьма просто ставится ree, обычно в opt. Далее в корне проекта есть Gemfile, в котором прописаны необходимые либы (можно с версиями) http://gembundler.com/

bundle install

И все поставилось, включая зависимости.

Но вообще деплоинг это не то. Вот деплоинг https://github.com/blog/470-deployment-script-spring-cleaning Т.е. обновление приложения на сервере. Т.е. суть не в том чтобы развернуть, а суть в том, чтобы поддерживать. Да и установка программ это уж точно не самое страшное/долгое/сложное.

special-k ★★★★
()
Ответ на: Мой дежурный вопрос профи PostgreSQL от Pronin

При работе 1С-сервера с базой данных potgresql наблюдаются блокировки, которые «разруливаются» использованием «управляемых блокировок» в «конфигурации 1С».

При тех же условиях, но с использование MSSQL «блокировок» не заметно.

К счастью не имел дела с 1С. Но блокировки просто так не возникают. Но я бы на Вашем месте скорее заинтересовался почему в MSSQL их нет.

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

yum install ruby

gem install bundler

mkdir my_project

cd my_project

echo «gem 'sqlite3'» > Gemfile

bundle install

yum install ruby-sqlite3 - вот это ерунда нахрен не нужна.

special-k ★★★★
()
Ответ на: комментарий от leave

Справедливости ради...

лол

Касаемо версий самого руби, лучше разрабатывать и развертывать на одной ветке (1.8/1.9). Но лучше все делать на 1.9 (1.9.3). 1.8.3 - это очень старая версия, на ней лучше не работать.

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

yum install ruby-sqlite3 - вот это ерунда нахрен не нужна.

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

leave ★★★★★
()
Ответ на: Мой дежурный вопрос профи PostgreSQL от Pronin

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

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

Тогда нахрена там СУБД?

А я думал, что субд нужна для хранения/обработки данных, а оказывается - это инструмент для масштабирования... От оно как...

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

Ну, когда 10000 вариантов решения не подходят по.. идейным соображениям остается только снять штаны и бегать)

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

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

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

Можно законсервировать все библиотеки в проекте, и просто перенести файлы.

special-k ★★★★
()
Ответ на: комментарий от leave

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

:) улыбнуло

Не все программы волшебным образом поспевают за выходящими последними версиями библиотек (gem) и это opensource - никто обратной совместимости не обещает. поэтому вполне нормально когда ПО использует свой набор библиотек.
rvm - дает три разных способа установки зависимостей. выбирай любой.

И да, ruby - это не только localhost, но и веб. и здесь rvm показывает все свою мощь.

Не надо равнять всех под свою гребенку - не у всех головы квадратные :)

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

Да не-не, норм, руби подойдет и под его квадратную голову)

Bundler умеет консервировать пакеты. Ничего не придется устанавливать кроме руби - все счастливы. Перед деплоингом консервация и все.

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

Bundler умеет консервировать пакеты. Ничего не придется устанавливать кроме руби - все счастливы. Перед деплоингом консервация и все.

Ъ-ынтерпрайз. А для обновления, наверное, нужен повторный деплой?

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

ога, тут играем, тут не играем, а тут мы рыбу заворачивали. представляю те сачстливые лица разработчиков, которые обнаружили в базе, которую предстоит супортить, часть логики на перле, часть на pl/sql :)

Особенно если они такие молодцы, что не знают ни того, ни другого.

rtvd ★★★★★
()

Отличная новость! Интересно, когда до Sid'а добежит? Дебианщики, есть прогнозы?

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

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

Если разобраться в теме, то никаких проблем не будет.

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

но подозреваю, что мусье не в курсе, что в оракле лицензируеться только редакция, а не версия.

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

Заранее согласен - да, за такой быдлокод надо убивать. Но что делать, если он уже написан и «спущен сверху»?

no-dashi ★★★★★
()
Ответ на: комментарий от leave

Ну тут как раз говорят, что проблема при смене базы данных была, когда ORM не использовался, а в коде непосредственно были прописаны SQL-запросы.

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

Ну так кто ж спорит-то? Да, ОРМ решает проблему миграции на другую СУБД - но какой ценой?

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