Re: Planner cost adjustments

From: Melvin Davidson <melvin6925(at)gmail(dot)com>
To: Daniel Begin <jfd553(at)hotmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Planner cost adjustments
Date: 2015-05-29 15:22:18
Message-ID: CANu8Fizif767ichcgjXs2mjLOKUgOKoqR8RYP_3zMie-vWWjfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)hotmail(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tomas Vondra 2015-05-29 16:20:26 Re: Planner cost adjustments
Previous Message Tom Lane 2015-05-29 14:17:17 Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1