но теперь появляется новый вопрос,  как сделать проверку используется ли данное значение в какой либо из таблиц.

В общем-то, не стоит лезть руками в системные таблицы: https://stackoverflow.com/questions/25889398/how-to-alter-type-and-remove-value-in-postgresql/49753911#49753911

И документация сразу предупреждает:
PostgreSQL's system catalogs are regular tables. You can drop and recreate the tables, add columns, insert and update values, and severely mess up your system that way. Normally, one should not change the system catalogs by hand, there are normally SQL commands to do that.

немного попозже могу проверить

господа, может кто-то подскажет идею как можно решить следующий вопрос: нужно решить задачу для запроса сколько хитов и кеша буферного кеша постргреса превратятся в чтения в случае еслибы кеш  был бы псутой. Поясню из плана запроса или из pg_stat_statements мы можем получить число shared_blks_hit\shared_blks_read. Но т.к к одному блоку во время выполнения запроса мы можем обратить дважды или больше нельзя сказать что общее кол-во чтений в случае холодного кеша будет shared_blks_hit+shared_blks_read.
простой пример
demo=# EXPLAIN (ANALYZE, buffers) SELECT * FROM t2 union all select * from t2;
                                                   QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Append  (cost=0.00..468.00 rows=20000 width=37) (actual time=0.018..39.915 rows=20000 loops=1)
  Buffers: shared hit=168
  ->  Seq Scan on t2  (cost=0.00..184.00 rows=10000 width=37) (actual time=0.015..7.022 rows=10000 loops=1)
        Buffers: shared hit=84
  ->  Seq Scan on t2 t2_1  (cost=0.00..184.00 rows=10000 width=37) (actual time=0.009..6.938 rows=10000 loops=1)
        Buffers: shared hit=84
Planning Time: 0.062 ms
Execution Time: 52.844 ms
(8 rows)

В общем случае — никак. А зачем это вообще нужно?

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

а можно кэш прогревать после запуска БД, если очень нужно

> а в каких случаях возможно?

В самых тривиальных (когда известно, что запрос только один, и известно, сколько есть доступного кеша и т.д.), и то так рассчитаете только чтение из кеша OS.

> задача оценить сколько этот запрос будет работать если кеш будет холодный

Опять-таки, зачем? В норме такое должно случаться очень редко, нет?

вот у меня есть запрос - он на тестовом сервере (полная копия боевого сервера по всем параметрам) выполнился за X   секунд, хочу понять за сколько он в худшем случае выполнится на бевом сервере. Тестовый получен промоутом теплого стенбая поэтому физическое расположение данных и план запроса одинаковые

И, опять-таки, не поймёте. Это если мы про реальность говорим, а не про гадание на shared hit. ;)

И даже если бы это было возможно — как можно с пользой применить эту информацию?

мне не нужна идеальная точность, ошибка на 15-20% ок, главное не на порядок. как применить - ну довольно просто - на тестовом сервере ведется проверка запросовёмиграций и тд и нужно понять попадаем мы в ограничения длительности которые накладываются на мастере или нет

> мне не нужна идеальная точность, ошибка на 15-20% ок

Если получится — расскажите, как (потому что лично мне это кажется несбыточными мечтами, не меньше).
(И разница с "расчётным" запросто может быть и на порядок, и более, как ни считай, IMHO.)

> нужно понять попадаем мы в ограничения длительности которые накладываются на мастере

Так СУБД общего назначения — не realtime-системы, поэтому тут можно только надеяться.

привет! выгружаю роли через pg_dumpall -r, прогоняю на свежем сервере, затем при попытке доступа к объектам получаю: permission denied for schema public

что я делаю не так? :)

наличие роли в базе не означает, что ей выданы какие-то права

а как скопировать всё?

я отдельно роли копирую и отдельно данные

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

результаты могут быть очень разными из-за разных условий в запросе. если вам не хватает данных из explain/pg_stat_statements, посмотрите на log_executor_stats, там замеры на основе getrusage, что чуть "ближе" к системе. но имхо все равно закладываться на эти результаты и чтото планировать на их основе не очень надежно.

вам нужно в довесок к ролям сдампить еще и гранты, скорей всего еще раз придется вызвать pg_dump, но вцелом это дешево по ресурсам