Size: a a a

pgsql – PostgreSQL

2021 March 22

АХ

Александр Хакимов... in pgsql – PostgreSQL
Yaroslav Schekin
Нет, это то, что Вам нужно показать.
Если отказываетесь — лучше поищите помощь где-то в другом месте, честное слово.
Мне интересно, зачем мне показывать структуру всех моих таблиц, для решения вопроса с "одной конкретной зависшей таблицей"?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Александр Хакимов
Мне интересно, зачем мне показывать структуру всех моих таблиц, для решения вопроса с "одной конкретной зависшей таблицей"?
Имелось в виду "каждой используемой в запросе таблицы", конечно.
Это общий совет, надоедает его перепечатывать. ;)
источник

АХ

Александр Хакимов... in pgsql – PostgreSQL
А, сорри.
источник

АХ

Александр Хакимов... in pgsql – PostgreSQL
И да, проблема пропала. Удалил данные из таблицы которые не использовались и были однотипными. Потом вакумом прошёлся и всё схлопнулось и быстро работает
источник

АХ

Александр Хакимов... in pgsql – PostgreSQL
всем спасибо
источник

D

Dmitriy in pgsql – PostgreSQL
Александр Хакимов
И да, проблема пропала. Удалил данные из таблицы которые не использовались и были однотипными. Потом вакумом прошёлся и всё схлопнулось и быстро работает
Так и толку? Со временем опять разжиреет - и запросы тупить начнут, если индексов нужных нет
источник

АХ

Александр Хакимов... in pgsql – PostgreSQL
Dmitriy
Так и толку? Со временем опять разжиреет - и запросы тупить начнут, если индексов нужных нет
Код поправил, который пихал данные в таблицу, теперь не разжиреет
источник

ГА

Георгий Ава... in pgsql – PostgreSQL
Yaroslav Schekin
А какая версия PostgreSQL? Если последний minor любой версии — пишите bug report, что ж.
postgres=# select version();
                                                   version                                                    
----------------------------------------------------------------------------------------------------------------
PostgreSQL 11.7 (Debian 11.7-0+deb10u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
(1 строка)
источник

D

Dmitriy in pgsql – PostgreSQL
Александр Хакимов
Код поправил, который пихал данные в таблицу, теперь не разжиреет
Как знаете
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Георгий Ава
postgres=# select version();
                                                   version                                                    
----------------------------------------------------------------------------------------------------------------
PostgreSQL 11.7 (Debian 11.7-0+deb10u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
(1 строка)
А последняя-то 11.11. Так что обновитесь сначала.
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
Yaroslav Schekin
Имелось в виду "каждой используемой в запросе таблицы", конечно.
Это общий совет, надоедает его перепечатывать. ;)
У окулиста до трусов раздеваться тоже не надо, но не всем очевидно :)
источник

AJ

Alexey Jericho in pgsql – PostgreSQL
помогите пожалуйста составить запрос)
есть функция ts_debug - возвращает подробности по парсингу поля через tsvector
пример:
SELECT description, token FROM ts_debug('16 парковая');
   description    |  token
-------------------+----------
Unsigned integer  | 16
Space symbols     |
Word, all letters | парковая

из этого интересует наличие токена с типом "Unsigned integer"

идем дальше. имеется таблица osm_buildings в которой есть столбец street в котором содержатся названия улиц. можем взять оттуда какое либо значение, перевести в tsvector и назначить вес "А"
например:
select setweight(to_tsvector(street), 'A')
from osm_buildings
where osm_id = 29702868;
         setweight
-----------------------------
'16':1A 'парков':3A 'ул':4A
А теперь суть вопроса:
Как грамотнее составить запрос, что бы setweight отработала по условию, заглянув сначала в функцию ts_debug по данному полю и если там присутствует какой нибудь токен с типом "Unsigned integer", то присвоила бы всему полю вес А, если отсутствует, то B?
источник

AV

