В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pgsql – PostgreSQL

4841 membersпожаловаться на группу
2020 July 27

YS

Yaroslav Schekin in pgsql – PostgreSQL
Разница в оценках тут очень существенная (38553.57 vs 134841.33).
И вот ещё:
 ->  Parallel Index Scan using bs_incoming_2020_07_demodulation_time_idx on bs_incoming_2020_07  (cost=0.43..129820.68 rows=381200 width=4) (actual time=0.024..8.244 rows=11646 loops=3)
       Index Cond: (demodulation_time >= '2020-07-23 16:54:37.84+00'::timestamp with time zone)
       Buffers: shared hit=21124

 ->  Parallel Index Scan using bs_incoming_2020_07_demodulation_time_idx on bs_incoming_2020_07  (cost=0.43..130188.54 rows=382109 width=4) (actual time=0.130..1387.630 rows=203675 loops=3)
       Index Cond: (demodulation_time >= '2020-07-23 16:54:37.84+00'::timestamp with time zone)
       Buffers: shared hit=338478 read=4

То же условие, но теперь actual rows стало гораздо больше. Данные добавляются, а autovacuum не успевает?

В общем, тут можно пробовать либо оценки улучшать (проблема из-за них, как минимум), либо начать с tuning (хотя и "железо" очень слабое, конечно :( ).
Если делать первое, можно попробовать CREATE STATISTICS (и ANALYZE после этого обязателен).
Если второе — нужно смотреть как минимум на все параметры нагрузки, которые у Вас просят tuners — см. ещё http://pgconfigurator.cybertec.at/ , кстати.
источник
19:41пожаловаться#1

L

Les in pgsql – PostgreSQL
Коллеги, а можно сдампить базу и сразу восстановиться на другом хосте через pipe, без сохранения и удаления файлов .sql ?
источник
19:44пожаловаться#2

АЛ

Аггей Лоскутников... in pgsql – PostgreSQL
Можно
источник
19:45пожаловаться#3

L

Les in pgsql – PostgreSQL
спасибо
источник
19:45пожаловаться#4

NA

Nikolay Abrosimov in pgsql – PostgreSQL
Yaroslav Schekin
Разница в оценках тут очень существенная (38553.57 vs 134841.33).
И вот ещё:
 ->  Parallel Index Scan using bs_incoming_2020_07_demodulation_time_idx on bs_incoming_2020_07  (cost=0.43..129820.68 rows=381200 width=4) (actual time=0.024..8.244 rows=11646 loops=3)
       Index Cond: (demodulation_time >= '2020-07-23 16:54:37.84+00'::timestamp with time zone)
       Buffers: shared hit=21124

 ->  Parallel Index Scan using bs_incoming_2020_07_demodulation_time_idx on bs_incoming_2020_07  (cost=0.43..130188.54 rows=382109 width=4) (actual time=0.130..1387.630 rows=203675 loops=3)
       Index Cond: (demodulation_time >= '2020-07-23 16:54:37.84+00'::timestamp with time zone)
       Buffers: shared hit=338478 read=4

То же условие, но теперь actual rows стало гораздо больше. Данные добавляются, а autovacuum не успевает?

В общем, тут можно пробовать либо оценки улучшать (проблема из-за них, как минимум), либо начать с tuning (хотя и "железо" очень слабое, конечно :( ).
Если делать первое, можно попробовать CREATE STATISTICS (и ANALYZE после этого обязателен).
Если второе — нужно смотреть как минимум на все параметры нагрузки, которые у Вас просят tuners — см. ещё http://pgconfigurator.cybertec.at/ , кстати.
Вряд-ли железо не успевает... База работает 99% времени в режиме write-only и совершает 4-10 INSERT в секунду. Процессор загружен на единицы процентов, в качестве хранилища используется SSD.

К тому-же, другой запрос, данные для которого приходят в 6.5 раз чаще, работает быстрее...

насколько я понял, actual rows это количество сообщений, подходящих под запрос? Скорее всего просто данные накопились. Первый Explain был сделан когда count был менее 8 тысяч, а сейчас - больше 18

Поможете с CREATE STATISTIC? На что нужно натравить?)
источник
20:04пожаловаться#5

АЛ

Аггей Лоскутников... in pgsql – PostgreSQL
VACUUM ANALYZE
источник
20:07пожаловаться#6

YS

Yaroslav Schekin in pgsql – PostgreSQL
Nikolay Abrosimov
Вряд-ли железо не успевает... База работает 99% времени в режиме write-only и совершает 4-10 INSERT в секунду. Процессор загружен на единицы процентов, в качестве хранилища используется SSD.

К тому-же, другой запрос, данные для которого приходят в 6.5 раз чаще, работает быстрее...

насколько я понял, actual rows это количество сообщений, подходящих под запрос? Скорее всего просто данные накопились. Первый Explain был сделан когда count был менее 8 тысяч, а сейчас - больше 18

Поможете с CREATE STATISTIC? На что нужно натравить?)
> Вряд-ли железо не успевает...

