Postgresso 21

Кстати, а вы эту нашу статью видели? (спрашиваю на всякий случай)
habr.com/ru/company/postgrespro/blog/412605

Postgresso 21

Да, MERGE сверхактивно продвигал Саймон Риггс, вплоть до конфликта. После того, как закоммитить не вышло, всё, кажется увяло. Ну а zheap — надеюсь, что потихоньку делают, но точно не так шустро, как многие ждали.

Postgresso 21

too эмоционально. Но ок, пусть будет здесь и такое мнение :)

Parallelism in PostgreSQL: treatment of trees and conscience

Спасибо, что напомнили! Дам ссылку сейчас в тексте. И скажу сразу, что она вот где: habr.com/ru/company/postgrespro/blog/423685

JSONPath in PostgreSQL: committing patches and selecting apartments

Спасибо! Рад, что пригодилось!

Секционирование в PostgreSQL 10 и не только

Рад, что понравилось!

JSONPath in PostgreSQL: committing patches and selecting apartments

он самый :) это же по поводу feature freeze :)

Postgresso 20

спасибо и вам. тогда сейчас проадейчу.

Postgresso 18

Спасибо! Хорошо, что вы это делаете. Ждём с интересом.
А я еще выложу выжимки из некоторых докладов немного попозже.

Postgresso 18

на здоровье :)

PG12: Дюжина патчей от Postgres Professional

Одна из причин того, что не в первом ряду: всё-таки это потенциальные возможности. Сделать с этим пока мало что можно.

PG12: Дюжина патчей от Postgres Professional

Да, были такие мысли. Возможно, вы и правы.
PS. спасибо за «спасибо» )

Дайджест новостей из мира PostgreSQL. Выпуск №17

Да, из принципиальных вещей по партициям там, кажется, всё уже должно работать. Разве что в некоторых местах не так быстро, как хочется разработчикам и пользователям.

Дайджест новостей из мира PostgreSQL. Выпуск №16

[болел, поэтому молчал]
Да, будет дальше развиваться и поддерживаться. И для 1С-версий будет отдельный сайт. Но он еще не готов.

Дайджест новостей из мира PostgreSQL. Выпуск №16

«Все собранные версии как и раньше доступны в репозитории. Новые версии будут появляться только после проведения тестирования их работы с платформой 1С»

Игра в прятки с оптимизатором. Гейм овер, это CTE PostgreSQL 12

Во всяком случае у

CREATE TABLE akina_table AS SELECT x, x AS y FROM generate_series(1,10) AS x;
EXPLAIN ANALYZE WITH
     cte1 AS (NOT MATERIALIZED) (SELECT * FROM akina_table WHERE x<2),
     cte2 AS (DELETE FROM akina_table WHERE y>9)
INSERT INTO akina_table SELECT * FROM cte1;

план одинаковый с и без NOT MATERIALIZED. Я ответил?

Игра в прятки с оптимизатором. Гейм овер, это CTE PostgreSQL 12

Проблема именно в «барьере» для оптимизатора. Дело не в том, попало что-то в кэш или нет: это все равно быстро, так как по индексу. В случае, когда материализация НЕ запрещена, поиск секскан, оптимизатор не может воспользоваться индексом. Он НЕ МОЖЕТ объединить условия, так как одно «внутри», а другое «снаружи». Он (по существующему дизайну) обязан сначала исполнить (точнее, исполняет, конечно, экзекьютер) внутренне, подлежащее материализации, а о внешнем он «узнает» только после этого.

Игра в прятки с оптимизатором. Гейм овер, это CTE PostgreSQL 12

да, конечно! спасибо, поправил.

Что заморозили на feature freeze 2019. Часть I. JSONPath

да, поправил. спасибо!

Дайджест новостей из мира PostgreSQL. Выпуск №15

Коллеги в большинстве своем считают, что «Да, можно, но после тщательного тестирования».