Структура - это полный, без редактирования, результат выполнения запроса SHOW CREATE TABLE tablename. Всё остальное - хрень собачья.
Окно с фильтрами никому нафиг не нужно. Следует показывать, что будет передано в запрос, или по крайней мере в код. который будет вызывать сервер БД и передавать ему запрос сс параметрами на выполнение. Какие значения (критерии для каких полей), какие возможны их комбинации, примеры значений.
Вывод - следует показывать, что нужно получить в результате выполнения запроса. Рисование потом этого дела на экране - другая, никак не связанная с этой, задача.
А каким местом думал архитектор, используя parent-child для построения иерархии, если среда не держит рекурсивные CTE? меняйте структуру хранения и переходите на FQpath.
galaxy, гм... нет, получается, что использовать-то он их может, вот только того профита, который обеспечивают покрывающие индексы в других СУБД, не будет, ибо всё одно придётся сбегать в тело таблицы. Битовые карты просто снимают остроту проблемы, делая возможным это обращение только для сравнительно свежих записей, т.е. уменьшая необходимое количество обращений к таблице. А для статической таблицы таких обращений в тело вообще не будет - впрочем, по карте пробежаться придётся, никуда не денешься.
То есть получается, что "PostgreSQL не умеет использовать покрывающий индекс полноценно". Но тем не менее извлекать кое-какой профит из покрывающего индекса он умеет.
Счас немного не до того. Вот тебе для затравки - агрегаты, с которыми надо работать: fiddle. Минимальные пояснения там есть... тебе надо совместить график погашения с фактическими платежами.
Понятие покрывающего индекса никак не связано с СУБД.
Если PostgreSQL не умеет использовать покрывающий индекс, то объясни мне, почему удаление поля из индекса (fiddle) изменяет план и вместо Index Only Scan using idx1 on test пишет Index Scan using idx1 on test. Что сервер подразумевает в первом случае, когда добавляет слово Only? Я воспринимаю это как мне достаточно индекса, все значения я возьму из него, в саму таблицу лазить не потребуется. Это неверно? тогда приведите своё пояснение происходящего.
В PostgreSQL есть частичные индексы
Мне почти очевидно, что значения 0 и 10 в условии Надо найти самую старую по обновленности запись, где n_flag=0 и num_status>=10. - это не константы на веки вечные, а параметры, которые регулярно меняются от вызова к вызову. И второе условие к тому же регулярно меняет оператор - то =, то <=, то вообще BETWEEN... а если это действительно так, то идею с частичным индексом можно смело спускать в унитаз.
Задача в том чтобы одним запросом найти продукты в которых некая подстрока имеет вхождение в name или в description, НО в выдаче в начале должны идти продукты с вхождением в name, а в конце в description
Какой ожидаемый средний процент попадания в каждое поле - по отдельности?
Константин Цветков, ну уж либо UNION DISTINCT, либо UNION ALL .. AND NOT name LIKE '%что-то%'. А одновременно - это какое-то масло масляное получается...