Re: many tables in db - Mailing list pgsql-general

From Tom Lane
Subject Re: many tables in db
Date
Msg-id 305.995581377@sss.pgh.pa.us
Whole thread Raw
In response to Re: many tables in db  (Kenneth Been <kennethb@telocity.com>)
List pgsql-general
Kenneth Been <kennethb@telocity.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

pgsql-general by date:

Previous
From: missive@frontiernet.net (Lee Harr)
Date:
Subject: Re: Client connection problem...
Next
From: lbayuk@mindspring.com (ljb)
Date:
Subject: Re: Examples of using bytea type