#postgresql
#postgresql
Вопрос:
У меня есть Postgres 9.4 и я использую функцию json_populate_record с типом, в котором определено 60 столбцов. Таблица с json, old_table, содержит 100 000 записей, и выполнение следующей команды синтаксического анализа и вставки занимает более 2 минут:
select (json_populate_record(null::v_type, row_to_json_output)).*
into new_table
from from old_table
Могу ли я каким-либо образом оптимизировать его? Альтернативы? Более новые версии лучше справляются с этим?
Спасибо
Комментарии:
1. Что такое
row_to_json_output? Это выглядит подозрительно.2. Вы должны показать свой фактический оператор и вывод
EXPLAIN (ANALYZE, BUFFERS)для него. Почему вы хотите использовать JSON?3. «Ограничение (стоимость = 0,00 ..382,50 строк = 1000 ширина = 4508) (фактическое время = 4,429 ..13151,684 строк = 1000 циклов = 1)» » Буферы: общее попадание = 1 чтение = 199″ » -> Сканирование Seq на vsats_json (стоимость = 0,00 ..35643,08 строк = 93184 ширина = 4508) (фактическое время = 4,426 ..13149,898 строк = 1000 циклов = 1) » » Буферы: общий доступ = 1 чтение = 199″ «Время планирования: 0,206 мс» «Время выполнения: 13224,286 мс»
4. На этот раз я запустил его только с 1000, чтобы получить план. Я попытался использовать jsonb / json_populate_record, но производительность была еще хуже. Я думал о наличии одной общей таблицы для аудита, но производительность может заставить меня иметь отдельные таблицы с отдельными полями вместо одного поля со структурой JSON. Спасибо за вашу помощь
Ответ №1:
На мой взгляд, использование jsonb_populate_record со значениями jsonb примерно на 40% быстрее, чем использование json_populate_record со значениями json.
Начиная с версии 11, этот оператор может выполняться параллельно. Однако оценка стоимости функции json_populate_record очень низкая, поэтому, чтобы заставить ее фактически выбрать распараллеливание, вам, вероятно, следует сделать что-то вроде:
alter function json_populate_record cost 1000;
И то же самое с jsonb_populate_record.
Но действительно, почему вы делаете это достаточно часто, чтобы заботиться о том, занимает ли это 2 минуты? Конечно, циклическое перемещение данных взад и вперед между таблицей в json и обратно в таблицу на регулярной постоянной основе, безусловно, не имеет особого смысла.