Melkij

приведение массива record к массиву композитного типа позиционное, а не символьное. Поменяйте в

SELECT DISTINCT ON (asin) asin, price, reviews, raing

порядок полей на совпадающий с таковым в таблице.

убрали бы лишние подзапросы, что ли.

(SELECT array_agg(j) FROM (SELECT DISTINCT ON (j.asin) j FROM jsonb_populate_recordset(NULL::t_best_asin_ranking_2, '[{
"asin":"B06XH9FNH1",                                                                                                  
"price": 1.5,                                                                                                   
"rating": 1.5,
"reviews": 1
}]') j ORDER BY j.asin) r);

вот так хотя бы.

Не связано с микросервисами никак. Может встретиться в любых приложениях, работающих с базой.

Кто-то забывает делать ограничения в схеме БД. Кто-то может вовсе не знать, что FK и check constraints существуют. Кто-то считает что проверки на приложении достаточно. (в этом случае бывает забавно показать примеры уже лежащих в БД данных, невозможных с точки зрения логики приложения)

Сознательный, реально обоснованный отказ от FK - штука крайне редкая

База на 30гб? Какая смешная кроха.

Да сгенерируйте себе синтетических данных и поиграйтесь с ними. Я понимаю неудобно на локальной машине щупать базу в десяток террабайт - но лишь только 30гб не проблема просто сгенерировать и посмотреть вживую.

Определитесь с тем как вы будете удалять эти данные.

3 колонки id, factor_id, parcel_id

Данную таблицу не надо анализировать или агрегировать. Нужно только иметь возможность быстро вставить и прочитать запись.

Очень большое сомнение что вам здесь нужен id вместо составного pk.

увеличивается примерно на 100к записей в день

Т.е. сейчас у вас данные за 15 лет работы и вас беспокоит что будет ещё через 15 лет? Ну просто пересчитав указанные объёмы вставки.

В полновесном MVCC транзакционнике PostgreSQL очень маленькие строки держать несколько дорого именно по месту, заголовок строки большой.

3 колонки id, factor_id, parcel_id

24 да 3*8 байт если эти поля считать bigint'ами, да на лярд записей... порядка 25гб плюс-минус. Фигня вопрос вообще-то. У вас проблема-то есть? Или просто руки чешутся?

Чтобы:
- без особой пользы в разы увеличить объём хранимых данных. Тем более если использовать строки.
- постараться запутать планировщик базы
- дополнительно увеличить стоимость записи индексов (значения случайны = значения пишутся в случайные места дерева, вы постоянно "пачкаете" разные страницы)

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

basebackup - это буквально копирование почти всего из PGDATA тупо на уровне файликов.
Строго в один поток. (ну, на самом деле в отдельном потоке walreceiver ещё если wal method выставлен stream)

Смотрите внимательнее куда упираетесь. Диск на чтение откуда снимаете? Диск куда пишете? Сеть? Одно ядро CPU на базе с которой снимаете? На которую пишете?
Несколько гигабит занять в общем-то не проблема.

Вы должны разрабатывать и деплоить приложение соответствующим образом. Так, чтобы старая версия приложения могла работать с новой версией схемы базы. Или наоборот, новая версия приложения могла работать со старой схемой базы.
То есть удаление таблички: сначала деплоите приложение, которое уже не работает с этой таблицей, потом удаляете таблицу
Новая табличка: сначала миграция, затем приложение
Новое поле в таблице с default значением: сначала поле, затем приложение
Новое поле без default: сначала новое поле с default null, затем релиз приложения которое обязано писать новое поле, но ещё не читать его (либо приводить null к нужному если это возможно на приложении), затем миграция с проставлением нужного значения (и, блин, не одним update по всей большой таблице), drop default, set not null, деплой приложения со всей логикой
И так далее. Во время разработки думаем, а как, когда и в сколько итераций это можно будет задеплоить.

Ну и, разумеется, DBA (или заменяющий его обязанности человек) думает над тем, как именно вносить нужную миграцию в базу

Работаем. Постоянно. У меня не установлено ни одного GUI к какой-либо базе

В psql вывод большого числа строк решается штатным \pset pager {on,off,always}, большое число столбцов обычно удобнее в развёрнутом виде (\x) смотреть.
Или взять less в качестве PAGER и получить скролл таблицы и горизонтальный и вертикальный:

export PAGER='/usr/bin/less -S'
psql

Для клиента mysql помню только развёрнутый вывод \G после запроса:

mysql> select * from users \G
*************************** 1. row ***************************
        id: 104
      name: NULL
    gender: 0
birth_date: 0
     phone: NULL
1 row in set (0.00 sec)

По клиенту к ораклу ничего не скажу, не видел.

Есть фундаментальный труд Transactional Information Systems. Theory, Algorithms, and the Practice of Concurrency Control and Recovery авторства Gerhard Weikum и Gottfried Vossen.

Ведь не проблема читать-писать файлы. Проблема - как это делать корректно в условиях конкурентного доступа, как обеспечивать восстановление после аварий, как обеспечивать ACID. В этой книге как раз вся сопутствующая теория.

Составной индекс 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 (возможно по отдельному сканированию на каждую строку, которая вызвала проверку целостности ключа)