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.
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 |