Re: partitioned table query question

[moved from -general]

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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!