LINUX.ORG.RU

Конференция PGConf.Russia 2024 в Петербурге собрала рекордные 1000 специалистов и пользователей Postgres

 ,


2

3

1 октября в Санкт-Петербурге прошла PGConf.СПб 2024 — техническая конференция по открытой СУБД PostgreSQL. Площадка собрала более 1000 постгресистов — разработчиков, администраторов баз данных, IT-менеджеров и других специалистов, работающих с PostgreSQL и СУБД на ее основе.

«PGConf.Russia в Северной столице прошла во второй раз, однако по своим масштабам уже сравнилась с традиционной встречей в Москве. Количество участников увеличилось в 3 раза — это главный признак растущего интереса к постгресу в стране, в частности Санкт-Петербурге. Локальное сообщество стремительно развивается и нуждается в объединении, в чем Postgres Professional видит свою основную задачу», — отметил Иван Панченко, сооснователь и заместитель генерального директора Postgres Professional.

Программа включила 18 докладов от экспертов «ЛУКОЙЛ-Технологии», «Тинькофф Центр Разработки», «Иннотех», «Софтлайн», «Сигма», Maxim Technology и Postgres Professional. Среди тем выступлений: повышение производительности, профилирование функций в PostgreSQL, безопасность СУБД, тестирование отказоустройчивого кластера Postres Pro и многое другое.

По традиции зрители проголосовали за лучшие доклады. Призы получили Андрей Бородин («Необычные возможности системы резервного копирования WAL-G»), Владимир Ситников («Лучшие практики по оптимальной работе базы данных на примере PostgreSQL»), Денис Пантелеенко («Декларирование партицирование»).

Специалисты Postgres Professional провели демонстрацию разработок — Postgres Pro Enterprise BiHA, PPEM и Shardman. Также они представили обновленную версию утилиты pg_probackup, рассказали про аппаратные снапшоты TATLIN.UNIFIED и о том, как работать базами данных на естественном человеческом языке за счет использования алгоритмов ML.

Все желающие прошли независимую сертификацию по PostgreSQL и получили от Postgres Professional единственный в России сертификат, подтверждающий навыки работы с открытой СУБД.

Партнеры конференции — ГК «ФОРС», Yadro, издательство «Питер». Информационную поддержку оказали «Инфостарт», «Марвел-Дистрибуция», Softline, «1С», Treolan, а также группы компаний MONT, «ФОРС».

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



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

А, ну почти понял. Спасибо.

С Оракл никогда не работал.

На древних БД вообще не было такой проблемы в принципе, потому что они и работали сразу на уровне физических дисков. Без файлов. Грубо говоря - от сектора такого-то, до сектора такого это тебе, БД, и делай там что хочешь, как тебе удобнее.

Если БД считает, что ей удобнее для самой себя же и помечать место, как свободное - да и на здоровье. Всё одно никто туда, кроме БД не попадёт. Это я к тому, что лично меня никак не напрягает, что ПГ не отдает в ОС дисковое пространство. Как по мне - и не должен.

Я и сейчас стараюсь так делать, когда есть возможность - отдельный раздел на диске под отдельный tablespace. И ничего там, кроме БД и нет.

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

Ты можешь сам проверить, postgres в docker можно запустить например такой командой:

docker run --rm -it -e POSTGRES_HOST_AUTH_METHOD=trust --name pg postgres:16

держи:

test=# create table t1 (id int);
insert into t1 select generate_series(1, 100000);
CREATE TABLE
INSERT 0 100000

test=# \! du -hs data/base
28M     data/base

test=# delete from t1 where id > 100;
DELETE 99900
test=# select pg_sleep(65);
 pg_sleep 
----------
 
(1 row)

test=# \! du -hs data/base
24M     data/base
Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot
=>create table tab_lor_2 (id int);
insert into tab_lor_2 select generate_series(1, 100000);
CREATE TABLE
INSERT 0 100000
=>SELECT pg_relation_filepath('tab_lor_2');
 pg_relation_filepath 
----------------------
 base/13773/75585
(1 строка)

=>SHOW data_directory;
     data_directory     
------------------------
 /var/lib/postgres/data
