From: | Chris Travers <chris(dot)travers(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Nick <nboutelier(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: At what point does a big table start becoming too big? |
Date: | 2012-08-23 14:09:40 |
Message-ID: | CAKt_ZfsxcSun7T8ZXNRJd11s2RpRhMJvJJbVpLw=HM9ZC1wYQw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Aug 23, 2012 at 6:46 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Wed, Aug 22, 2012 at 6:06 PM, Nick <nboutelier(at)gmail(dot)com> wrote:
>> I have a table with 40 million rows and haven't had any performance issues yet.
>>
>> Are there any rules of thumb as to when a table starts getting too big?
>>
>> For example, maybe if the index size is 6x the amount of ram, if the table is 10% of total disk space, etc?
>
> Well, that begs the question: ...and do what? I guess you probably
> mean partitioning.
>
> Partitioning doesn't reduce index size -- it makes total index size
> *bigger* since you have to duplicate higher nodes in the index --
> unless you can exploit the table structure around the partition so
> that less fields have to be indexed.
Depending on the operation it may make the effective index size bigger
or smaller. For example if querying only one child table your
effective index size is much smaller.
However, if you are worried about that, partial indexes rock :-D
Best Wishes,
Chris Travers
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-08-23 14:18:28 | Re: At what point does a big table start becoming too big? |
Previous Message | Craig Ringer | 2012-08-23 13:52:03 | Re: Can column name aliases be supported? |