Re: Planner won't use composite index if there is an order by ???? - Mailing list pgsql-performance

From Tom Lane
Subject Re: Planner won't use composite index if there is an order by ????
Date
Msg-id 11004.1209083007@sss.pgh.pa.us
Whole thread Raw
In response to Planner won't use composite index if there is an order by ????  (Dave Cramer <pg@fastcrypt.com>)
List pgsql-performance
Dave Cramer <pg@fastcrypt.com> writes:
> Any idea why it wouldn't choose the right index ?

It thinks that way is cheaper.  It's estimating its cost at 8381,
whereas selecting all the rows then sorting must take 10131 plus
some time to sort.

The reason why those estimates are so far off from reality is directly
tied to the 400-estimated-vs-2-actual rowcount estimation error.
I'm not sure how much of that could be fixed by raising the stats target
for the table, but that's certainly something to try.

Another thing you should look at is eliminating dependences between
columns.  I'll bet that the "scored_at is not null" condition is either
redundant with the "score in ..." condition, or could be made so (ie
force score to null when scored_at is null).  If you could get rid of
the separate test on scored_at, it'd help to avoid the estimation weak
spot of correlated restrictions.

            regards, tom lane

pgsql-performance by date:

Previous
From: Dave Cramer
Date:
Subject: Planner won't use composite index if there is an order by ????
Next
From: Robert Treat
Date:
Subject: Re: Re: [HACKERS] [COMMITTERS] pgsql: Fix TransactionIdIsCurrentTransactionId() to use binary search