| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | suganthi Sekar <suganthi(at)uniphore(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: partition pruning |
| Date: | 2019-02-14 14:36:11 |
| Message-ID: | 20190214143611.GG30291@telsasoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, Feb 14, 2019 at 01:37:49PM +0100, Laurenz Albe wrote:
> There is no condition on the table "call_report2" in your query,
> so it is not surprising that all partitions are scanned, right?
Some people find it surprising, since: a.call_id=b.call_id
suganthi Sekar wrote:
> > explain analyze
> > select * from call_report1 as a inner join call_report2 as b on a.call_id=b.call_id
> > where a.call_created_date ='2017-11-01' and '2017-11-30'
Justin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mariel Cherkassky | 2019-02-14 16:09:04 | Re: autovacuum big table taking hours and sometimes seconds |
| Previous Message | suganthi Sekar | 2019-02-14 14:35:12 | Re: constraint exclusion with ineq condition (Re: server hardware tuning.) |