Re: Planner cost adjustments - Mailing list pgsql-general

From Melvin Davidson
Subject Re: Planner cost adjustments
Date
Msg-id CANu8Fizif767ichcgjXs2mjLOKUgOKoqR8RYP_3zMie-vWWjfQ@mail.gmail.com
Whole thread Raw
In response to Planner cost adjustments  (Daniel Begin <jfd553@hotmail.com>)
Responses Re: Planner cost adjustments
List pgsql-general
I have found that setting

enable_seqscan = off

will remedy that situation. Basically, it forces the planner to choose the index. However, if no correct index is available, it will use sequential scan anyway. The only time it will have a negative effect is if the seqscan is actually faster, which doesn't happen very often.

On Fri, May 29, 2015 at 9:39 AM, Daniel Begin <jfd553@hotmail.com> wrote:

Hi all,

Running some queries, I found that the planner often selects sequential scan instead of an index scan, even if the latter is way faster (one order of magnitude faster if I consider some tests I made by setting enable_seqscan = ON/OFF). How can I figure out what parameter I should adjust to get the planner select an appropriate plan that would better consider my DB setup?

 

I had a look at http://www.postgresql.org/docs/9.3/static/runtime-config-query.html but at this point it is too much information for me;-)  Any rules of thumb, recipes I could use to select which parameters I should look at first?

 

Daniel




--
Melvin Davidson
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Next
From: Tomas Vondra
Date:
Subject: Re: Planner cost adjustments