Melkij

Составной индекс b типа сравнивается кортежами, то бишь порядок определения индекса имеет значение

Зависит от алгоритма. Справедливо для btree, может быть полностью лишено смысла для других типов. Например, если СУБД будет строить ключ для hash-индекса от конкатенации полей индекса - (a,b) ничем не будет отличаться от (b,a).

лучше определять b индекс для столбцов с высокой селективностью

Не имеет важного значения.
Значение имеет под какие запросы индексы делаем. btree (a,b) не может нормально обслуживать where b = value and a > value, для этого запроса куда осмысленнее (b,a)
Если у вас запрос where a = const and b = const, то btree индексы (a,b) и (b,a) будут равнозначны.

Если у вас индекс с крайне селективным timestamp на первом месте - то что вы с ним делать-то будете? Строгое сравнение таймштампа случай крайне редкий, а на любой запрос диапазона эффективность последующих полей падает катастрофично и большинство СУБД их вовсе не используют. В основном используют только если получается взять индекс как покрывающий.

имеется два столбца в некоторой абстрактной таблице: x - внешний ключ, y - datetime

Варианты если вы попробуете сделать только btree(y,x) индекс:
- СУБД вовсе откажется делать FK т.к. нет подходящего индекса для проверки FK
- СУБД неявно этот индекс создаст при добавлении FK
- СУБД позволит существовать FK без индекса, но соответственно fullscan всей таблицы на каждую проверку консистентности по этому FK (возможно по отдельному сканированию на каждую строку, которая вызвала проверку целостности ключа)

Потому что верное описание синтаксиса limit дано в первой статье.
Что проверяется первоисточником https://dev.mysql.com/doc/refman/8.0/en/select.html

[LIMIT {[offset,] row_count | row_count OFFSET offset}]

Формируется выборка из row_count + offset числа строк, затем первые offset строк отбрасываются и в результирующий набор попадает не более row_count строк.

Без явно указанного order by выборка смысла не имеет вообще, СУБД по стандарту имеет право отдавать любые удовлетворяющие запросу данные в любом порядке по своему усмотрению. Соответственно offset будет взять непонятно откуда и непонятно как.

Есть у меня один зомби-процесс

Где?

user 3954 0.0 0.0 105316 952 pts/0 S+ 05:57 0:00 grep -w Z

Здесь нет ни одного зомби.

А grep в списке процессов ожидаемо есть и по условию "встречается Z" он успешно находит самого себя.

Если чуть присмотреться к пути в сообщении ошибки - то будет очевидно, что прав нет на удалённом хосте 192.168.1.27
То есть вы банально не там смотрите права. sudo разумеется работает только на локальном хосте и удалённому нет никакого дела, есть у вас рутовые права на вашей локальной системе или нет.

Передайте pg_class.oid и всё.

pg_size_pretty(pg_table_size(с.oid)) AS size,
pg_size_pretty(pg_indexes_size(с.oid)) AS idxsize,
pg_size_pretty(pg_total_relation_size(с.oid)) as "total"

Если загляните в определение pg_tables - то увидите, что это view от pg_class с фильтром relkind = 'r'. То есть объединение с pg_tables довольно лишнее.

Судя по расширениям - это куски mysql.
Только запросами к запущенному серверу mysql и взаимодействовать. Клиент выберите любой, их много

Настроек у него никаких, поэтому достаточно проверить, что он загружен, т.е. упомянут в
show shared_preload_libraries;