Не успевает, конечно. Это по планам видно:
  Buffers: shared hit=22555 read=52532
  I/O Timings: read=29825.175

В "железе" главное — RAM. ;) И кстати, что это за "прекрасный" SSD, который выдаёт 14 MB/s (если я не обсчитался)?
> SELECT pg_size_pretty((52532 * 8192.0) / 29)
 14 MB

Throttling IOPS там жёсткий, наверное?

> насколько я понял, actual rows это количество сообщений, подходящих под запрос?

Да.

> Скорее всего просто данные накопились.

Ну да, я так и понял...

> Поможете с CREATE STATISTIC? На что нужно натравить?)

Да можно попробовать просто как-то так (примерно):
CREATE STATISTICS some_stat ON batch_id, owner_id FROM sync_devices;
VACUUM ANALYZE sync_devices; -- или хотя бы просто ANALYZE
источник
20:13пожаловаться#7

NA

Nikolay Abrosimov in pgsql – PostgreSQL
Yaroslav Schekin
> Вряд-ли железо не успевает...

Не успевает, конечно. Это по планам видно:
  Buffers: shared hit=22555 read=52532
  I/O Timings: read=29825.175

В "железе" главное — RAM. ;) И кстати, что это за "прекрасный" SSD, который выдаёт 14 MB/s (если я не обсчитался)?
> SELECT pg_size_pretty((52532 * 8192.0) / 29)
 14 MB

Throttling IOPS там жёсткий, наверное?

> насколько я понял, actual rows это количество сообщений, подходящих под запрос?

Да.

> Скорее всего просто данные накопились.

Ну да, я так и понял...

> Поможете с CREATE STATISTIC? На что нужно натравить?)

Да можно попробовать просто как-то так (примерно):
CREATE STATISTICS some_stat ON batch_id, owner_id FROM sync_devices;
VACUUM ANALYZE sync_devices; -- или хотя бы просто ANALYZE
После CREATE STATISTICS и VACUUM ANALYZE стало пошустрее. 400-800мс на запрос. Спасибо!

> И кстати, что это за "прекрасный" SSD, который выдаёт 14 MB/s (если я не обсчитался)?
Судя по мониторингу, там было около 75MB/s.

> Не успевает, конечно
1Gb RAM и 2 CPU с SSD мало для того, чтобы делать менее 10 INSERT`ов в секунду? Мне казалось, что это совсем плёвая задача и её должен уметь делать даже калькулятор... А тюнинг конфига может помочь в ускорении? Или профит будет, но разница не кардинальна?
источник
20:31пожаловаться#8

YS

Yaroslav Schekin in pgsql – PostgreSQL
Nikolay Abrosimov
После CREATE STATISTICS и VACUUM ANALYZE стало пошустрее. 400-800мс на запрос. Спасибо!

> И кстати, что это за "прекрасный" SSD, который выдаёт 14 MB/s (если я не обсчитался)?
Судя по мониторингу, там было около 75MB/s.

> Не успевает, конечно
1Gb RAM и 2 CPU с SSD мало для того, чтобы делать менее 10 INSERT`ов в секунду? Мне казалось, что это совсем плёвая задача и её должен уметь делать даже калькулятор... А тюнинг конфига может помочь в ускорении? Или профит будет, но разница не кардинальна?
> После CREATE STATISTICS и VACUUM ANALYZE стало пошустрее. 400-800мс на запрос.

А план смотрели? Нужный выбирается (вдруг это всё — кеширование)?

> Судя по мониторингу, там было около 75MB/s.

По крайней мере, это не то, что показывает EXPLAIN ANALYZE. И (даже если это так) мне не кажется, что это очень уж хорошо для современного SSD.

