По производительности есть вопрос.

Проверка значения shared_buffer
testdb=# SHOW shared_buffers;
shared_buffers
----------------
128MB
(1 row)

Примечание: Будьте осторожны, так как некоторые ядра не поддерживают большее значение, особенно в Windows.

Сколько реально можно поставить? Linux, kernel 3.x, RAM - 64G. 16G сожно будет?

Проверка значения shared_buffer
testdb=# SHOW shared_buffers;
shared_buffers
----------------
128MB
(1 row)

Примечание: Будьте осторожны, так как некоторые ядра не поддерживают большее значение, особенно в Windows.

Реально можно поставить столько, чтобы hot read set в него влезал.
И вообще, стоит прочитать документацию про tuning PostgreSQL и OS.
Начиная с http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server и https://www.postgresql.org/docs/current/kernel-resources.html , например.

sudo su - postgres -c 'DATE=`date +%Y-%m-%d-%H:%M:%S` && pg_dump ergdb > /backup/ergdb_$DATE.backup’

выходит This account is currently not available.
как быть ?
а если делаю так то тупо стоит

PGPASSWORD="__" pg_dump --host localhost --port 5432 --username "__" --role "__" --no-password --format custom --blobs --encoding UTF-8 --verbose --file "/home/ssgpo/backups/erg.backup" "__"

нашёл странное поведение, похоже на баг планировщика
есть табличка - выборка из pg_timezone_names, name - PK
Запросы почти равнозначны, за исключением того, что второй возвращает json:

select name from timezones
order by utc_offset

select json_agg(name order by utc_offset) from timezones

При этом их планы:

QUERY PLAN
Index Scan using tz on timezones  (cost=0.27..16.27 rows=433 width=32) (actual time=0.107..0.375 rows=433 loops=1)
  Buffers: shared hit=8
Planning Time: 0.194 ms
Execution Time: 0.464 ms

QUERY PLAN
Aggregate  (cost=10000000010.42..10000000010.43 rows=1 width=32) (actual time=0.834..0.835 rows=1 loops=1)
  Buffers: shared hit=5
  ->  Seq Scan on timezones  (cost=10000000000.00..10000000009.33 rows=433 width=32) (actual time=0.030..0.119 rows=433 loops=1)
        Buffers: shared hit=5
Planning Time: 0.191 ms
Execution Time: 0.930 ms

огромный cost и сортировка игнорируется (правда в таблице они и так в отсортированном порядке)
Как это понимать?
Версия 12.2

судя по костам, кто-то игрался с enable_* параметрами

tz - индекс по колонке utc_offset

я JIT отключал потому что он мне другой запрос сильно портил, опять же из-за неправильных костов
больше ничего такого

такой кост у SeqScan говорит, что enable_seqscan=off у вас, но другого варианта исполнения запроса нет

учитывая, что Buffers: shared hit=5 при SeqScan и Buffers: shared hit=8 в первом запросе — SeqScan выглядит лучше

хм. Действительно, выше в этой консоли тестил...
Получается постгрес как-то понимает что индекс не нужен потому что всё и так упорядочено?
В запросе без json индекс всё же используется

Нет. Агрегаты с ORDER BY сортируют свои входные данные "самостоятельно", этой сортировки в планах не видно.

о как. Буду знать, спасибо)

Здравствуйте! Подскажите, как организовать дифференциальное резервное копирование только измененных данных. Только на Postgresql 9.6

некоторые приложения для бекапов умеют такое
допустим wal-g

Спасибо. А bacula не умеет?

бакула там только как триггер и хранилище бекапов должна действовать, как я помню бекапится постгря там другими тулзами

На правах рекламы:
https://github.com/postgrespro/pg_probackup

народ, если бд создана с "LC_COLLATE = C"
возможно ли заменить collate для конкретной таблицы конкретного атрибута на "en_US" ?

Это аналог пг-арман?

Форк