Melkij

create sequence serial_number_seq minvalue 1 maxvalue 999999999;

Сделать новое число - nextval('serial_number_seq')
Гарантированно уникально. К строке, если очень хочется, можете привести сами

select admin_id
count(*) filter(where created_at >= '2019-01-01' and created_at < '2019-02-01'),
count(*) filter(where created_at >= '2019-02-01' and created_at < '2019-03-01'),
....
from tablename where ... group by admin_id

Или tablefunc

А называется то что вы хотите получить - PIVOT.

Зачем вам рут для поиграться с базой? Postgresql прямо запрещает запуск себя от рута.
initdb куда скажут себе в хомяке и стартовать оттуда базу через pg_ctl может любой пользователь с доступом к консоли. Порт только себе выбрать любой свободный выше привилегированного диапазона. И играйтесь в своё удовольствие, никаких особых прав для этого не надо.

Если truncate выполняется дольше секунды - значит truncate не выполняется вовсе, а ждёт блокировку.

Посмотрите в pg_stat_activity where state != 'idle' на предмет долгих транзакций.
Или сразу запросом по pg_locks, например, вот таким: https://github.com/dataegret/pg-utils/blob/master/...

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

melkij=> create table identity_test (i int primary key generated by default as identity, val int);
CREATE TABLE
melkij=> insert into identity_test (val) values (1);
INSERT 0 1
melkij=> table identity_test;
 i | val 
---+-----
 1 |   1
(1 строка)

melkij=> create table identity_test_like (like identity_test INCLUDING COMMENTS INCLUDING CONSTRAINTS INCLUDING DEFAULTS INCLUDING INDEXES);
CREATE TABLE
melkij=> \d identity_test_like
                    Таблица "public.identity_test_like"
 Столбец |   Тип   | Правило сортировки | Допустимость NULL | По умолчанию 
---------+---------+--------------------+-------------------+--------------
 i       | integer |                    | not null          | 
 val     | integer |                    |                   | 
Индексы:
    "identity_test_like_pkey" PRIMARY KEY, btree (i)

melkij=> \d identity_test
                                Таблица "public.identity_test"
 Столбец |   Тип   | Правило сортировки | Допустимость NULL |           По умолчанию           
---------+---------+--------------------+-------------------+----------------------------------
 i       | integer |                    | not null          | generated by default as identity
 val     | integer |                    |                   | 
Индексы:
    "identity_test_pkey" PRIMARY KEY, btree (i)

include identity нет - identity не скопирован. Всё выглядит корректно.

Если же вы не про identity, а про синтаксический сахар serial - то его nextval был скопирован потому вы сами это попросили через INCLUDING DEFAULTS.
Типа данных serial нет. Это синтаксический сахар вокруг поля int, создания sequence и указания nextval в default.

Проверяйте версии используемого ПО. Ваша библиотека предоставляющая вызов getImportedKeys очевидно не умеет используемую у вас версию PostgreSQL.
Последний релиз postgresql где было поле tgconstrname системного каталога - далёкий 8.4

pg_upgrade --link ?
Бесполезный datadir от 9.5 удалили? pg_upgrade создал скрипт delete_old_cluster после обновления для этого.

мне сно , при апдейте кортежа в varchar запись удаляется с диска и вписывается на новое место в памяти

Ммм. Сомневаюсь что действительно что-то ясно.

Для начала:
на диске данные существуют ровно в том же виде, что и затем обрабатываются в памяти. Как побочного следствие именно этого, кстати, базы postgresql физически не переносимы на другие процессорные архитектуры, только dump/restore или ещё какую логическую репликацию. А ещё есть забавный фокус выравнивания структур данных в памяти. Из-за чего при разном порядке столбцов в таблице идентичный объём записанных данных может различаться по требуемому месту на дисках.

postgresql - mvcc база. При удалении строки запись не удаляется. Вообще. Только проставляется xmax и страничка отмечается грязной. Операции обновления строки не существует вовсе. Update - это всегда delete + insert. Обновлённая запись при этом попадает в отличающееся место таблицы, так, что в таблице одновременно существую и старая и новая версии строки. И их может быть много.
(enterprisedb грозятся доделать zheap в pg13, так что может будет веселее, но в версиях до 11 гарантированно как я описал, в 12 - только если вы смелый человек и будете собирать экспериментальные расширения)
Итак, далее приходит autovacuum или vacuum, строки которые уже никому не могут быть видны вычищаются и считаются пустым пространством, в том числе по free space map.

Пишущие операции пытаются найти место под запись:
- в той же самой странице данных
- в какой-то странице начиная от начала таблицы
- в худшем случае создают новую страницу

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

занимаемой процессом памяти на жестком диске

Что это такое?
Если интересен формат датафайлов - то вам дорога в исходники базы. Для ОС выделяются блоки на диске по 8кб и в них хранится какая-то бинарная штука.

Касательно private памяти backend'а - в postgresql есть менеджер памяти, называемый memory context. backend память запрашивает у ОС блоками, что-то делает что ему надо используя эту память под всякую мелочь или не очень мелочь, затем memory context обнуляется или удаляется и память возвращается ОС. Большинство контекстов существуют не долго, на транзакцию или на запрос, например.
Отладчик широко распространён - gdb. Без dbg сборки, впрочем, там явно будет ничего не понятно.

Пароли скорей всего сохранены как md5. Метод scram-sha-256 появился только в 10 и включая 12 релиз ещё не используется по-умолчанию (проблем с базой нет, сообщество даёт время на реализацию этого протокола в клиентских библиотеках, чтобы не как с mysql 8.0 получилось).

Хэши паролей md5 можно найти в pg_authid таблице системного каталога, считаются как

select rolpassword = ('md5' || md5('some password' || rolname)) from pg_authid where rolname = 'username';

То есть восстановить исходный пароль невозможно. Можно попробовать подобрать коллизию для хэша.

Никак.
view не хранит никаких данных, а раз нет данных - то не по чему строить индекс.
Пример принципиальной проблемы индекса на view: если сделать view вида select foo, avg(bar) from tablename group by foo; - как пересчитывать данные при изменении строк в tablename?

Индекс может быть создан на материализованном представлении (materialized view) - потому что такое представление данные хранит непосредственно. Но обновлять эти данные требуется вручную запросом REFRESH MATERIALIZED VIEW, который выполнит запрос, запишет его результат в новый heap, затем заменит старый heap новым (если не указан concurrently) либо обновит несовпадающие строки (для concurrently)

Ищите где выставлен statement_timeout. Такая ошибка именно по срабатывании этой настройки. И включать её надо намеренно. Так что ищите где ставится, от конфига СУБД, настроек базы и пользователя до руками сделанного set в приложении.