(1 строка)

=>\! sudo stat /var/lib/postgres/data/base/13773/75585
  Файл: /var/lib/postgres/data/base/13773/75585
  Размер: 3629056   	Блоков: 7088       Блок В/В: 4096   обычный файл
Устройство: 8/2	Инода: 395051      Ссылки: 1
Доступ: (0600/-rw-------)  Uid: (  961/postgres)   Gid: (  961/postgres)
Доступ:        2024-10-04 10:56:07.209617026 +0700
Модифицирован: 2024-10-04 10:56:07.259616961 +0700
Изменён:       2024-10-04 10:56:07.259616961 +0700
Создан:        2024-10-04 10:56:07.209617026 +0700
=>update tab_lor_2 t set id = t.id + 1;
UPDATE 100000
=>\! sudo stat /var/lib/postgres/data/base/13773/75585
  Файл: /var/lib/postgres/data/base/13773/75585
  Размер: 7249920   	Блоков: 14160      Блок В/В: 4096   обычный файл
Устройство: 8/2	Инода: 395051      Ссылки: 1
Доступ: (0600/-rw-------)  Uid: (  961/postgres)   Gid: (  961/postgres)
Доступ:        2024-10-04 10:56:07.209617026 +0700
Модифицирован: 2024-10-04 10:57:43.099496933 +0700
Изменён:       2024-10-04 10:57:43.099496933 +0700
Создан:        2024-10-04 10:56:07.209617026 +0700
=>select pg_sleep(65);  
 pg_sleep 
----------
 
(1 строка)

=>\! sudo stat /var/lib/postgres/data/base/13773/75585
  Файл: /var/lib/postgres/data/base/13773/75585
  Размер: 7249920   	Блоков: 14160      Блок В/В: 4096   обычный файл
Устройство: 8/2	Инода: 395051      Ссылки: 1
Доступ: (0600/-rw-------)  Uid: (  961/postgres)   Gid: (  961/postgres)
Доступ:        2024-10-04 10:56:07.209617026 +0700
Модифицирован: 2024-10-04 10:57:43.402829903 +0700
Изменён:       2024-10-04 10:57:43.402829903 +0700
Создан:        2024-10-04 10:56:07.209617026 +0700
=>delete from tab_lor_2 where id > 100;
DELETE 99901
=>select pg_sleep(65);
 pg_sleep 
----------
 
(1 строка)

=>\! sudo stat /var/lib/postgres/data/base/13773/75585
  Файл: /var/lib/postgres/data/base/13773/75585
  Размер: 3629056   	Блоков: 7088       Блок В/В: 4096   обычный файл
Устройство: 8/2	Инода: 395051      Ссылки: 1
Доступ: (0600/-rw-------)  Uid: (  961/postgres)   Gid: (  961/postgres)
Доступ:        2024-10-04 10:56:07.209617026 +0700
Модифицирован: 2024-10-04 11:02:41.644987370 +0700
Изменён:       2024-10-04 11:02:41.644987370 +0700
Создан:        2024-10-04 10:56:07.209617026 +0700
=>VACUUM FULL tab_lor_2;
VACUUM
=>SELECT pg_relation_filepath('tab_lor_2');
 pg_relation_filepath 
----------------------
 base/13773/75588
(1 строка)

=>\! sudo stat /var/lib/postgres/data/base/13773/75588
  Файл: /var/lib/postgres/data/base/13773/75588
  Размер: 8192      	Блоков: 16         Блок В/В: 4096   обычный файл
Устройство: 8/2	Инода: 395261      Ссылки: 1
Доступ: (0600/-rw-------)  Uid: (  961/postgres)   Gid: (  961/postgres)
Доступ:        2024-10-04 11:06:21.736417703 +0700
Модифицирован: 2024-10-04 11:06:21.736417703 +0700
Изменён:       2024-10-04 11:06:21.736417703 +0700
Создан:        2024-10-04 11:06:21.736417703 +0700
Toxo2 ★★★★
()
Ответ на: комментарий от Eshkin_kot
postgres=# \! du -hs /var/lib/postgresql/data
39M	/var/lib/postgresql/data
postgres=# create table t1 (id int);
CREATE TABLE
postgres=# insert into t1 select generate_series(1, 10000000);
INSERT 0 10000000
postgres=# \! du -hs /var/lib/postgresql/data
993M	/var/lib/postgresql/data
postgres=# delete from t1 where id > 100;
DELETE 9999900
postgres=# select pg_sleep(65);
 pg_sleep 
