| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Cresswell <pgsql-performance(at)stephen-cresswell(dot)net> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Why is the optimiser choosing a sub-optimal plan? |
| Date: | 2016-11-14 19:37:21 |
| Message-ID: | 20825.1479152241@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Stephen Cresswell <pgsql-performance(at)stephen-cresswell(dot)net> writes:
> I have the a table with two indexes...
(1) Tell us about the other table, mobile_summary_type.
(2) Did you transcribe the second query plan correctly? I have a hard
time believing that EXPLAIN printed two Index Cond lines for the same
indexscan.
(3) What PG version is this, exactly?
(4) Are you doing anything funny like disabling autovacuum/autoanalyze?
The rowcount estimates in the "good" plan seem rather far away from
reality, and it's not obvious why, particularly here:
> -> Seq Scan on mobile_summary_type mst
> (cost=0.00..18.80 rows=880 width=64) (actual time=0.014..0.016 rows=4
> loops=1)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pietro Pugni | 2016-11-14 20:50:38 | Re: Some tuning suggestions on a Red Hat 6.7 - PG 9.5.3 production environment |
| Previous Message | Stephen Cresswell | 2016-11-14 17:53:43 | Why is the optimiser choosing a sub-optimal plan? |