From: | "Jean-Yves F(dot) Barbier" <12ukwn(at)gmail(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: index speed-up and automatic tables/procedures creation |
Date: | 2009-11-27 03:15:44 |
Message-ID: | 4B0F4460.8040302@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Greg Stark a écrit :
> 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.
Sooo, I guess the answer is: cut your table by pieces=year?
--
<Overfiend> ltd: Fine, go through life just pointing and grunting at
what you mean. Works for Mac users.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-11-27 03:58:22 | Re: index speed-up and automatic tables/procedures creation |
Previous Message | Greg Stark | 2009-11-27 00:04:01 | Re: index speed-up and automatic tables/procedures creation |