• Обзор основных секций конференции PG Day'17 Russia
    0
    Да.
  • 11 вопросов к администраторам баз данных PostgreSQL
    0
    https://martinfowler.com/bliki/TwoHardThings.html
  • 11 вопросов к администраторам баз данных PostgreSQL, часть 2
    0
    Слона-то я и не приметил, когда корректуру делали. Это опечатка транскрипции, приношу извинения. Исправлено.
  • «Когда с базами данных происходит критическая авария, это всегда случается несколько эпически» — Илья Космодемьянский
    0
    Поправил, спасибо :-)
  • «Происшествие с Gitlab — очень хорошая и показательная история», — Алексей Лесовский об администрировании PostgreSQL
    0
    https://pgday.ru/ru/2016/schedule

    Все презентации уже давно опубликованы.
  • «Происшествие с Gitlab — очень хорошая и показательная история», — Алексей Лесовский об администрировании PostgreSQL
    0
    Да, будет)
  • «Происшествие с Gitlab — очень хорошая и показательная история», — Алексей Лесовский об администрировании PostgreSQL
    0
    В прошлом году у нас не было видеосъемок.
  • «Происшествие с Gitlab — очень хорошая и показательная история», — Алексей Лесовский об администрировании PostgreSQL
    0
    Сопроводительные материалы, думаю, выложим. Видео мастер-классов не будет, к сожалению. Только основных дней конференции (доклады).
  • Сервер приложений на pl/pgsql
    0
    приглашаем к нам на конференцию летом, выступить, поделиться опытом :-)
  • Миллионы запросов в секунду: мирная битва между PostgreSQL и MySQL при сегодняшних требованиях к рабочим нагрузкам
    0
    Света, информация о том, что это перевод, и его авторстве указана согласно гайдлайнам хабра с момента публикации статьи. Ссылку плейнтекстом добавил в начало, что ни у кого никаких сомнений не возникало. Перевод мы обсуждали и согласовывали с Настей еще задолго до начала работ по нему.

    Информация о том, что тестирование PG проводил Александр, указана в первом же абзаце перевода вашей статьи, мы здесь ни на грам ничего не изменили. Авторство блогпоста на сайте перконы принадлежит тебе и Насте, что мы и указываем во вступлении. Александр автором статьи на сайте Percona не значится.
  • Эволюция отказоустойчивости в PostgreSQL
    0
    ОК, позиция ясна и аргумент принимается. По вопросу ACID я полностью согласен, по вопросу конформирования стандарту — не совсем, но смысла спорить не вижу :)

    В дальнейшем мы постараемся обращать внимание читателя на подобные огрехи, чтобы провоцировать более вдумчивое осмысление материала и стремление к более обстоятельному изучению рассматриваемых вопросов.
  • Эволюция отказоустойчивости в PostgreSQL
    0
    Понял, значит это я некорректно истолковал ваши комментарии. Внезапно развернувшаяся баталия на тему MySQL vs. PostgreSQL сбила меня с толку.
  • Эволюция отказоустойчивости в PostgreSQL
    0
    Как главный провокатор и распространитель вранья, прокомментирую)

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

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

    Насчет стандарта, в тексте написано, что «PG является SQL-совместимым», а не «PG строго соответствует стандарту SQL». Или я не прав, и эти два выражения надо отождествлять? Какова позиция строгих экспертов Хабра по данному вопросу (by the way, наименование стандарта, SQL:2011, он же ISO/IEC 9075:2011, все-таки упоминается в тексте, пускай и без прямой ссылки)?

    Насколько я могу судить, примерно то же самое пытаются изложить разработчики СУБД в этом разделе документации: https://www.postgresql.org/docs/current/static/features.html

    Я безмерно благодарен за вашу критику, Алексей, в будущем наша команда будет более внимательна в подборе материалов)
  • Эволюция отказоустойчивости в PostgreSQL
    –1
    Собираемся, конечно. Например, в следующей статье будет короткий экскурс в историю становления возможностей репликации в PostgreSQL.

    Заголовок меняться не будет, из песни слов не выкинешь. Это перевод существующей публикации.
  • Эволюция отказоустойчивости в PostgreSQL
    0
    Эта статья — первая из цикла статей, посвященных вопросу. В ней рассматриваются более фундаментальные аспекты архитектуры СУБД. Следующие выпуски будут освещать развитие иных средств из числа доступных пользователям PostgreSQL, не охваченных в текущем выпуске. Всего будет 4 публикации. Но того уровня детализации, который вы ожидаете, точно не предвидится, вынужден разочаровать.
  • Информатика за индексами в Постгресе
    +1
    Мы стараемся подбирать разнообразные материалы. Может, у вас есть на примете хороший? Мы добавим его в свой wish-list и подготовим перевод для читателей Habrahabr!
  • Информатика за индексами в Постгресе
    0
    в тред вызывается hydrobiont )
  • Информатика за индексами в Постгресе
    0
    Не могу дать точного ответа. Знаю лишь, что разработка патча, добавляющего поддержку, велась, но вроде как подзаглохла. В сети имеется некоторое количество всяких workaround'ов на эту тему, использующих drop + create concurrently

    Насколько могу судить из этой дискуссии http://www.sql.ru/forum/941407/reindex-bazy-pod-nagruzkoy, вопрос внедрения фичи не стоит остро и народ, в целом, обходится вышеупомянутым обходным путем.
  • Путешествие запроса Select через внутренности Постгреса
    +1
    Так сложность в том, что вам не хватает выразительности SQL или средств, генерирующих итоговый SQL?

    В первое мне трудно поверить, имея за плечами многолетний опыт разгребания многоэтажных «портянок», в которых порой такую неочевидную ахинею умудряются записать, что просто поражаешься)
  • Путешествие запроса Select через внутренности Постгреса
    0
    Explain analyze более показателен будет в данном случае, я думаю. «Голое» время выполнения мало о чем говорит.
  • Путешествие запроса Select через внутренности Постгреса
    0
    Я думаю что второй вариант, т.к. при наличии индекса у вас будет единичный index scan.

    В первом случае, вам надо сделать index scan для поиска максимального элемента во вложенном запросе, а потом еще index lookup для выборки нужного ряда.
  • Путешествие запроса Select через внутренности Постгреса
    +4
    Для раскрытия темы нужен целый отдельный цикл материалов, думается мне :)
    А вообще, это еще одна затея из разряда как творчески выстрелить себе в ногу. И базе данных тоже заодно. Насколько мне известно, еще никто не придумал решений на тему передачи AST напрямую в СУБД. Дерево тоже ведь надо кодировать в какой-то формат для передачи и на принимающей стороне (внутри СУБД) преобразовывать во внутренние структуры языка Си, которые используются для хранения деревьев. Это тоже накладные расходы. Фактически — обучить базу еще одной формальной грамматике. Полученное AST все равно надо гонять через реврайт и оптимизатор, т.к. не факт что ваше нагенеренное дерево будет высокопроизводительным вариантом.

    В общем, все это — очень большие заморочки с неоднозначным «профитом».
  • Путешествие запроса Select через внутренности Постгреса
    +1
    Ответ кроется в следующем абзаце:
    Как видите, Sort функционирует совсем не так, как Limit. Он сразу загружает все доступные данные из субплана в буфер прежде, чем что-либо возвращать. Затем он сортирует буфер с помощью алгоритма Quicksort и, наконец, возвращает первое отсортированное значение.

    Весь блок данных будет отсортирован, а потом Limit из него уже будет подтягивать нужное количество. Сортировка не является ненужной, т.к. в посгресе таблицы не имеют какого-то неявного по-умолчанию установленного порядка хранения записей.
  • Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 2
    0
    В «подвале» статьи (там где рейтинг и голосование). Аналогичная ссылка есть в статье-переводе первой части.
  • Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1
    0
    Да, это MySQL живет не по понятиям :)
  • Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1
    0
    В order by можно, а вот в группировке, например, — нельзя.

    Я подозреваю, что комментарий возник в связи с тем, что MySQL как раз-таки позволяет оперировать алиасами в group by. Я сам сталкивался с этой печалью имени MySQL-«архитекторов», когда надо было код портировать, в котом трехъэтажная «регулярка» была в виде алиаса условием для group by! Пришлось переписывать, конечно. В тупую Посгрес не дает таки вещи переносить, и это, в общем-то, хорошо.
  • Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1
    +2
    Здесь вы правы. Но такой продукт будет либо очень «средний по больнице», и в процессе эксплуатации все равно придется лезть в недра или звать сантехников, которые умеют в них ковыряться) Грабли на нагрузках и объемах неизбежно повылазят уже после внедрения. А до тех пор — какая-то усредненная функциональность, более-менее решаемая ORM'ом с сомнительной степенью эффективности.
  • Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1
    +2
    Вот вы знаете, может, я просто не сталкивался с подобными проектами, но я очень подозрительно отношусь к продукту, которому надо рутинно менять одно хранилище на другое. Я имею ввиду какой-то сервис, который предоставляет услугу, считает деньги за эту услугу, разработчки каждый день решают «хотелки» от коммерции разной степени адекватности и т.д.
  • Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1
    0
    Поясните, свой вопрос, пожалуйста :) Про индексы можете почитать переводы наших статей про explain, там частично эта тема затрагивается. Про большие таблицы — на крупных инсталляциях проблемы с их обслуживанием могут возникнуть, зависит от совокупной ситуации на вашей базе (объем и количество таблиц, интенсивность записи и т.д.), но это тема для отдельной статьи про эксплуатацию.
  • Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1
    +4
    Это может показаться ответом наивного фанбоя, но я вот посидел честно и подумал о своем опыте интенсивной работы с ПГ в крупных проектах и не могу вспомнить чего-то такого масштабно плохого, от чего были большие боли и страдания, по сравнению с моим опытом от работы с MySQL и NoSQL решениями. Мелких придирок могу накидать, выше коллеги, например, писали про невозможность использовать alias сложносочиненного выражения в group by. Но я это считаю больше решением из разряда bad design. Такие вещи правильно отцепить в CTE / подзапрос.

    Хотя мысль, конечно, любопытная, написать подобную статью и покопаться в шкафу со скелетами.

    Вещи из разряда «GUI кривой» я не считаю недостатком базы и всех программистов приучаю работать с psql.
  • Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1
    +1
    В нашем блоге есть переводы хороших статьей Депеша про Explain! :)
  • Объясняя необъяснимое. Часть 4
    0
    У нас с саппортом Хабра, к сожалению, вышло небольшое несогласие о том, что является маркетинговым контентом в статье :) Поэтому пришлось внести корректировки и опубликовать статью повторно. К тому времени она уже уехало очень далеко в новостных лентах пользователей, поскольку Хабр осуществляет повторную публикацию с датой исходной.
  • Объясняя необъяснимое. Часть 2
    +2
    Да, analyze полезно делать после заполнения какой-то таблицы или большого удаления, поскольку обновляется статистика для планировщика. Очень полезный прием, когда надо какую-то статистику обновить, например. Берем сырые данные, кладем в temporary таблицу с нужным партиционированием, строим индексы, делаем analyze и работаем с данными.
  • Объясняя необъяснимое
    0
    Я своих собеседников никогда не считаю по-умолчанию тупыми или невежественными. Ровно поэтому, когда коллега выше упомянул ссылку на документацию, я счел, что вы, являясь, наверняка, человеком образованным и сообразительным, найдете для себя там ответ.

    Именно поэтому я оставил свой комментарий, рассчитывая на то, что вы его оцените именно с позиции человека, имеющего опыт в отрасли. Кручение «гаек» планировщика является очень опасным приемом, который в неумелых руках приводит к тому, что ранее работавшие запросы внезапно начинают дико тормозить, когда меняется статистика, собираемая базой данных, и, как следствие, выстраиваемый план запроса. То, что раньше было неэффективным и столь неэлегантным образом отключалось, внезапно стало жизненноважным для хорошей производительности.

    Мой комментарий никак не касался ваших умственных способностей, профессионального опыта или стажа пребывания на Habrahabr.
  • Объясняя необъяснимое
    0
    Я рассчитываю на совокупность тегов и самого текста в теле статьи. Уходить от авторского названия не очень хочется.
  • Объясняя необъяснимое
    0
    Интересно! Спасибо за ссылку.
  • Объясняя необъяснимое
    0
    set enable_indexscan = off;
    set enable_bitmapscan = off;
  • Объясняя необъяснимое
    0
    Вы какие-то странные выводы из сказанного делаете, но дело ваше.
  • Объясняя необъяснимое
    0
    Да, это очень достойная штука.
  • Объясняя необъяснимое
    0
    Да, автор не уточнил, какие именно «гайки» он крутил, что даже очень хорошо, на мой взгляд :) Неумелое кручение этих гаек может привести к поиску подземного стука потом в приложении.