Thread: Query choosing Bad Index Path

Query choosing Bad Index Path

From
Valli Annamalai
Date:
Postgres version: 11.4
Problem:
    Query choosing Bad Index Path. Details are provided below:


Table :






Doubt
   1. Why is this Query choosing Index Scan Backward using table1_pkey Index though it's cost is high. It can rather choose
            BITMAP OR
                  (Index on RECORDID) i.e; table1_idx6
                  (Index on RELATEDID) i.e; table1_idx7

      Below is the selectivity details from pg_stats table
        - Recordid has 51969 distinct values. And selectivity (most_common_freqs) for recordid = 15842006928391817 is 0.00376667
        - Relatedid has 82128 distinct values. And selectivity (most_common_freqs) for recordid = 15842006928391817 is 0.0050666

Since, selectivity is less, this should logically choose this Index, which would have improve my query performance here.

I cross-checked the same by removing PrimaryKey to this table and query now chooses these indexes and response is in 100ms. Please refer the plan below (after removing primary key):
















Attachment

Re: Query choosing Bad Index Path

From
Julien Rouhaud
Date:
Hi,
On Mon, Feb 07, 2022 at 11:36:17AM +0530, Valli Annamalai wrote:
> *Postgres version:* 11.4
> 
> *Problem:*
>     Query choosing Bad Index Path. Details are provided below:
> 
> 
> *Table :*
> 
> 
> 
> 
> 
> 
> *Doubt*
>    1. Why is this Query choosing *Index Scan Backward using table1_pkey
> Index *though it's cost is high. It can rather choose
>             BITMAP OR
>                   (Index on RECORDID) i.e; table1_idx6
>                   (Index on RELATEDID) i.e; table1_idx7
> 
>       Below is the selectivity details from *pg_stats* table
>         - Recordid has 51969 distinct values. And selectivity
> (most_common_freqs) for *recordid = 15842006928391817* is 0.00376667
>         - Relatedid has 82128 distinct values. And selectivity
> (most_common_freqs) for *recordid = 15842006928391817* is 0.0050666
> 
> Since, selectivity is less, this should logically choose this Index, which
> would have improve my query performance here.
> I cross-checked the same by removing PrimaryKey to this table and query now
> chooses these indexes and response is in 100ms. Please refer the plan below
> (after removing primary key):

You already sent the same email less than an hour ago on pgsql-performance
([1]), which is the correct mailing list, please don't post on this mailing
list also.

Note also that sending information as images can be problematic as some people
here (including me) won't be able to see them.  I tried on a web-based MUA and
that's not really better though, as the images are hardly readable and
definitely not grep-able.  You will likely have more answers sending
information in plain text.

[1] https://www.postgresql.org/message-id/CADkhgiJ+gT_FDKZWgP8oZsy6iRbYMYkmRjsPhqhcT1A2KBgcHA@mail.gmail.com