> Which brings us back to the original issue. If I decide to stick with > the current implementation and not "improve our existing partitioning > mechanisms to scale to 100,000 partitions", I could do something like:
There is a point where you can leave the selection of the correct rows to normal btree indexes. I'd say that that point currently is well below 2000 partitions for all common db systems. I opt, that more partitions will only be useful for very limited use cases, and would be very interested in hearing of a practical partitioning scheme where more partitions still show a performance advantage (any db system). Looks like in your case a partitioning scheme with 256 partitions on one of the 2 dimensions sounds reasonable. Or 32 instead of 256 bins for each dim, if your searches are bidirectional. Andreas ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly