![[syndicated profile]](https://www.dreamwidth.org/img/silk/identity/feed.png){kind=small}
temalebedev_feedЛюбой напиток в стекле вкуснее, чем в пластике.
Тут даже спорить не о чем.
И в стеклянной бутылке любой напиток от воды до вина вкуснее, и в пластиковой бутылке или пластиковом стаканчике любой напиток как говно.
pavel_kosenko_lj_feedpavel_kosenko_lj_feedtemalebedev_feedЯ никогда не знаю имен музыкантов, исполнителей, спортсменов и пр. Даже если бы узнал, то забыл бы через минуту.
Вот слушаю всю жизнь "Аквариум", а как зовут барабанщика или скрипача - понятия не имею. Я даже не знаю, как зовут солистов в "Пинк Флойде" и "Даер Стрейтсе".
Все спортивные команды я знаю в лучшем случае по названиям - "Динамо" или "Манчестер Юнайтед". А кто там играет - ваще не ебу.
В кино я еще туда-сюда помню, кто играет самого главного героя, но только если я посмотрел с ним уже 20 фильмов. Иногда могу вспомнить - а, этот, который Джесси Пинкмана играл! - но как его зовут не имею понятия.
Даже на переговорах (к своему стыду) я моментально забываю, с кем только что познакомился. Впрочем, на эту тему у меня есть лайфхак - я раскладываю визитки так, чтобы передо мной была маленькая копия рассадки. И подглядываю на расклад - да, Михаил, это очень интересная задача. Но вот если Михаил пересядет, а я не успею визитку переложить, то будет жопа, конечно.
planet_pgsql_short_feed
© Laurenz Albe 2025
While I sometimes write about real-life problems I encounter in consulting sessions (see this example), I admit that curiosity and the desire to play are the motivation for many of my articles (like this one). So I am glad that a friend of mine, whose job as a DBA puts him on the front line every day, offered to let me quote from his (unreleased) memoirs. Finally, this is material that I hope will connect with all the hard-working souls out there! My friend insists on anonymity, hence the “bastard DBA from hell” in the title.
I like being a DBA. The only problem are the people using the databases.
A week ago I get a call from accounting. The guy sounds like I stole his sandwich, “We get deadlocks all the time.”
“Well, don't do it then.”, I tell him. I should have known that this kind of person wouldn't listen to good advice.
“It's your Postgre system that gives me these deadlock errors. So you fix them”.
“As you wish.”. >clickety click< “Ok, you shouldn't get any more deadlock errors now.”
He mumbles something and hangs up. It didn't sound like “thank you”. That's fine with me. After all, I set his lock_timeout to 500.
Yeaterday the guy from accounting called me again, in that accusing, complaining tone, “Our disk is 95% full.”
“I know, I got an alert from the monitoring system. Actually, I sent you guys an e-mail about it. 10 days ago.”
“Can't you fix that?”
“Do you want me to extend the file system?”
“We have no more data in there than before. So why do we need a bigger disk?”
I tell him “hang on” and log into their system. >clickety click<
“Well, you got a 350GB table there that's taking up all the space. But it's 99% dead data... Did you create that prepared transaction a month ago and never commit it?” >clickety click< “There, gone now. Just run a VACUUM (FULL) on the table and you'll be good.”
I thought I was r
[...]pavel_kosenko_lj_feedtemalebedev_feedРаньше был один автор-творец и много слушателей-читателей.
Потом постепенно читатели-зрители начали не просто в одиночку переваривать свои эмоции и чувства, а собираться в группы. И стали отбирать у авторов право на интерпретацию. Появился фанфик.
При этом до сих пор автор напоминает царя, а читатели и зрители - его подданных. Но все меняется.
И главное изменение - появление многосюжетности. Сегодня зритель может сам предложить свой вариант.
А завтра любой зритель - соавтор! Кто этого изменения не примет, тот не сможет быть автором в будущем. Это самое важное изменение отношений между автором и зрителем за последние 1000 лет. Мир катится именно сюда.
planet_pgsql_short_feedplanet_pgsql_short_feedMaking GROUP BY a bit easier to use is in my experience among the top three requested features in SQL.
Like, if you do
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
CREATE TABLE t1 (a int, b int, ...);
SELECT a, avg(b) FROM t1 GROUP BY a;
the column list in the GROUP BY clause doesn’t convey much information. Of course you wanted to group by a, there is no other reasonable alternative. You can’t not group by a because that would be an error, and you can’t group by things besides a, because there is nothing else in the select list other than the aggregate.
The problem gets worse if you have a longer select list or complicated expressions, because you need to repeat these in the GROUP BY clause and carefully keep them updated if you change something. (Or you can try to work around this by using subqueries.) Could be easier!
A number of implementations1234 have adopted the syntax GROUP BY ALL to simplify this.
SELECT a, avg(b) FROM t1 GROUP BY ALL;
The SQL standard working group discussed this feature informally at the June 2025 meeting, and there was consensus about going forward with it.
At the September 2025 meeting, a formal change proposal was brought forward and accepted. (So, technically, it’s just a working draft right now, and it won’t be final until the standard is released.)
The formal meaning of GROUP BY ALL is that it expands to a list of the elements of the select list that do not contain aggregate functions. So in
SELECT a, avg(b) FROM t1 GROUP BY ALL;
a does not contain an aggregate function, but avg(b) does, so GROUP BY ALL resolves to GROUP BY a, as expected.
This doesn’t completely remove the need for explicit GROUP BY lists. Consider a more complicated case like
CREATE TABLE t1 (a int, b int, c int, d int, ...);
SELECT a, avg(b) + c + d FROM t1 GROUP BY ALL;
Here, a does not contain an aggregate function, but avg(b) + c + d does contain an aggregate function, so the query resolves to
SELECT a, avg(b) + c + d FROM t1 GROUP BY a;
But that is not valid, because you need t
[...]temalebedev_feedПиздец, самая большая тупость на свете - это жрать Л-карнитин, думая, что он помогает в спортивных достижениях и в качалке.
Л-карнитин никак не помогает. От него нет никакого толка, кроме того, что под разными этикетками он приносит доход разводителям лохов.
planet_pgsql_short_feedPostgreSQL 18 brings a couple of performance related features to the table which will help applications to run more efficiently, providing a better and more enjoyable user experience. One of those performance features is called “skip scans”. Most of you might ask yourself at this point: Wow, sounds cool, but what is a skip scan? The purpose of this post is to shed some light and explain how this works, what it does and most importantly: How one can benefit from this feature in real life.
To understand what a skip scan does, we first need to create some test data that is suitable for the challenge. Here is a classical example which can help to illustrate the topic nicely:
test=> CREATE UNLOGGED TABLE tab (
frequent integer,
rare integer
);
CREATE TABLE
test=> INSERT INTO tab
SELECT i / 100000, i % 100000
FROM generate_series(0, 999999) AS i;
INSERT 0 1000000
test=> VACUUM (ANALYZE) tab;
VACUUM
test=> CREATE INDEX ON tab (frequent, rare);
CREATE INDEX
We have created a table with just two columns. The first column contains just a handful of different values (so most of them are identical, making the index struggle). The second column contains many more different values. The challenge now is: How can we make use of the combined index we created efficiently?
In general, a btree in PostgreSQL can be seen as a sophisticated version of a sorted list. This is also true if we are dealing with a composite index. In our case, a subset of the index might look like this:
A composite index is sorted by “frequent” and “rare” (just like a phone book). Of course, there are various sophistications such as deduplication and a lot more, but the basic principle remains the same: We are dealing with a list sorted by those columns (or expressions) in the index. If you want to learn more about indexing, consider the following posts:
[...]planet_pgsql_short_feed
Your API is slowing down. You check your database and find 42 indexes on your users table. Which ones can you safely drop? How much performance are they costing you? Let's look at what actually happens in Postgres when you have too many indexes.
If you're a backend or full-stack engineer, you probably don't want to become an indexing expert — you just want your API fast and stable, without babysitting pg_stat_user_indexes.
Index maintenance includes multiple activities: dropping unused indexes, dropping redundant indexes, and rebuilding indexes on a regular basis to get rid of index bloat (and of course, keeping autovacuum well tuned).
There are many reasons why we need to keep our index set lean, and some of them are tricky.
I keep collecting these ideas over years. Here's the current list (more to come):
As for index bloat, reasons 3-6 apply to bloated indexes as well. Plus, if an index is extremely bloated (e.g., 90%+, or >10x the optimal size, index scan latencies suffer. Postgres B-tree implementation lacks merge operations — once a page splits, those pages never merge back together even after deletions. Over time, this leads to increasing fragmentation and bloat. Deduplication in PG13+ helps compress duplicate keys and bottom-up deletion in PG14+ reduces bloat by removing dead tuples more aggressively during insertions. However, these features don't address structural degradation from page splits. Regular monitoring and rebuilding of bloated indexes remains essential maintenance work.
Let's examine each item from the list, studying Postgres source code (here, it's Postgre
[...]temalebedev_feedВ жизни нужны усложнения, чтобы когда их уберешь потом - стало легче.
Скажем, когда я плаваю, мне тренер дает в руки гантели, а к жопе прицепляет парашут. Гантели тянут руки на дно, а парашут не дает двигаться. Проплывешь так пару бассейнов, заебешься, а потом все оставляешь и плывешь уже без всего. И сразу становится так классно, быстро и охуенно!
Об этом же старый еврейский анекдот про раввина и козу.
Мораль простая: научись ценить то, что есть, потому что бывает и хуже.
hardsign_lj_feedПара статей про Highload внезапно словила такой хайп, что количество полученных комментариев в этом блоге превысило количество написанных, с чем себя и поздравляю. Ну а теперь немножко про сами технологии.
Послушал на конференции несколько докладов, суть которых сводилась к следующему: есть вот такая задача, PostgreSQL для неё не очень подходит, но под наши специфические требования нормальной платформы нет. Поэтому мы до самого упора выкрутили все настройки влево (или вправо), купили железо помощнее и всё-таки запустили свой велосипед.
Во всех этих случаях есть другие платформы, которые подошли бы для решения задачи гораздо лучше. Но разработчики то ли не знают о них, то ли знают, но боятся попробовать. Зато не стесняются сделать доклад на публику.
Привычный инструмент — всегда лучший, даже если он совсем не годится для решения задачи. «Имеющему молоток все проблемы представляются гвоздями» — не вчера сказано. Но чем кажется проблема имеющему PostgreSQL, для меня загадка...
planet_pgsql_short_feedThis quarter's round of minor releases are expected later this week. Note this will be the last minor release for PostgreSQL 13 .
PostgreSQL 19 changes this week logging wal_fpi_bytes value shown in log entries for VACUUM and ANALYZE operations logical replication support for sequence synchronization added pgbench option --continue-on-error added pg_stat_subscription_stats column seq_sync_error_count added psql \pset variables display_true and display_false added SET NULL now accepted for specifying an empty list WAIT FOR SQL command added PostgreSQL 18 articles PostgreSQL 18 enables data‑checksums by default (2025-11-03) - Josef Machytka / credativ What do the new Index Searches lines in EXPLAIN mean? (2025-10-10) - Michael Christofides / pgMustardtemalebedev_feedВопрос на миллион: почему банки не дают закрыть депозит раньше срока без потери накапанного, если ключевая ставка снизилась?
Это же тупо выгодно банку будет. Иначе он продолжит платить процент, который будет выше текущей ставки ЦБ, какая в этом бизнес-логика?
Типа, банк должен быть принципиальным до конца в любых ситуациях?
planet_pgsql_short_feedNew podcast episode published by Claire Giordano from her series “Talking Postgres” : Building a dev experience for Postgres in VS Code with Rob Emanuele
Blog posts
Ellyne Phneah Key takeaways from the PostgreSQL & AI Summit: RAG, agents, and tuning
Claire Giordano Postgres Trip Summary from PGConf EU 2025
hardsign_lj_feedНаписал вчера о встрече с Максутом Шадаевым и, признаться, реакция комментаторов меня немало озадачила. Такое ощущение, что комментаторы воспринимают ковровые блокировки как борьбу хороших парней с плохими парнями. Первые пекутся о народном благе, а вторые думают, как бы этот самый народ по-всякому курощать. И ведь это не зумеры-тиктокеры, а вполне взрослые состоявшиеся люди... Что ж, поработаю в этот воскресный вечер капитаном Очевидность.
Мы наблюдаем не борьбу парней, а борьбу систем.
Первая система — Youtube и иже с ним. Тоже те ещё зайки: сносят без предупреждения русскоязычные каналы с миллионами подписчиков, а на просьбы снести вредоносный контент (оставим за скобками его реальную вредоносность) не реагируют. Более того, штаб-квартира этой конторы находится под юрисдикцией государства, с которым мы по факту находимся в состоянии войны (хорошо, что холодной). Очевидно, они не могут игнорировать не только писаные законы этого государства, но и всякие намёки, пожелания, звонки и прочие неформальные указания. В конце концов, нам не так важно, является ли снос каналов тайным приказом ЦРУ или инициативой на местах, важен факт сноса. Уверен, что удовлетворённость российских пользователей Youtube при принятии решения не то что не является приоритетом, а вообще не рассматривается как аргумент.
Вторая система — наше государство. Система огромная и неповоротливая, большие системы — все именно такие.
Нет, конечно, бывают стартапы — быстрые и эффективные. Но жить в государстве-стартапе обычно не очень комфортно, и импортозамещение, искусственный интеллект и прочая цифровизация в таком государстве из актуальных проблем быстро переходят в разряд ностальгии типа «как же хорошо мы плохо жили». Одно из лучших государств-стартапов — республика Фиуме, остальные хуже. Да что я рассказываю, любой русский человек очень хорошо знаком с историей одного такого стартапа...
Так вот, государство реагирует, как может. А может оно вот так.
У государства много голов, куда там Лернейской Гидре, и каждая решает какую-то свою задачу, не особо задумываясь, насколько решение этой задачи противоречит задаче соседней головы. Минцифры и Роскомнадзор — разные головы. Благосостояние граждан каждая голова может принимать во внимание, но лишь постольку, поскольку оно не противоречит её основной задаче.
И вот одна голова решает повернуться к людям лицом, а не тем местом, которым обычно. И что она видит?
— Да вы все там...
— Да я вас...
— Да там вообще не может быть...
К слову, я сам занимаюсь разработкой импортозамещённого платформенного софта. Правда, не с 2022 года, а примерно с 2014. И мне очень важно и нужно (и конечно, приятно) знать, что мы все дармоеды, хапуги и рукожопы. И как докладчику на Highload++ и других конференциях мне необходимо услышать, что содержимое тамошних докладов — ложь, [censored: враньё] и провокация. Спасибо тем, кто написал это в комментариях.
В общем, если бы я был министром, а встреча состоялась бы в комментариях к вчерашней записи, я бы сказал по результатам: ну и чёрт с вами, живите, как хотите.
К счастью, в зале было сказано совсем другое. И кстати, один из спрашивающих указал Максуту Игоревичу, что интересы Роскомнадзора «держать и не пущать» входят в противоречие с интересами Минцифры «обеспечить развитие», и министр пообещал устроить встречу с РКН — пусть в закрытом, но достаточно широком составе. Это — конструктив.
Разумеется, каждый волен решать, пытаться как-то решить проблемы, когда есть такая возможность, или вместо этого плеваться жёваным говном. Мне милее первый путь. Может, эффекта не будет, но я хотя бы попытаюсь. Тем более, что Минцифры само идёт на контакт.
P. S. доступ к записи ограничен, но постараюсь в ближайшее время скинуть в личку ролик тем, кому это нужно и интересно.
temalebedev_feedПиздец, больше всего на свете ненавижу клей, которым дисконтные карты приклеивают к буклетам.
Клей с дисконтных карт напоминает козявку, которую я не доставал из своего носа.
Не понимаю, почему не придумают чего-то более приятного для держания дисконтных карт.
temalebedev_feed - Вкус напиткаpavel_kosenko_lj_feed - Еда. Записная книжка рецептовpavel_kosenko_lj_feed - Винегретtemalebedev_feed - Именаplanet_pgsql_short_feed - Laurenz Albe: The bastard DBA from helltemalebedev_feed - № 669 Арбузы в Антарктиде / Мясорубка Зеленского / Запрет вейповpavel_kosenko_lj_feed - Говядина, тушеная с овощами, тархуном и грушейtemalebedev_feed - Куда катится этот мирplanet_pgsql_short_feed - Hubert 'depesz' Lubaczewski: Waiting for PostgreSQL 19 – Sequence synchronization in logical replicaplanet_pgsql_short_feed - Peter Eisentraut: Waiting for SQL:202y: GROUP BY ALLtemalebedev_feed - Л-карнитинplanet_pgsql_short_feed - Hans-Juergen Schoenig: PostgreSQL 18: More performance with index skip scansplanet_pgsql_short_feed - Nikolay Samokhvalov: #PostgresMarathon 2-013: Why keep your index set leantemalebedev_feed - Усложненияhardsign_lj_feed - О привычных технологияхplanet_pgsql_short_feed - Ian Barwick: PgPedia Week, 2025-11-09temalebedev_feed - Банки и депозитыplanet_pgsql_short_feed - Cornelia Biacsics: Contributions for week 45, 2025hardsign_lj_feed - О системеtemalebedev_feed - Дисконтные карты