Re: Tuning resource parameters for a logging database. - Mailing list pgsql-general

From Vick Khera
Subject Re: Tuning resource parameters for a logging database.
Date
Msg-id 2968dfd60905220756l2cc4a989x1fde21d8254b555f@mail.gmail.com
Whole thread Raw
In response to Re: Tuning resource parameters for a logging database.  (Alex Thurlow <alex@blastronetworks.com>)
Responses Re: Tuning resource parameters for a logging database.
List pgsql-general
On Thu, May 21, 2009 at 3:37 PM, Alex Thurlow <alex@blastronetworks.com> wrote:
> I was hoping to not have to change all my code to automate the partitioning
> table creation stuff, but if that's really the best way, I'll check it out.
> Thanks for the advice.

About a 18 months ago we split a large table with 300+ million rows
into 100 partitions.  The query speed was improved by at least 2
orders of magnitude.  Postgres is exceptionally good at dealing with
tables in the 10 million row range, and that's what we gave it.  Our
primary queries on the data were able to go directly to the right
partition, but using constraint exclusion was still nearly just as
fast.

It was totally worth the 10 days or so it took to set up, test (on a
replica!) and migrate the data.  In your case you could have a natural
migration by just adding the child tables and inserting your new data
there and deleting old data from your main table.  After 30 days, your
main table will be empty and you just truncate it, freeing up all the
space.

pgsql-general by date:

Previous
From: artacus@comcast.net
Date:
Subject: Re: Aggregate Function to return most common value for a column
Next
From: Grzegorz Jaśkiewicz
Date:
Subject: Re: question on serial key