"Julian Mehnle" <julian@xxxxxxxxxx> writes: > However, if I restrict the query to just the partitions that actually do > have data in them ... There are a few things going on here. 1) The optimizer can't build a plan which ignores those partitions because the statistics are just approximations. You could insert into one of them at any time and the statistics won't update immediately. If you have a partition which is empty of some type of data you can put a constraint on it to promise the optimizer that that condition will stay true. 2) The optimizer is assuming that empty tables have a default 1,000 records in them with no idea about their statistics. Otherwise you get terrible plans on tables which have just been created or never analyzed. In this case that's causing it to think there will be tons of matches on what is apparently a very selective criterion. 3) The optimizer is a bit dumb about partitioned tables. But I'm not sure if that's actually the fault here. Try adding one record of data to each of those partitions or putting a constraint on them which will allow constraint_exclusion (I assume you have that enabled?) to kick in. You'll still be bitten by the parent table but hopefully that's not enough to cause a problem. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