Alexander Vershilov in pgsql – PostgreSQL
А поделитесь пожалуйста местом, где стоит начать изучение того, как разбираться почему высокое CPU usage у postgres. При том, что в pg stat_activity ничего особенно подозрительного нет, а планы тех запросов, которые там видны более-менее адекватные
источник

СК

Сергей Кравчук... in pgsql – PostgreSQL
если цпу высок, а долгих запросов нет, почти наверняка виноваты короткие запросы )

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

ну и иногда наступает момент когда уже ничего не помогает, и просто нужно больше ядер )
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Alexander Vershilov
А поделитесь пожалуйста местом, где стоит начать изучение того, как разбираться почему высокое CPU usage у postgres. При том, что в pg stat_activity ничего особенно подозрительного нет, а планы тех запросов, которые там видны более-менее адекватные
А что-то на самом деле "тормозит" или нет?
И ещё вопрос, как (по ядрам? за какие периоды?) это измеряется — может, "проблема" в этом.
источник

AV

Alexander Vershilov in pgsql – PostgreSQL
Мониторинг в yandex cloud показывает загрузку по CPU >90% на postgres; там среднее за 5 минут по user_time смотрится, afaik, но могу подробнее посмотреть.
источник

ГА

Георгий Ава... in pgsql – PostgreSQL
Yaroslav Schekin
А последняя-то 11.11. Так что обновитесь сначала.
postgres=# select version();
                                                     version                                                      
