Re: Very slow query performance when using CTE

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Michael Christofides <[email protected]>
To: Chris Joysn <[email protected]>
Cc: [email protected]
Subject: Re: Very slow query performance when using CTE
Date: Thu, 3 Apr 2025 10:10:07 +0100
Message-ID: <CAFwT4nBzs=iLHg5Q75rA=6AtA=AqqutOS051XzBw3XFt90d1_Q@mail.gmail.com> (raw)
In-Reply-To: <CAKRYhW3K1TbFxYrVvmGfun3cB0R1KCZytZmjk_hY8nFAxVRH=w@mail.gmail.com>
References: <CAKRYhW36jEbPPSPoiPkNcPWdrEXOtdugw9Hyg1poHju7LECHJg@mail.gmail.com>
	<[email protected]>
	<CAKRYhW2bMxD80HeVqQHk2UauZDb1X9CEZ_pVVfRvnsQN3QM9xg@mail.gmail.com>
	<[email protected]>
	<CAKRYhW1kLxq+RG75hxOK0t9Skh4RwsHk6E+JXqQ4NRsadOnRAg@mail.gmail.com>
	<CAKRYhW3K1TbFxYrVvmGfun3cB0R1KCZytZmjk_hY8nFAxVRH=w@mail.gmail.com>

>
> 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

view thread (7+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Very slow query performance when using CTE
  In-Reply-To: <CAFwT4nBzs=iLHg5Q75rA=6AtA=AqqutOS051XzBw3XFt90d1_Q@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox