Re: many tables in db

Kenneth Been <kennethb(at)telocity(dot)com> writes:
> ... So a one table solution would have a query like

> select stuff from lines where range && query_range

> which would be replaced in the multi-table solution with

> (select stuff from lines_43 where range && query_range)
> union
> (select stuff from lines_46 where range && query_range)

> I can easily store in memory the range (bounding box) for
> each table, so no disk accesses are required to know which
> tables need to be searched.

Hmm. My immediate reaction: if the rtree index can't do that for you a
lot better than you can do it for yourself, then the rtree concept is
seriously flawed, or the implementation needs lots of work. What you're
essentially proposing is to do the top level of rtree indexing yourself.
That should definitely not be a win.

Getting around the not-enough-space-to-cluster problem might take some
creativity, however. I'd suggest that before you spend too much time on
it, you run some experiments on a table with only half the entries, and
see if it's really worth the trouble to try to accomplish the
clustering.

regards, tom lane