From: | Steve Atkins <steve(at)blighty(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: how many record versions |
Date: | 2004-05-24 17:51:43 |
Message-ID: | 20040524175143.GA26636@gp.word-to-the-wise.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, May 24, 2004 at 11:15:07AM -0700, Joe Conway wrote:
> Greg Stark wrote:
> >Well this was actually under Oracle, but I can extrapolate to Postgres
> >given
> >my experience.
> >
> >The idea tool for the job is a feature that Postgres has discussed but
> >hasn't
> >implemented yet, "partitioned tables". Under Oracle with partitioned
> >tables we
> >were able to drop entire partitions virtually instantaneously. It also made
> >copying the data out to near-line backups much more efficient than index
> >scanning as well.
>
> I think you can get a similar effect by using inherited tables. Create
> one "master" table, and then inherit individual "partition" tables from
> that. Then you can easily create or drop a "partition", while still
> being able to query the "master" and see all the rows.
I've done this, in production, and it works fairly well. It's not as
clean as true partitioned tables (as a lot of things don't inherit)
but you can localise the nastiness in a pretty small bit of
application code.
Any query ends up looking like a long union of selects, which'll slow
things down somewhat, but I found that most of my queries had date range
selection on them so I could take advantage of that in the application
code to only query some subset of the inherited tables for most of the
application generated queries, while I could still do ad-hoc work from
the psql commandline using the parent table.
Cheers,
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2004-05-24 18:15:07 | Re: how many record versions |
Previous Message | Robert Fitzpatrick | 2004-05-24 17:22:06 | Error building PHP with PostgreSQL support |