Re: Very slow query performance when using CTE

Поиск
Список
Период
Сортировка
От Michael Christofides
Тема Re: Very slow query performance when using CTE
Дата
Msg-id CAFwT4nBzs=iLHg5Q75rA=6AtA=AqqutOS051XzBw3XFt90d1_Q@mail.gmail.com
обсуждение исходный текст
Ответ на Fwd: Very slow query performance when using CTE  (Chris Joysn <joysn71@gmail.com>)
Ответы Re: Very slow query performance when using CTE
Список pgsql-performance
CREATE STATISTICS st_simrun_component_metadata (dependencies) ON sim_run_id, key FROM sim_run_component_metadata;
ANALYZE sim_run_component_metadata;

When I run this query, no statistics are returned:

SELECT m.* FROM pg_statistic_ext join pg_statistic_ext_data on (oid = stxoid),

pg_mcv_list_items(stxdmcv) m WHERE stxname = 'st_simrun_component_metadata';


Is there something I might have missed?

It looks like you created "dependencies" statistics, but then searched for "mcv" statistics. To test if mcv helps, you could drop and recreate as: CREATE STATISTICS st_simrun_component_metadata (mcv) ... 

The fetch from the table is rather fast. some milliseconds. But a subsequent sort operations takes very long time, for the amount of records fetched.

This does not seem to be the case for the slow cases you shared (those are dominated by several millisecond index scans that are looped over 32k times). So I assume you're talking about the fast case? If so, there is a Sort that takes a couple of hundred milliseconds being done on disk (~15MB) so you might also want to look into how fast that would be in memory (via work_mem).
 
But, just like the estimated rows in the plan, it does not match the real amount of available data in the table:

I'm not sure what you mean by this, is it only that the row estimates are still bad?

Regards,
Michael

В списке pgsql-performance по дате отправления: