Re: Showing applied extended statistics in explain Part 2

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Tatsuro Yamada <yamatattsu(at)gmail(dot)com>, Masahiro(dot)Ikeda(at)nttdata(dot)com
Cc: tomas(dot)vondra(at)enterprisedb(dot)com, tatsuro(dot)yamada(at)ntt(dot)com, pgsql-hackers(at)postgresql(dot)org, Masao(dot)Fujii(at)nttdata(dot)com
Subject: Re: Showing applied extended statistics in explain Part 2
Date: 2025-01-24 10:17:41
Message-ID: d480e486-4f90-45a6-8bf9-faf5db7e4899@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/1/24 12:22, Tatsuro Yamada wrote:
> Hi All,
>
> I apologize for not being able to continue development due to various
> circumstances.
> The attached file is the rebased patch.
> I will now catch up on the discussion and try to revise the patch.
I wonder why it’s so important to know exactly where and who has used
extended statistics.

I often use SQL Server to compare execution plans generated by
PostgreSQL, and I appreciate how they display the usage of extended
statistics. They clearly identify which statistics were utilized during
query planning and include them in the summary section of query plan.

I find this method much easier to implement, as it allows us to see any
usage points - remember that `estimate_num_groups` may be applied in
multiple places and may not always correspond to a node clause.

It’s worth noting that some clauses may be transformed during the
planning process, and the scan filter may not align with the estimated
clause. It’s possible that certain clauses might not appear in the final
estimated plan based on the extended statistics.

If necessary, we could add an `extstat_ID` to the summary to reference
it in the plan nodes.

--
regards, Andrei Lepikhov

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Benoit Lobréau 2025-01-24 10:32:52 Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch)
Previous Message Lukas Fittl 2025-01-24 09:59:00 Re: [PATCH] Optionally record Plan IDs to track plan changes for a query