Re: Strategies/Best Practises Handling Large Tables - Mailing list pgsql-general

From Chris Travers
Subject Re: Strategies/Best Practises Handling Large Tables
Date
Msg-id CAKt_Zfs64hDKsJTTj0YkYLLE7W38KKbp6pDVJ8edj=U-LcBeTA@mail.gmail.com
Whole thread Raw
In response to Strategies/Best Practises Handling Large Tables  (Chitra Creta <chitracreta@gmail.com>)
Responses Re: Strategies/Best Practises Handling Large Tables  (Chitra Creta <chitracreta@gmail.com>)
List pgsql-general


On Fri, Oct 12, 2012 at 7:44 AM, Chitra Creta <chitracreta@gmail.com> wrote:

Hi,

I currently have a table that is growing very quickly - i.e 7 million records in 5 days. This table acts as a placeholder for statistics, and hence the records are merely inserted and never updated or deleted.

Many queries are run on this table to obtain trend analysis. However, these queries are now starting to take a very long time (hours) to execute due to the size of the table.

I have put indexes on this table, to no significant benefit.  Some of the other strategies I have thought of:
1. Purge old data
2. Reindex
3. Partition
4. Creation of daily, monthly, yearly summary tables that contains aggregated data specific to the statistics required

Does anyone know what is the best practice to handle this situation?


The answer is well, it depends.  Possibly some combination.

One approach I like that may be included in #4 but not necessarily is the idea of summary tables which contain snapshots of the data, allowing you to roll forward or backward from defined points.  This is what I call the log, aggregate, and snapshot approach.   But it really depends on what you are doing and there is no one size fits all approach at this volume.

Instead of reindexing, I would suggest also looking into partial indexes.

Best Wishes,

pgsql-general by date:

Previous
From: Fathi Ben Nasr
Date:
Subject: Re: PostgreSQL Magazine
Next
From: Vincent Veyron
Date:
Subject: Re: PostgreSQL training recommendations?