| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Cory Tucker <cory(dot)tucker(at)gmail(dot)com> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Bad Query Plans on 10.3 vs 9.6 |
| Date: | 2018-03-29 15:25:57 |
| Message-ID: | 28562.1522337157@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Cory Tucker <cory(dot)tucker(at)gmail(dot)com> writes:
> relallvisible has a value of 0 for that table on both databases.
That would result in IOS being estimated at the same cost as a regular
indexscan, I believe, or very close to that anyway.
Is the 10.3 plan parallelized at all? It's possible that the planner
thinks a parallel seqscan is faster than a nonparallel indexscan
(AFAIR, v10 doesn't have parallel indexscan).
The other likely explanation is simply that indexscanning a partitioned
table is not considered, or not correctly costed. I'm not very sure what
the state of that code is, but certainly all the v10 partitioning logic is
still pretty wet behind the ears.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvar Freude | 2018-03-29 17:24:26 | Re: Question about buffers_alloc in pg_stat_bgwriter view for monitoring |
| Previous Message | Ravi Krishna | 2018-03-29 15:21:36 | Question about AWS Calculator |