Вот структура таблицыПочему таблица тостов не влияет на expay (анализ)?
create table test as
select
lpad('x',100,'x') as a1,
(SELECT array_to_string(ARRAY(SELECT chr((65 + round(random() * 25)):: int) FROM generate_series(1,1024*1024)), '')) as a2
from generate_series(1,5*1024);
Общий размер таблицы 770Kb плюс тост таблицы 5.8Gb
Бежим
explain (analyze, buffers, timing) select a2 from test
"Seq Scan on t1 (cost=0.00..145.20 rows=5120 width=18) (actual time=0.041..2.959 rows=5120 loops=1)"
"Buffers: shared hit=2 read=92"
"Planning time: 1.771 ms"
"Execution time: 3.375 ms"
Что означает тост таблицы не сканируется. Вот почему результат объяснения не соответствует реальному запросу.
Я думаю, это проблема оптимизации планировщика. Нет потребителя данных, нет необходимости их читать. Но результат объяснения, предположим, совпадают (по крайней мере, по таймингам примерно) с реальным запросом.
Являются ли ключевые слова объяснять, анализировать, буферов часть синтаксиса и они вставляются в AST, созданный парсером запросов postgres? Или они вырезаны из запроса, а postgres выполняют остальную часть запроса, но «умеют» получать статистические данные о выполнении?
Если кто-то может подтвердить или объяснить, почему это происходит.
Detoast возможно, но изменить выходные результаты. Этот запрос примитивен, поэтому разница легко заметна. Но то, что сложный запрос и распространение данных не постоянны в таблице. – simar
Я бы сказал, что проблема возникает только для столбцов в списке SELECT. Все промежуточные значения, которые используются в запросе, все равно должны быть взломаны. Поэтому просто присоедините 'length()' к каждому столбцу varlena в списке SELECT. –