Re: index speed-up and automatic tables/procedures creation
От | Jean-Yves F. Barbier |
---|---|
Тема | Re: index speed-up and automatic tables/procedures creation |
Дата | |
Msg-id | 4B0F4460.8040302@gmail.com обсуждение исходный текст |
Ответ на | Re: index speed-up and automatic tables/procedures creation (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: index speed-up and automatic tables/procedures creation
|
Список | pgsql-novice |
Greg Stark a écrit : > On Thu, Nov 26, 2009 at 10:19 PM, Jean-Yves F. Barbier <12ukwn@gmail.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.
В списке pgsql-novice по дате отправления: