gihyo.jpPostgreSQLの並列処理とJIT ――実行計画からひも解く処理特性と導入効果
https://gihyo.jp/article/2026/03/postgresql-parallel-jit?utm_source=feed
#gihyo #技術評論社 #gihyo_jp #Software_Design #PostgreSQL_18 #並列処理 #JIT #MVCC
HabrFastAPI на AMD FX-8320: оптимизация P99 latency в условиях ограниченных ресурсов (HDD, DDR3)
В 2026 году асинхронный Python уже никого не удивляет. Мы привыкли к автоскейлингу в облаках, но что делать, если ваш бюджет на инфраструктуру равен нулю, а в распоряжении есть только «печка» из 2012 года? Рассказываю про личный опыт выжимания максимума из FastAPI на AMD FX-8320: от тюнинга ядра Linux и PostgreSQL до миграции на Ed25519 и использования Rust-сервера Granian.
https://habr.com/ru/articles/1002312/
#FastAPI #Granian #AMD_FX8320 #PostgreSQL_18 #Angie #Valkey #P99 #Linux_Tuning
Postgres Pro Enterprise 18: встроенный in-memory кеш и новые горизонты отказоустойчивости
Асинхронный ввод-вывод, ML-оптимизация планов запросов и встроенный пулинг соединений — ключевые особенности новой Postgres Pro Enterprise 18. Релиз объединил возможности ванильного ядра PostgreSQL 18 и Enterprise-инструменты для работы с большими данными. Расскажем про технические детали, новые стратегии сканирования индексов и механизмы масштабирования записи.
https://habr.com/ru/companies/postgrespro/articles/989394/
#postgres_pro_enterprise #postgres_pro_enterprise_18 #postgresql_18 #postgres #релиз #postgres_professional
[Перевод] Более глубокий взгляд на старый UUIDv4 и новый UUIDv7 в PostgreSQL 18
UUIDv4 как первичный ключ в PostgreSQL обычно ругают за «случайность» — но за этим словом прячется конкретная физика: сплиты страниц B-дерева, рыхлый листовой уровень, фрагментация и лишний случайный I/O при чтении. В PostgreSQL 18 появился UUIDv7 — и это хороший повод посмотреть на проблему не на уровне вкусов, а на уровне того, как реально устроены индекс и heap: от корреляции и ctid до статистики страниц и плотности листьев.
https://habr.com/ru/companies/otus/articles/979212/
#UUIDv4 #postgresql #UUIDv7 #PostgreSQL_18 #первичный_ключ #Btree_индекс #фрагментация_индекса #локальность_данных
Carl von LesquereuxAparentemente se les fue la olla a los de #Fedora con la actualización a #Fedora43 si se tiene instalado #PostgreSQL.
#Fedora42 trae #PostgreSQL_16, mientras que la v43 trae #PostgreSQL_18. Entonces, al actualizar el SO, todo peta, porque no puedes usar `postgresql-setup --upgrade`, ya que tu cluster es v16 y el upgrade sólo sirve de v17 a v18.
Más info y solución, aquí: https://discussion.fedoraproject.org/t/cant-upgrade-postgres-after-f42-f43/171071/4
Can't upgrade postgres after f42->f43
Unfortunately there are a few issues. Fedora does not allow to install multiple versions of Postgres, which makes this a bit more complicated. Luckily the postgres-upgrade packages include the “old” (n-1) binaries. There are a few options available how to do the upgrade. I am trying to find a nice solution that is the least error prone. e.g. if you are not careful you might end up with things like old cluster does not use data checksums but the new one does. An upgrade always replaces your c...
[Перевод] Эвристика: OR в SQL — это дорого
Один запрос выполняется 100 мс, другой — меньше 1 мс. Оба делают одно и то же, но второй написан на странном, почти алхимическом SQL. В чём подвох? Первый использует OR , а второй — хитрую комбинацию AND . Этот перевод — расследование того, почему условие OR так дорого обходится вашей базе данных, и практическое руководство по тому, как проектировать схемы, чтобы избежать этой ловушки производительности.
https://habr.com/ru/companies/postgrespro/articles/953506/
#оптимизация_запросов #планировщик_запросов #индексы #базы_данных #postgresql #postgres #postgresql_17 #postgresql_18
