Re: Using LIMIT changes index used by planner - Mailing list pgsql-performance

From Tom Lane
Subject Re: Using LIMIT changes index used by planner
Date
Msg-id 16696.1103052917@sss.pgh.pa.us
Whole thread Raw
In response to Re: Using LIMIT changes index used by planner  (Sven Willenberger <sven@dmv.com>)
List pgsql-performance
Sven Willenberger <sven@dmv.com> writes:
> On a related note, is there a way (other than set enable_seqscan=off) to
> give a hint to the planner that it is cheaper to use and index scan
> versus seq scan?

There are basically two things you can do.  One: if the planner's
rowcount estimates are badly off, you can try increasing the stats
targets for relevant columns in hopes of making the estimates better.
A too-large rowcount estimate will improperly bias the decision towards
seqscan.  Two: if the rowcounts are in the right ballpark but the
estimated costs have nothing to do with reality, you can try tuning
the planner's cost parameters to make the model match local reality
a bit better.  random_page_cost is the grossest knob here;
effective_cache_size is also worth looking at.  See the
pgsql-performance archives for more discussion.

>                ->  Index Scan using orderdate_idx on custacct
> (cost=0.00..2657990.68 rows=43297 width=41) (actual
> time=4.432..28145.212 rows=44333 loops=1)

In this case there's already a pretty good match between actual and
estimated rowcount, so increasing the stats targets isn't likely to
improve the plan choice; especially since a more accurate estimate would
shift the costs in the "wrong" direction anyway.  Look to the cost
parameters, instead.

Standard disclaimer: don't twiddle the cost parameters on the basis
of only one test case.

            regards, tom lane

pgsql-performance by date:

Previous
From: Sven Willenberger
Date:
Subject: Re: Using LIMIT changes index used by planner
Next
From: sarlav kumar
Date:
Subject: Query Optimization