Спасибо

Кто-то пользуется cockroachdb в проде? Как оно?

Если есть отзывы по CockroachCloud, тоже очень интересно, особенно на GCloud

И неудивительно (он никогда и не был очень хорошим, насколько я помню).
В сторону: Интересно, автор всё так же посылает нафиг игнорирует советы даже основных разработчиков PostgreSQL, когда они пишут ему issues с разъяснениями, в чём он неправ? ;(

я вот мускультюнер ругал)), но  он хотя бы статистику удобно даёт и есть что анализировать, а пгтюн вообще шлак)

Ну так заставить его автора что-то исправить никто не может, такие дела.

По htop видно что он все процы начинает под сотку грузить

ставь пгадмина и дебажь

Ок, всем спасибо за советы, сэкономили мне много времени, появилось ведение куда дальше копать, всем удачи, чтобы бд никогда не падали и чтобы всегда были консистентны )) классное сообщество!

Есть таблица в которой есть время (гг-мм-дд чч:мм:сс)  и перечень строк у которых совпадает название процесса и этих процессов всего штук 10. Вопрос, как погруппировать по этим процессам и по дням одновременно, к примеру 2021-03-20, процесс1 - 10 записей
2021-03-20 процесс 2 - 7 записей,
...
2021-03-21 процесс 1 - 12 записей
2021-03-21 процесс 2 - 9 записей

Не нужно кодом, просто какие мысли есть на этот счёт

GROUP BY timestamp_col, process_col ?

сейчас попробую, спасибо

netbox=# drop table public.dcim_cable;
ERROR:  cannot drop table dcim_cable because other objects depend on it
DETAIL:  constraint circuits_circuittermination_cable_id_35e9f703_fk_dcim_cable_id on table circuits_circuittermination depends on table dcim_cable
constraint dcim_consoleport_cable_id_a9ae5465_fk_dcim_cable_id on table dcim_consoleport depends on table dcim_cable
constraint dcim_consoleserverport_cable_id_f2940dfd_fk_dcim_cable_id on table dcim_consoleserverport depends on table dcim_cable
constraint dcim_interface_cable_id_1b264edb_fk_dcim_cable_id on table dcim_interface depends on table dcim_cable
constraint dcim_poweroutlet_cable_id_8dbea1ec_fk_dcim_cable_id on table dcim_poweroutlet depends on table dcim_cable
constraint dcim_powerport_cable_id_c9682ba2_fk_dcim_cable_id on table dcim_powerport depends on table dcim_cable
constraint dcim_powerfeed_cable_id_ec44c4f8_fk_dcim_cable_id on table dcim_powerfeed depends on table dcim_cable
constraint dcim_frontport_cable_id_04ff8aab_fk_dcim_cable_id on table dcim_frontport depends on table dcim_cable
constraint dcim_rearport_cable_id_42c0e4e7_fk_dcim_cable_id on table dcim_rearport depends on table dcim_cable
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

как проще всего эту таблицу дропнуть, чтоб потом с данными из скрипта пересоздать? хочу в скрипте поменять порядок полей

netbox=# drop table public.dcim_cable;
ERROR:  cannot drop table dcim_cable because other objects depend on it
DETAIL:  constraint circuits_circuittermination_cable_id_35e9f703_fk_dcim_cable_id on table circuits_circuittermination depends on table dcim_cable
constraint dcim_consoleport_cable_id_a9ae5465_fk_dcim_cable_id on table dcim_consoleport depends on table dcim_cable
constraint dcim_consoleserverport_cable_id_f2940dfd_fk_dcim_cable_id on table dcim_consoleserverport depends on table dcim_cable
constraint dcim_interface_cable_id_1b264edb_fk_dcim_cable_id on table dcim_interface depends on table dcim_cable
constraint dcim_poweroutlet_cable_id_8dbea1ec_fk_dcim_cable_id on table dcim_poweroutlet depends on table dcim_cable
constraint dcim_powerport_cable_id_c9682ba2_fk_dcim_cable_id on table dcim_powerport depends on table dcim_cable
constraint dcim_powerfeed_cable_id_ec44c4f8_fk_dcim_cable_id on table dcim_powerfeed depends on table dcim_cable
constraint dcim_frontport_cable_id_04ff8aab_fk_dcim_cable_id on table dcim_frontport depends on table dcim_cable
constraint dcim_rearport_cable_id_42c0e4e7_fk_dcim_cable_id on table dcim_rearport depends on table dcim_cable
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

есть опция чтобы “проще”, в выводе подсказка даже есть.
но стоит быть осторожным, чтобы не снести чего-то важного.

рекомендую DROP хотя-бы в транзакцию обернуть, чтобы откатить, если проверка покажет что-то странное…

Объясните, в чем проблема.
Начал я update всей таблицы

update contacts
set contact_origin = 'Authentic'
where contact_origin is null

Ну думаю, че-то долго, посоветовали циклами по 10к строк апдейтить.
Обрываю запрос, в итоге таблица распухла чуть ли не вдвое (было ~5 стало ~8гб). Но при этом ничего не изменилось, кол-во строк те же, никакие столбцы не апдейтнулись.
Вопрос - с чем это связано?

Коллеги, добрый вечер!
Как интерпретировать ситуацию, когда EXPLAIN показывает Workers Planned: 48, однако, на деле запрос отрабатывает с одним worker?

update contacts
set contact_origin = 'Authentic'
where contact_origin is null

Блоат

С чем это связано?

Свободных worker-ов нет, например (max_parallel_workers, кажется).