--------------------------------------------------------------------------------------------------------------------
PostgreSQL 11.11 (Debian 11.11-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
(1 строка)


logic_repl=# \! tail -n 1 -f /var/log/postgresql/backup_test/postgresql-2021-03-22_115030.log
2021-03-22 12:07:18.155 MSK :[18854]::logic_repl:postgres:[idle]:СООБЩЕНИЕ:  оператор: ALTER TABLE information_schema.ddl_events enable replica trigger play_ddl_event;

2021-03-22 12:07:36.625 MSK :[17513]:СООБЩЕНИЕ:  фоновый процесс "logical replication worker" (PID 19059) был завершён по сигналу 11: Ошибка сегментирования
2021-03-22 12:07:36.625 MSK :[17513]:СООБЩЕНИЕ:  завершение всех остальных активных серверных процессов
2021-03-22 12:07:36.630 MSK :[18854]::logic_repl:postgres:[idle]:ПРЕДУПРЕЖДЕНИЕ:  закрытие подключения из-за краха другого серверного процесса
2021-03-22 12:07:36.630 MSK :[18854]::logic_repl:postgres:[idle]:ПОДРОБНОСТИ:  Управляющий процесс отдал команду этому серверному процессу откатить текущую транзакцию и завершиться, так как другой серверный процесс завершился аварийно и возможно разрушил разделяемую память.
2021-03-22 12:07:36.630 MSK :[18854]::logic_repl:postgres:[idle]:ПОДСКАЗКА:  Вы сможете переподключиться к базе данных и повторить вашу команду сию минуту.
2021-03-22 12:07:36.632 MSK :[17534]::postgres:postgres:[idle]:ПРЕДУПРЕЖДЕНИЕ:  закрытие подключения из-за краха другого серверного процесса
2021-03-22 12:07:36.632 MSK :[17534]::postgres:postgres:[idle]:ПОДРОБНОСТИ:  Управляющий процесс отдал команду этому серверному процессу откатить текущую транзакцию и завершиться, так как другой серверный процесс завершился аварийно и возможно разрушил разделяемую память.
2021-03-22 12:07:36.632 MSK :[17534]::postgres:postgres:[idle]:ПОДСКАЗКА:  Вы сможете переподключиться к базе данных и повторить вашу команду сию минуту.
2021-03-22 12:07:36.636 MSK :[17520]:ПРЕДУПРЕЖДЕНИЕ:  закрытие подключения из-за краха другого серверного процесса
2021-03-22 12:07:36.636 MSK :[17520]:ПОДРОБНОСТИ:  Управляющий процесс отдал команду этому серверному процессу откатить текущую транзакцию и завершиться, так как другой серверный процесс завершился аварийно и возможно разрушил разделяемую память.
2021-03-22 12:07:36.636 MSK :[17520]:ПОДСКАЗКА:  Вы сможете переподключиться к базе данных и повторить вашу команду сию минуту.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Георгий Ава
postgres=# select version();
                                                     version                                                      
--------------------------------------------------------------------------------------------------------------------
PostgreSQL 11.11 (Debian 11.11-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
(1 строка)


logic_repl=# \! tail -n 1 -f /var/log/postgresql/backup_test/postgresql-2021-03-22_115030.log
2021-03-22 12:07:18.155 MSK :[18854]::logic_repl:postgres:[idle]:СООБЩЕНИЕ:  оператор: ALTER TABLE information_schema.ddl_events enable replica trigger play_ddl_event;

2021-03-22 12:07:36.625 MSK :[17513]:СООБЩЕНИЕ:  фоновый процесс "logical replication worker" (PID 19059) был завершён по сигналу 11: Ошибка сегментирования
2021-03-22 12:07:36.625 MSK :[17513]:СООБЩЕНИЕ:  завершение всех остальных активных серверных процессов
2021-03-22 12:07:36.630 MSK :[18854]::logic_repl:postgres:[idle]:ПРЕДУПРЕЖДЕНИЕ:  закрытие подключения из-за краха другого серверного процесса
2021-03-22 12:07:36.630 MSK :[18854]::logic_repl:postgres:[idle]:ПОДРОБНОСТИ:  Управляющий процесс отдал команду этому серверному процессу откатить текущую транзакцию и завершиться, так как другой серверный процесс завершился аварийно и возможно разрушил разделяемую память.
2021-03-22 12:07:36.630 MSK :[18854]::logic_repl:postgres:[idle]:ПОДСКАЗКА:  Вы сможете переподключиться к базе данных и повторить вашу команду сию минуту.
2021-03-22 12:07:36.632 MSK :[17534]::postgres:postgres:[idle]:ПРЕДУПРЕЖДЕНИЕ:  закрытие подключения из-за краха другого серверного процесса
2021-03-22 12:07:36.632 MSK :[17534]::postgres:postgres:[idle]:ПОДРОБНОСТИ:  Управляющий процесс отдал команду этому серверному процессу откатить текущую транзакцию и завершиться, так как другой серверный процесс завершился аварийно и возможно разрушил разделяемую память.
2021-03-22 12:07:36.632 MSK :[17534]::postgres:postgres:[idle]:ПОДСКАЗКА:  Вы сможете переподключиться к базе данных и повторить вашу команду сию минуту.
2021-03-22 12:07:36.636 MSK :[17520]:ПРЕДУПРЕЖДЕНИЕ:  закрытие подключения из-за краха другого серверного процесса
2021-03-22 12:07:36.636 MSK :[17520]:ПОДРОБНОСТИ:  Управляющий процесс отдал команду этому серверному процессу откатить текущую транзакцию и завершиться, так как другой серверный процесс завершился аварийно и возможно разрушил разделяемую память.
2021-03-22 12:07:36.636 MSK :[17520]:ПОДСКАЗКА:  Вы сможете переподключиться к базе данных и повторить вашу команду сию минуту.
Печально. :( Пишите bug report (лучше, конечно, если получится написать repro).
источник

МШ

Михаил Шурутов... in pgsql – PostgreSQL
Мал-мала поправил обзор инструментария для бекапов ПГ: https://ru-postgres.livejournal.com/66359.html
Добавил столбцы Шифрование данных, Хуки и Частичное восстановление, поковырялся в доках и таки решил, что wal-g нельзя не рассматривать.
источник

PM

Pavel Mellonges® in pgsql – PostgreSQL
вопрос новичка: в postgres указываются числа без скобок, а строки в исключительно одинарных ковычках?
источник