----------
 
(1 row)

postgres=# \! du -hs /var/lib/postgresql/data
1.1G	/var/lib/postgresql/data
vbr ★★★★
()
Ответ на: комментарий от vbr

Ты не учёл WAL которые в data/pg_wal, их размер ограничен max_wal_size и они ротируются при checkpoint. Поэтому для оценки освобождения места таблицей удобнее следить за размером файлов таблиц, они хранятся в каталоге data/base.

postgres=# \! du -hs data
1.1G    data
postgres=# \! du -hs data/pg_wal
1.1G    data/pg_wal
postgres=# show max_wal_size ;
 max_wal_size
--------------
 1GB
(1 row)

postgres=# insert into t1 select generate_series(1, 10000000);
INSERT 0 10000000
postgres=# \! du -hs data/base
375M    data/base
postgres=# \! du -hs data/
1.4G    data/

postgres=# delete from t1 where id > 100;
DELETE 9999900
postgres=# select pg_sleep(65);
 pg_sleep 
----------
 
(1 row)

postgres=# \! du -hs data/
1.1G    data/
postgres=# \! du -hs data/base
30M     data/base
postgres=# \! du -hs data/pg_wal
1.1G    data/pg_wal
Eshkin_kot ★★
()
Ответ на: комментарий от ahdenchik

Почему этой штуки нет из коробки сразу, рядом с vacuum?

Разработчики предлагаю свой вариант – vacuum full и, видимо, считают что этого достаточно.

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

Мы обсуждаем вот этот тезис: «Место, которое высвободилось в делите в ОС никогда не уйдёт», так что твой пример с UPDATE тут не в тему.

С UPDATE тоже может освободиться место, когда туплы уедут в начало файла то автовакуум отрежет конец, сделай в транзакции UPDATE несколько раз:

postgres=# delete from tab_lor_2 where id > 100;
DELETE 99901
postgres=# select pg_sleep(65);
 pg_sleep 
----------
 
(1 row)

postgres=# \! stat data/base/5/16384
  File: data/base/5/16384
  Size: 3629056         Blocks: 7088       IO Block: 4096   regular file


postgres=# begin;
BEGIN
postgres=*# with u as (update tab_lor_2 t set id = t.id + 1 returning ctid) select max(ctid) from u \watch
Fri 04 Oct 2024 02:37:38 PM UTC (every 2s)

   max    
----------
 (442,99)
(1 row)

Fri 04 Oct 2024 02:37:40 PM UTC (every 2s)

    max    
-----------
 (442,226)
(1 row)

Fri 04 Oct 2024 02:37:42 PM UTC (every 2s)

   max   
---------
 (0,170)
(1 row)

^C
postgres=*# end;
COMMIT

postgres=# select pg_sleep(65);
 pg_sleep 
----------
 
(1 row)

postgres=# \! stat data/base/5/16384
  File: data/base/5/16384
  Size: 8192            Blocks: 16         IO Block: 4096   regular file
Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

Интересно. Получилось.

У вас на третий раз ctid пришёл мелкий. Я немного иначе делал UPDATE сначала, перед DELETE - у меня на четвертый раз внутри транзакции с UPDATE'ами ctid стал маленький, и после sleep действительно физический файл уменьшился.

Честно говоря - никогда не озадачивался вопросом размера физических файлов.

Больше скажу - я тут под впечатлением от этой темы вчера ночью одну продуктовую БД полностью VACUUM FULL. Даже так - ничего не поменялось глобально. По крайней мере на уровне гигабайтов - никак размер /base не поменялся.

Наверное есть какие-то сценарии реального использования БД, при которых можно съесть всё пространство большими UPDATE'ами. Но я таких не видел. Только вот так, вручную, искусственно - да, вижу, что не отдаёт.

Toxo2 ★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.