Thread: Query choosing Bad Index Path
Postgres version: 11.4
Problem:Query choosing Bad Index Path. Details are provided below:
Table :Doubt1. 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_idx7Below 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.0050666Since, 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
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