Re: Postgres partitions-query scanning all child tables - Mailing list pgsql-performance

From rverghese
Subject Re: Postgres partitions-query scanning all child tables
Date
Msg-id BLU179-W82570C187031578457B014BADA0@phx.gbl
Whole thread Raw
In response to Re: Postgres partitions-query scanning all child tables  (Corey Huinker <corey.huinker@gmail.com>)
List pgsql-performance
Yeah that would be a pain to have the date_part in each query. Thanks for the info!


Date: Thu, 28 Jan 2016 00:48:10 -0700
From: [hidden email]
To: [hidden email]
Subject: Re: Postgres partitions-query scanning all child tables

On Thu, Jan 28, 2016 at 1:10 AM, rverghese <[hidden email]> wrote:
Ok, thanks. Thats a bummer though. That means I need a table for every month/year combination. I was hoping to limit it to 12 tables.

Riya


If you wanted to have a column called month_num or something like that, and if *all* of your queries extract the month date_part() in every where clause, then yes, you could have just 12 tables.

But you won't like that partitioning scheme for other reasons:
- queries that don't "play by the rules" will be slow
- very old data will slow down recent-day queries
- no ability to quickly remove obsolete data by dropping partitions that are no longer useful




If you reply to this email, your message will be added to the discussion below:
http://postgresql.nabble.com/Postgres-partitions-query-scanning-all-child-tables-tp5884497p5884581.html
To unsubscribe from Postgres partitions-query scanning all child tables, click here.
NAML


View this message in context: RE: Postgres partitions-query scanning all child tables
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.

pgsql-performance by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Postgres partitions-query scanning all child tables
Next
From: Albe Laurenz
Date:
Subject: Hash join gets slower as work_mem increases?