Re: At what point does a big table start becoming too big?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Travers <chris(dot)travers(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, 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:18:28
Message-ID: 11389.1345731508@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Chris Travers <chris(dot)travers(at)gmail(dot)com> writes:
> On Thu, Aug 23, 2012 at 6:46 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> 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.

I tend to think of it like this: partitioning means *manually* replacing
the first level of index search.

As such, it is almost never a win for either complexity or performance
of simple searches and updates. As Merlin said, pretty much the only
compelling reason to do it is if you can match up the partition
boundaries with bulk tasks that are common in your application, such as
dropping a month's worth of data at a time.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Gauthier, Dave 2012-08-23 14:19:05 Re: Can column name aliases be supported?
Previous Message Chris Travers 2012-08-23 14:09:40 Re: At what point does a big table start becoming too big?