[moved from -general] "Tom Lane" <[EMAIL PROTECTED]> writes:
> The bottom line here is that we have built a partitioning facility > out of spare parts, ie, a very generalized contradiction-proving > section of the planner. That's true but I think the conclusions you reach are a stretch. The main problem with our existing approach is that there's no way to make the kind of deductions we want which depend on an holistic view of all the constraints. So you can't sort the ranges and search them using a binary scan, or join matching partitions from separate tables before appending them, or any number of similar ideas. But I don't see that handling hash or bin partitioning is really going to be so hard with our current scheme. I think we need to have some form of understanding of which functions preserve which btree ordering information in order to make better use of expression indexes anyways. > Eventually we'll have to push an understanding of partitioning down to > some lower level of the system --- that is, if we think it's critical > enough to justify that much effort. If by a lower level of the system you mean the storage manager or anything like that then I definitely don't agree. If on the other hand you just mean a simpler more regular structure than turing-complete constraints then I would agree, but for the reasons above -- not for the problems with hash/bin partitioning and equality semantics. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
