Re: Duplicate WHERE condition changes performance and plan - Mailing list pgsql-performance

From Michael Lewis
Subject Re: Duplicate WHERE condition changes performance and plan
Date
Msg-id CAHOFxGoN1LZoR5Mf-C_OMCDC=_kL1AqfosPgfLOnXUN2--ugNA@mail.gmail.com
Whole thread Raw
In response to Re: Duplicate WHERE condition changes performance and plan  ("singh400@gmail.com" <singh400@gmail.com>)
List pgsql-performance
Why not vacuum analyze both tables to ensure stats are up to date? 

Have you customized default_statistics_target from 100? It may be that 250 would give you a more complete sample of the table without increasing the size of the stats tables too much such that planning time increases hugely.

Do you know if any of these columns are correlated? Custom stats with CREATE STATISTICS may help the planner make better decisions if so.

I usually hesitate to put any boolean field in an index. Do you need the proposal.has_been_anonymised false values only, if so you could add that to a WHERE condition on the index instead of including it as the leading column.

pgsql-performance by date:

Previous
From: Jean-Christophe Boggio
Date:
Subject: Re: Recursive query slow on strange conditions
Next
From: Justin Pryzby
Date:
Subject: Re: Please help! Query jumps from 1s -> 4m