Re: constraint exclusion analysis caching

Andrew Dunstan <andrew@[EMAIL PROTECTED]
> writes:
> Yesterday a client and I were sad to discover that the overhead of 
> constraint exclusion is apparently O(n) in the number of partitions, and

> that where we had ~180 partitions each with a simple constraint (check 
> (field = nnn)) the overhead appeared to amount to about 0.25s on some 
> quite performant hardware, which is way too high for our application. 

I would think that any sort of formal partitioning feature would fix the
problem, because the planner would understand directly about
partitioning instead of having to prove the correctness of not scanning
each one of the other 179 partitions.  The existing feature is cool in
the sense of obtaining useful behavior from generalized spare parts,
but it was never designed or expected to give great planning speed
with large numbers of partitions.  TFM points out that constraint
exclusion cannot scale beyond perhaps a hundred partitions ...

			regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers