ДМ
На локале я добавил в эту таблицу
contact_origin varchar NULL и сделал массовый апдейтSize: a a a
2021 March 25
YS
Дмитрий Мачихелян
Да, не выполнял
А что выполняли? Там читается почти в два раза больше данных, хотя примерно такое же количество записей, вот в чём дело.
Тем не менее, на PROD-е настолько быстрее не поэтому (это просто наблюдение), а потому, что я написал в начале https://t.me/pgsql/292760
Тем не менее, на PROD-е настолько быстрее не поэтому (это просто наблюдение), а потому, что я написал в начале https://t.me/pgsql/292760
ДМ
Yaroslav Schekin
А что выполняли? Там читается почти в два раза больше данных, хотя примерно такое же количество записей, вот в чём дело.
Тем не менее, на PROD-е настолько быстрее не поэтому (это просто наблюдение), а потому, что я написал в начале https://t.me/pgsql/292760
Тем не менее, на PROD-е настолько быстрее не поэтому (это просто наблюдение), а потому, что я написал в начале https://t.me/pgsql/292760
На локале я добавил в эту таблицу
contact_origin varchar NULL и сделал массовый апдейтYS
Дмитрий Мачихелян
На локале я добавил в эту таблицу
contact_origin varchar NULL и сделал массовый апдейт» Вы массового UPDATE (всей таблицы или около того) на этом тестовом сервере не выполняли, случайно?
> Да, не выполнял
> и сделал массовый апдейт
Что?!
> Да, не выполнял
> и сделал массовый апдейт
Что?!
ДМ
Ой, извините)
ДМ
Я имел в виду, что на проде не выполнял. А на локале выпонлял. Неправильно прочитал
YS
Дмитрий Мачихелян
На локале я добавил в эту таблицу
contact_origin varchar NULL и сделал массовый апдейтНу вот её и "раздуло", собственно. Т.е. понятно, почему она вдвое больше, по крайней мере.
А в остальном — см. выше.
А в остальном — см. выше.
b
В общем, у меня есть json, в котором динамические рут ключи. Понятное дело, что это уже проблема дизайна, но что есть, то есть.
Соответственно, мне нужно доставать инфу по этим рутовым uuid.
{ "5421bba9-1af5-4bbf-b266-821318040caf": { .. } }Соответственно, мне нужно доставать инфу по этим рутовым uuid.
>
Изворачивайтесь через @>
The default GIN operator class for jsonb supports queries with top-level key-exists operators ?, ?& and ?| operators and path/value-exists operator @>.Изворачивайтесь через @>
ДМ
Yaroslav Schekin
Ну вот её и "раздуло", собственно. Т.е. понятно, почему она вдвое больше, по крайней мере.
А в остальном — см. выше.
А в остальном — см. выше.
А раздутие нужно через vacuum решать?
YS
Дмитрий Мачихелян
А раздутие нужно через vacuum решать?
Можно. Не обязательно нужно.
Если бы проблема была в нём, было бы раза в два медленнее, всего лишь.
Это делается:
если что.
Если бы проблема была в нём, было бы раза в два медленнее, всего лишь.
Это делается:
VACUUM FULL contacts;
VACUUM ANALYZE contacts;
если что.
ДМ
Кстати, я использовал его. Он вроде не особо помог)
YS
Дмитрий Мачихелян
Кстати, я использовал его. Он вроде не особо помог)
Именно так, как я написал выше?
И, ещё раз (в третий? ;) ), и не должен был — основная проблема не в этом.
И, ещё раз (в третий? ;) ), и не должен был — основная проблема не в этом.
ДМ
Yaroslav Schekin
Именно так, как я написал выше?
И, ещё раз (в третий? ;) ), и не должен был — основная проблема не в этом.
И, ещё раз (в третий? ;) ), и не должен был — основная проблема не в этом.
Не, я сейчаас не о проблеме долгого вопроса, а про размер.
vacuum full contacts использовал, размер не особо уменьшился.
Хотя честно могу соврать, вчера ночью использовал vacuum
vacuum full contacts использовал, размер не особо уменьшился.
Хотя честно могу соврать, вчера ночью использовал vacuum
YS
Дмитрий Мачихелян
Не, я сейчаас не о проблеме долгого вопроса, а про размер.
vacuum full contacts использовал, размер не особо уменьшился.
Хотя честно могу соврать, вчера ночью использовал vacuum
vacuum full contacts использовал, размер не особо уменьшился.
Хотя честно могу соврать, вчера ночью использовал vacuum
Если это действительно так — где-то есть что-то ("зависшая" транзакция, или слот репликации и т.п.), что мешает очистке.
KL
>
Изворачивайтесь через @>
The default GIN operator class for jsonb supports queries with top-level key-exists operators ?, ?& and ?| operators and path/value-exists operator @>.Изворачивайтесь через @>
Спасибо, попробую
b
Спасибо, попробую
И есть ещё путь [лёгкого] извращения: вручную проиндексировать ключи.
Запросто может оказаться в разы компактнее и быстрее стандартного индекса за счёт меньшего размера исходных данных.
CREATE FUNCTION jsonb_top_keys (IN x JSONB, OUT keys TEXT[])
IMMUTABLE
AS 'select array_agg(src.k) FROM (SELECT * FROM jsonb_object_keys(x) AS k) AS src'
LANGUAGE SQL;
CREATE INDEX ... USING GIN(jsonb_top_keys(json_column))
SELECT ... WHERE jsonb_top_keys(json_column) && ARRAY['key']Запросто может оказаться в разы компактнее и быстрее стандартного индекса за счёт меньшего размера исходных данных.
KL
И есть ещё путь [лёгкого] извращения: вручную проиндексировать ключи.
Запросто может оказаться в разы компактнее и быстрее стандартного индекса за счёт меньшего размера исходных данных.
CREATE FUNCTION jsonb_top_keys (IN x JSONB, OUT keys TEXT[])
IMMUTABLE
AS 'select array_agg(src.k) FROM (SELECT * FROM jsonb_object_keys(x) AS k) AS src'
LANGUAGE SQL;
CREATE INDEX ... USING GIN(jsonb_top_keys(json_column))
SELECT ... WHERE jsonb_top_keys(json_column) && ARRAY['key']Запросто может оказаться в разы компактнее и быстрее стандартного индекса за счёт меньшего размера исходных данных.
ну я думал про функциональный индекс, но почему-то показалось оверкиллом
KL
У меня в целом в таблице всего 5к+ кортежей, но жсоны могут быть огромными, так что посомтрю, как будет работать
b
ну я думал про функциональный индекс, но почему-то показалось оверкиллом
Мне тоже так казалось, но на моих данных это 192 kB против 7904 kB и Execution time: 12.312 ms против 182.274 ms.
KL
хмммм