Re: Query planner issue with preferring primary key over a better index when using ORDER BY and LIMIT - Mailing list pgsql-general

From Michael Lewis
Subject Re: Query planner issue with preferring primary key over a better index when using ORDER BY and LIMIT
Date
Msg-id CAHOFxGrGWyDQQUSWif_P9XVUKWUng4c7u7CbWGsbXrcXrurxEw@mail.gmail.com
Whole thread Raw
In response to Query planner issue with preferring primary key over a better index when using ORDER BY and LIMIT  (Alan Hodgson <ahodgson@lists.simkin.ca>)
Responses Re: Query planner issue with preferring primary key over a better index when using ORDER BY and LIMIT  (Alan Hodgson <ahodgson@lists.simkin.ca>)
List pgsql-general
What is your default_statistics_target and how accurate is that estimate of 5668 rows? What is random_page_cost set to by the way?

More importantly, what is the better plan that you'd like the planner to use with your existing indexes? It would seem logical to me to scan for the matching shipment_import_id if the estimate is saying 5868 out of 29 million should match and then sort and only get the smallest ID. Doing an index scan on ID and looking up in the table to see if shipment_import_id matches when the planner expects that to be about a .0001 chance... I can't imagine that plan performing well at all.

Certainly a composite index would be very helpful here. Using explain analyze and sharing the output would give more info to go on.

pgsql-general by date:

Previous
From: Alan Hodgson
Date:
Subject: Query planner issue with preferring primary key over a better index when using ORDER BY and LIMIT
Next
From: Rob Sargent
Date:
Subject: Re: Query planner issue with preferring primary key over a better index when using ORDER BY and LIMIT