Skip site navigation (1) Skip section navigation (2)

Re: What needs to be done for real Partitioning?

From: "Roger Hand" <RHand(at)kailea(dot)com>
To: "Hannu Krosing" <hannu(at)tm(dot)ee>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>,"PFC" <lists(at)boutiquenumerique(dot)com>,"Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: What needs to be done for real Partitioning?
Date: 2005-04-26 19:52:53
Message-ID: DB28E9B548192448A4E8C8A3C1B1E475611A51@sj1-exch-01.us.corp.kailea.com (view raw or flat)
Thread:
Lists: pgsql-performance
On March 21, 2005 8:07 AM, Hannu Krosing wrote:
> On L, 2005-03-19 at 23:47 -0500, Tom Lane wrote:
> > Well, partitioning on the primary key would be Good Enough for 95% or
> > 99% of the real problems out there.  I'm not excited about adding a
> > large chunk of complexity to cover another few percent.
> 
> Are you sure that partitioning on anything else than PK would be
> significantly harder ?
> 
> I have a case where I do manual partitioning over start_time
> (timestamp), but the PK is an id from a sequence. They are almost, but
> not exactly in the same order. And I don't think that moving the PK to
> be (start_time, id) just because of "partitioning on PK only" would be a
> good design in any way.
> 
> So please don't design the system to partition on PK only.

I agree. I have used table partitioning to implement pseudo-partitioning, and I am very pleased with the results so far. Real partitioning would be even better, but I am partitioning by timestamp, and this is not the PK, and I don't wish to make it one.

-Roger

pgsql-performance by date

Next:From: Matthew NuzumDate: 2005-04-26 20:16:57
Subject: speed up query with max() and odd estimates
Previous:From: Steve PoeDate: 2005-04-26 17:49:46
Subject: Re: pgbench Comparison of 7.4.7 to 8.0.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group