> 1Gb RAM и 2 CPU с SSD мало для того, чтобы делать менее 10 INSERT`ов в секунду?

Хмм... причём тут INSERT-ы? Вы ни о каких проблемах с ними не писали... нет?
А проблемный запрос у Вас вовсе не OLTP (они не должны читать сотни мегабайт, в норме).

> А тюнинг конфига может помочь в ускорении?

Скорее всего, да.

> Или профит будет, но разница не кардинальна?

А кто его знает — по железу и нагрузке Вы достаточной информации не показали (опять-таки, как я писал в https://t.me/pgsql/241011 —  нужно смотреть как минимум на все параметры нагрузки, которые у Вас просят tuners). ;)
Telegram
Yaroslav Schekin in pgsql – PostgreSQL
Разница в оценках тут очень существенная (38553.57 vs 134841.33).
И вот ещё:
->  Parallel Index Scan using bs_incoming_2020_07_demodulation_time_idx on bs_incoming_2020_07  (cost=0.43..129820.68 rows=381200 width=4) (actual time=0.024..8.244 rows=11646 loops=3)
      Index Cond: (demodulation_time >= '2020-07-23 16:54:37.84+00'::timestamp with time zone)
      Buffers: shared hit=21124

->  Parallel Index Scan using bs_incoming_2020_07_demodulation_time_idx on bs_incoming_2020_07  (cost=0.43..130188.54 rows=382109 width=4) (actual time=0.130..1387.630 rows=203675 loops=3)
      Index Cond: (demodulation_time >= '2020-07-23 16:54:37.84+00'::timestamp with time zone)
      Buffers: shared hit=338478 read=4
То же условие, но теперь actual rows стало гораздо больше. Данные добавляются, а autovacuum не успевает?

В общем, тут можно пробовать либо оценки улучшать (проблема из-за них, как минимум), либо начать с tuning (хотя и "железо" очень слабое, конечно :( ).
Если делать первое, можно попробовать CREATE STATISTICS…
источник
21:05пожаловаться#9
2020 July 28

f

ferret🔬 in pgsql – PostgreSQL
Всем привет!
Подскажите, где ошибся или что упустил.
Ситуация: если запись существует - обновить, иначе - создать. Проблема с созданием: id не автоинкрементируется, а получает значения на порядок больше, последнего 'правильного' id. 
insert into subdomains(domain_id,name,source)
values (1, 'foo', 'bar'),(1, 'example', 'example1')
  on conflict (name) do update set
  domain_id=excluded.domain_id,
  source=excluded.source;

поле 
name - unique

разобрался, нужно добавить 
id=excluded.id
источник
01:22пожаловаться#10

.

. in pgsql – PostgreSQL
Всем привет! Хочу почистить и немного уменьшить объем базы с помощью reindex и full vacuumdb. База данных master-replica. Необходимо эти команды запускать только на мастере или на реплике тоже?
источник
06:02пожаловаться#11

o

om in pgsql – PostgreSQL
Sergey
Существует. Вы меня слышите вообще? Я и говорю что это узкие проекты, либо стартапы, и в целом все кто тут есть это и подтверждают.
Холивара для.
На слуху многопетабайтные БД на PostgreSQL. А как с этим с MS SQL Server?
Причём не про PDW и прочее SSAS, а именно операционные БД?
источник
06:33пожаловаться#12

РЖ

Роман Жарков... in pgsql – PostgreSQL
.
Всем привет! Хочу почистить и немного уменьшить объем базы с помощью reindex и full vacuumdb. База данных master-replica. Необходимо эти команды запускать только на мастере или на реплике тоже?
На мастере. Реплики не поддерживают "пишущие" запросы.
Имейте ввиду, что объём трафика возрастёт после vacuum full. Реиндекс, после него, кстати, не нужен - оно само переделает все индексы.
источник
06:46пожаловаться#13

.

. in pgsql – PostgreSQL
Роман Жарков
На мастере. Реплики не поддерживают "пишущие" запросы.
Имейте ввиду, что объём трафика возрастёт после vacuum full. Реиндекс, после него, кстати, не нужен - оно само переделает все индексы.
В общем достаточно будет full vacuumdb на мастере? А реплика при этом не отстанет от мастера? У нас настроена синхронная репликация
источник
06:48пожаловаться#14

РЖ

Роман Жарков... in pgsql – PostgreSQL
.
В общем достаточно будет full vacuumdb на мастере? А реплика при этом не отстанет от мастера? У нас настроена синхронная репликация
Зависит от размера базы. Тупить будет пока не доделает :)
источник
06:48пожаловаться#15

РЖ

Роман Жарков... in pgsql – PostgreSQL
vacuum full - пересоздание таблицы заново, по сути.
источник
06:49пожаловаться#16

.

. in pgsql – PostgreSQL
Роман Жарков
Зависит от размера базы. Тупить будет пока не доделает :)
Размер базы сейчас составляет 23 Гига, при этом если снять sql dump и развернуть в новую базу будет весить 1.2Гб
источник
06:50пожаловаться#17

РЖ

Роман Жарков... in pgsql – PostgreSQL
om
Холивара для.
На слуху многопетабайтные БД на PostgreSQL. А как с этим с MS SQL Server?
Причём не про PDW и прочее SSAS, а именно операционные БД?
Эти базы - штучные продукты.
Напоминает спор пэтэушников-маляров на чём лучше рисовать: на штукатурке или на холсте. Все такие сразу Микеланджелы.
источник
06:53пожаловаться#18

РЖ

Роман Жарков... in pgsql – PostgreSQL
.
Размер базы сейчас составляет 23 Гига, при этом если снять sql dump и развернуть в новую базу будет весить 1.2Гб
Попробуйте на отдельных таблицах потренироваться.
У vacuum full есть основное мерзкое свойство - пока не доделается, доступ к таблице заблокирован полностью.
Если это не проблема - делайте смело.
источник
06:54пожаловаться#19

o

om in pgsql – PostgreSQL
Роман Жарков
Эти базы - штучные продукты.
Напоминает спор пэтэушников-маляров на чём лучше рисовать: на штукатурке или на холсте. Все такие сразу Микеланджелы.
Ну я бы не сказал. Объём данных растёт. И БД размером более петабайта уже вовсю становятся маенстримом. Поэтому, вполне адекватный критерий.
источник
06:55пожаловаться#20