From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | "Jean-Yves F(dot) Barbier" <12ukwn(at)gmail(dot)com> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: index speed-up and automatic tables/procedures creation |
Date: | 2009-11-27 00:04:01 |
Message-ID: | 407d949e0911261604y665bba70x203e987142040c0@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
On Thu, Nov 26, 2009 at 10:19 PM, Jean-Yves F. Barbier <12ukwn(at)gmail(dot)com> wrote:
> 1)- I'd like to keep a table in one piece, but it'll be huge (several millions rows
> and growing); can a segmentation of indexes (all indexes that are used for
> searching) speed-up this table scans enough to keep it as responsive to queries as
> multiple tables? And what can I do about the primary key index, which is monolitic?
> (I can't use inheritance as there are some integrity references into it.)
There are plenty of people with tables with many more than several
million records. How big that is depends on how wide those rows are,
but still, it's not necessarily a problem. Indexed access speed should
scale fine.
The real problem that partitioning addresses is routine maintenance.
When it comes time to dump this table or create a new index or even
just scan a large section of the table for a report you may find the
jobs taking impracticably long.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Yves F. Barbier | 2009-11-27 03:15:44 | Re: index speed-up and automatic tables/procedures creation |
Previous Message | Jean-Yves F. Barbier | 2009-11-26 22:19:06 | index speed-up and automatic tables/procedures creation |