Re: Query planner wants to use seq scan - Mailing list pgsql-performance

From Bertrand Paquet
Subject Re: Query planner wants to use seq scan
Date
Msg-id CAN1xZsfrZrHTcn9dGSNHpPHMMe81kzC+rZUhuewzrer4cdfrCw@mail.gmail.com
Whole thread Raw
In response to Re: Query planner wants to use seq scan  (Bertrand Paquet <bertrand.paquet@doctolib.fr>)
Responses Re: Query planner wants to use seq scan  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: Query planner wants to use seq scan  (Alex Ignatov <a.ignatov@postgrespro.ru>)
List pgsql-performance
So,

Tonight, the index on the three field is used, may be my yesterday vacuum updated stats.

Thx you for your help.

Regards,

Bertrand




2015-10-27 18:33 GMT+01:00 Bertrand Paquet <bertrand.paquet@doctolib.fr>:
Hi tom,

I did the test yesterday with an index on the three fields, and with a partial index on organization and status and where is null condition on handled. I saw no modification on query plan.
May be I forgot to analyze vacuum after. I will retry tonight. 

I use a btree index. Is it the good solution, even with the In clause ?

Regards,

Bertrand

Le mardi 27 octobre 2015, Tom Lane <tgl@sss.pgh.pa.us> a écrit :
Bertrand Paquet <bertrand.paquet@doctolib.fr> writes:
> We have a slow query. After analyzing, the planner decision seems to be
> discutable : the query is faster when disabling seqscan. See below the two
> query plan, and an extract from pg_stats.

> Any idea about what to change to help the planner ?

Neither one of those plans is very good: you're just hoping that the
Filter condition will let a tuple through sooner rather than later.

If you care about the performance of this type of query, I'd consider
creating an index on (organization_id, status, handled_by) so that all
the conditions can be checked in the index.

                        regards, tom lane

pgsql-performance by date:

Previous
From: Vitalii Tymchyshyn
Date:
Subject: Re: Partition Constraint Exclusion Limits
Next
From: Jim Nasby
Date:
Subject: Re: Partition Constraint Exclusion Limits