Эээ... вопрос же был про порядок полей для конкретного запроса, нет?
И порядок тут важен, конечно.

То, сколько (какая доля, в среднем) записей отбирается каждой комбинацией условий из:
1.  a > 10 AND b = 'somebody'
2.  b = 'somebody' AND c < 20

А как это понять? Я вот могу посмотреть, что именно лежит в буффер Кеше, а как понять что нагружает диск?
Единственное, что снизил частоту чекпоинтлв через wal_max_size с трёх раз в 10 минут до одного раза, но на общую картину это не повлияло

Конечно ?

Даже "обычные" tools вроде iotop могут дать такую информацию.
Затем, её (только отчасти!) можно получить и "изнутри" postgres, см. pg_current_wal_lsn() и pg_stat_*, например.

В чём вопрос-то?

Про порядок важен

и там где записей больше ставить на 2 место, а где меньше на 3?

Условия были:

WHERE a > 10 AND b = 'somebody' AND c < 20

Т.е. здесь, скорее всего, больше одного значения b в таблице. ;) Поэтому оно идёт в начало, остальные — см. выше.
Или же я не понял, в чём именно Ваш вопрос. :(

WHERE a > 10 AND b = 'somebody' AND c < 20

Если это вопрос про btree, то скорее всего это - покрывающий уникальный индекс, он представляет из себя данные в виде кортежа, по которым btree дерево перестраивает TID-ы при вставке новых значений, теперь прочитайте, что я писал выше

Лучше сделать индекс по более селективному условию.
Т.е. если, к примеру
1. " b = 'somebody' AND a > 10 " выбирает 2000 записей, а
2. " b = 'somebody' AND c < 20 " — только 15,
то лучше использовать INDEX ON (b, c, a).

Я прочитал. И что? Вопрос (или совет) в чём?

Понял, спасибо, буду ковыряться....

Спасибо большое, что помогли разобраться!

ERROR:  cannot refresh materialized view concurrently

можно ли этого избежать? есть вероятность, что обновление одной и той же вьюхи запустили 2 раза

может есть какие-то проверки, что обновление запущено?

Приветы!

У меня есть вопрос, который несколько выходит за пределы моих точных познаний по проектированию баз данных.

Собственно, кейс такой.
Проектируется кусок REST API, который позволяет пользователю заполнить огромных размеров форму, состоящую из некоторого фиксированного количества разделов (пусть будет 6).
В каждом разделе пользователь может ввести один из двух типов данных (он прям вот галочкой явно переключается): либо целевые данные (пусть будет информация о страховке, которую он хотел бы оформить) с кучей полей, либо стандартный набор данных о уже существующей страховке (когда и кем выдана).

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

Итого, на языке сущностей, у меня получается:
- есть некоторая центральная сущность, назовём её InsuranceDetails.
- есть 6 разных сущностей, представляющих целевые данные: MedicalInsuranceDetails, CarInsuranceDetails, HouseInsuranceDetails, итд. У них явно связь 1:1 c InsuranceDetails, и на стороне InsuranceDetails просто лежит FK указывающий на PK каждой из этих таблиц.
- и есть 1 сущность, которая представляет стандартные данные: ExistedInsuranceDetails

И вот мы подобрались к самому главному. А ExistedInsuranceDetails к InsuranceDetails как относится?
С одной стороны это 1:M, потому что один InsuranceDetails может иметь много ExistedInsuranceDetails.
C другой стороны, это 1:1, потому что один InsuranceDetails может иметь 0 или 1 ExistedInsuranceDetails, относящихся к разделу Medical, 0 или 1 ExistedInsuranceDetails относящихся к разделу Car итд.


Т.е. получается какая-то 1:M, но каждая связь тегированна уникально... в общем я даже не догадываюсь как это правильно погуглить 🙂

Сейчас решил это тем, что затащил вообще все FK в InsuranceDetails фактически гвоздями прибив 1:M везде. Есть сомнения в правильности такого подхода в целом, но тут на чаще весов "за", то что местный ORM такое переваривает очень хорошо и не требует дополнительных телодвижений, на чаще весов "против" - сомнения, что это всё вообще правильно.

Вопрос: есть какой-то "правильный" подход для решения подобного класса задач?

не знаю кому как, но мне лень читать портянку(

Может, дело совсем не в этом? Вы это где запускаете, hint там нет в сообщении об ошибке?