Re: Improve EXPLAIN output for multicolumn B-Tree Index

From: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
To: <Masahiro(dot)Ikeda(at)nttdata(dot)com>
Cc: <pgsql-hackers(at)lists(dot)postgresql(dot)org>, <Masao(dot)Fujii(at)nttdata(dot)com>
Subject: Re: Improve EXPLAIN output for multicolumn B-Tree Index
Date: 2024-06-21 15:31:09
Message-ID: 20240622003109.6a4db3d72cd296cc3a89c4c9@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 21 Jun 2024 07:12:25 +0000
<Masahiro(dot)Ikeda(at)nttdata(dot)com> wrote:

> * Is this feature useful? Is there a possibility it will be accepted?

I think adding such information to EXPLAIN outputs is useful because it
will help users confirm the effect of a multicolumn index on a certain query
and decide to whether leave, drop, or recreate the index, and so on.

> * Are there any other ideas for determining if multicolumn indexes are
>
> being used efficiently? Although I considered calculating the efficiency using
>
> pg_statio_all_indexes.idx_blks_read and pg_stat_all_indexes.idx_tup_read,
>
> I believe improving the EXPLAIN output is better because it can be output
>
> per query and it's more user-friendly.

It seems for me improving EXPLAIN is a natural way to show information
on query optimization like index scans.

> * Is "Index Bound Cond" the proper term?I also considered changing
>
> "Index Cond" to only show quals for the boundary condition and adding
>
> a new term "Index Filter".

"Index Bound Cond" seems not intuitive for me because I could not find
description explaining what this means from the documentation. I like
"Index Filter" that implies the index has to be scanned.

> * Would it be better to add new interfaces to Index AM? Is there any case
>
> to output the EXPLAIN for each index context? At least, I think it's worth
>
> considering whether it's good for amcostestimate() to modify the
>
> IndexPath directly as the PoC patch does.

I am not sure it is the best way to modify IndexPath in amcostestimate(), but
I don't have better ideas for now.

Regards,
Yugo Nagata

>
>
>
>
> Regards,
>
> --
>
> Masahiro Ikeda
>
> NTT DATA CORPORATION
>
>

--
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2024-06-21 15:37:54 New standby_slot_names GUC in PG 17
Previous Message Robert Haas 2024-06-21 15:15:34 Re: Meson far from ready on Windows