| From: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
|---|---|
| To: | "Albin, Lloyd P" <lalbin(at)scharp(dot)org> |
| Cc: | Dave Johansen <davejohansen(at)gmail(dot)com>, bricklen <bricklen(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Partitions not Working as Expected |
| Date: | 2013-06-27 19:17:40 |
| Message-ID: | 51CC8FD4.10401@optionshouse.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 06/27/2013 01:45 PM, Albin, Lloyd P wrote:
> We have also run into this with our production databases. We worked
> around the issue by adding an index to each child table so that it
> scans all the child index's instead of the child table's. For us
> this made a large performance improvement.
Haha. Yeah, that's assumed. I'd never use a partition set without the
constraint column in at least one index. The proof of concept was just
to illustrate that the planner doesn't even get that far in ignoring
"empty" partitions. Sure, scanning the inapplicable child tables has a
low cost, but it's not zero. With about a dozen of them, query times
increase from 0.130ms to 0.280ms for my test case. Not a lot in the long
run, but in a OLTP system, it can be fairly noticeable.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2013-06-27 19:49:26 | Re: Partitions not Working as Expected |
| Previous Message | Shaun Thomas | 2013-06-27 19:14:34 | Re: Partitions not Working as Expected |