| From: | Michael Lewis <mlewis(at)entrata(dot)com> |
|---|---|
| To: | "singh400(at)gmail(dot)com" <singh400(at)gmail(dot)com> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pgsql Performance <pgsql-performance(at)lists(dot)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Subject: | Re: Duplicate WHERE condition changes performance and plan |
| Date: | 2020-05-04 17:11:41 |
| Message-ID: | CAHOFxGoN1LZoR5Mf-C_OMCDC=_kL1AqfosPgfLOnXUN2--ugNA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2020-05-04 19:12:01 | Re: Please help! Query jumps from 1s -> 4m |
| Previous Message | Jean-Christophe Boggio | 2020-05-04 16:25:15 | Re: Recursive query slow on strange conditions |