Re: Planner cost adjustments
I have found that setting
enable_seqscan = off
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.
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
В списке pgsql-general по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1