Было бы неплохо, но уже так собирается, и, думаю, не изменится. Нестрашно, буду разбирать это, и нормально

и если будете пробовать с json работать, то сразу используйте jsonb

он продвинутый

попробую, спасибо

Вот UNNEST нормально сопоставляет пары:

WITH source_table (id, ppk1, ppk2) AS (
 VALUES  (1, ARRAY['GoogleClientID', 'LeadDriveID', 'transactionId'], ARRAY['567865786.undefined', '457689jgitrjhg8495uy', '83c20a25-4772-4a77-b40d-7e73f95cf012']),
   (2, ARRAY['goalAction', 'goalValue', 'GoogleClientID', 'LeadDriveID', 'GoogleClientID', 'transactionId'], ARRAY['send', '', '984830011.590487419', 'Bddnjldfbnjfd','32523563.231532523', '26c176f3-d2f4-438c-a8bb-3e7d2545a890'])
)
SELECT  id, UNNEST(ppk1), UNNEST(ppk2)
FROM  source_table;

Есть нюанс: jsonb убирает дубликаты ключей, а json - нет. В исходных данных в ключах есть дубликаты, поэтому надо или json, или что-то придумывать.

json не может иметь дубликаты ключей по спецификации.

По спецификации - не может. Но pg хранит json как текст и не проверяет это условие.

Может иметь по спецификации. Хотя в RFC сказано, что это не рекомендуется.

Подскажите, для каких целей можно использовать повторение ключей в JSON?

Привет. Забавная ситуация, когда limit меняет всё. У меня есть запрос. Он достаточно большой, могу выдать).  Так вот для маленького значения limit (4) этот запрос выполняется 2-3 секунды. Для большего (50)  - около 30 миллисекунд. Есть gin индекс с триграммами и  b-tree индекс по тому же полю (он тоже нужен!)  и поиск по ilike '%blabla%' в запросе. Так вот для лимит 4 он делает Index Scan по btree, а для 50 - индекс скан по gin, разница в костах примерно на 3 порядка. Статистика актуальна. Не могу понять, как так и как лечить

Конечно же ни для каких. Конечно же в реальной жизни это бред. Но вопрос касался спецификации. Могу ошибаться, но в RFC был описан алгоритм получения одного значения среди дубликатов.

> Забавная ситуация, когда limit меняет всё

И это нормально.

> Так вот для лимит 4 он делает Index Scan по btree, а для 50 - индекс скан по gin

Значит, такие оценки.

> Не могу понять, как так и как лечить

Покажите полную версию PostgreSQL, \d таблиц, запросы и планы (EXPLAIN (ANALYZE, BUFFERS).
Последние можно на https://explain.depesz.com/

Plan limit 4
https://explain.depesz.com/s/6GOE
Plan limit 50
https://explain.depesz.com/s/h1bk

tables definition
http://pastie.org/p/0yj9NVUSsZftGxyrv7JkGK

Query
http://pastie.org/p/3ab2JoQp54R8lyvaSrDfPf
Там сейчас limit 4 (первый план), если поставить лимит 50, то включается второй план

Часть  запроса может выглядеть дико, но так как это генерит EF, то я не могу заставить девов все их переделать.

Не увидел версии  PostgreSQL...

Ну а так — в оценке селективности условия (("Subject")::text ~~* '%55681%'::text) (и стоимости использования индексов и так далее) дело, казалось бы.
Насколько она вообще соответствует реальности?

11.7

А можно вообще дать оценку селективности на btree, когда поиск по середине строки

?

С помощью MCV, если я правильно помню.
Так Вы проверьте, всё же.
Т.е.

EXPLAIN SELECT * FROM messages."Message" AS m WHERE ("Subject")::text ~~* '%55681%'::text;
-- против
SELECT COUNT(*) FROM messages."Message" AS m WHERE ("Subject")::text ~~* '%55681%'::text;

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

"Bitmap Heap Scan on "Message" m  (cost=165.55..935.56 rows=200 width=254)"
"  Recheck Cond: (("Subject")::text * '%55681%'::text)"
"  ->  Bitmap Index Scan on trgm_idx_message_subject  (cost=0.00..165.50 rows=200 width=0)"
"        Index Cond: (("Subject")::text * '%55681%'::text)"
vs
60
в каунте