From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | AlexK <alkuzo(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Should I partition this table? |
Date: | 2014-07-10 18:14:20 |
Message-ID: | 1405016060.56674.YahooMailNeo@web122304.mail.ne1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
AlexK <alkuzo(at)gmail(dot)com> wrote:
> For now, all the data fits in the cache: the box has 384GB of
> RAM. But I want to be ready for later, when we have more data. It
> is easier to refactor my table now, when it is still smallish.
Makes sense.
> Children are only added to recently added parents, and they are
> all added/updated/deleted at once. These child rows represent an
> object which changes as a whole.
>
> Parents are added over time at a steady pace, with increasing ID
> values. But we frequently read history as well as recent rows.
> Also we sometimes remove, always the parent and all its child
> rows.
That suggests to me that a partition based on ranges of parent IDs
would be optimal, with a CLUSTER of each partition as it reaches a
fairly stable state.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | AlexK | 2014-07-10 18:36:27 | Re: Should I partition this table? |
Previous Message | Chris Hanks | 2014-07-10 18:12:56 | Re: Joining on a view containing a UNION ALL produces a suboptimal plan on 9.3.4 |