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 stho...@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
