Что заморозили на feature freeze 2019. Часть I. JSONPath

[grufos]

мелкая неточность:

Счастливец Паша может выбирать из 4 квартир. Но стоит изменить 1 букву в запросе — с «П» на «С», и выбора не останется! Подойдет только 1 квартира.

в запросе указан Саша:

FROM house, demands WHERE name = 'Саша';

а в выводе запроса приведены 4 квартиры. Такой вывод подошёл бы если бы в запросе был указан Паша.

[Igor_Le]

да, поправил. спасибо!

[Delf1n]

Планируем реализовать высоконагруженный проект на Postgres.
Если сравнить 3 решения:
1)плоская таблица
2)таблица с 1 JSONPath
3)таблица с несколькими(пусть будет 3) JSONPath
Количество записей ~500 млн

Основная нагрузка — поиск по разным наборам полей, пусть будет (а1 и a1,a2,b1,c1) (где a, b и c — разные JSONPath в п.3 )

У решений 2 и 3 есть возможность достичь такого же быстродействия как и п.1?

[x-wao]

Что такое плоская таблица?

[Delf1n]

Денормализованная

[x-wao]

Заранее трудно сказать, будет ли вариант с JSON быстрее. В простейших случаях -нет, т.к. JSON надо дополнительно парсить, чтобы извлечь значения полей (даже JSONb, хоть он и читается гораздо быстрее). Если поиск по индексу по конкретному набору полей внутри JSON, то надо строить функциональный BTree-индекс по этим полям, скорость работы будет примерно такая же.
JSON делали не для скорости, а для функциональности. Например, в нем можно иметь многоуровневую структуру данных внутри одного поля, а в «плоской» таблице как это сделать? В отдельных случаях JSON ускоряет, если, например, позволяет сократить объем данных, или запихнуть несколько таблиц в одну.

[Delf1n]

Спасибо. Мой пример, я так понимаю, простейший случай.
Да, JSON нужен для удобства, в нашем случае, расширения и возможности сразу его отдавать. Есть некоторые опасения, поэтому рад был бы услышать об опыте на схожих объемах