Re: [PERFORM] table partioning performance - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: [PERFORM] table partioning performance
Date
Msg-id 20070111210122.GR36267@nasby.net
Whole thread Raw
In response to Re: [PERFORM] table partioning performance  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
On Thu, Jan 11, 2007 at 12:15:50PM +0000, Simon Riggs wrote:
> On Wed, 2007-01-10 at 16:00 -0500, Steven Flatt wrote:
> > On 1/9/07, Simon Riggs <simon@2ndquadrant.com> wrote:
> >         If you are doing date range partitioning it should be fairly
> >         simple to
> >         load data into the latest table directly. That was the way I
> >         originally
> >         intended for it to be used. The rules approach isn't something
> >         I'd
> >         recommend as a bulk loading option and its a lot more complex
> >         anyway.
> > The problem we have with blindly loading all data into the latest
> > table is that some data (< 5%, possibly even much less) is actually
> > delivered "late" and belongs in earlier partitions.  So we still
> > needed the ability to send data to an arbitrary partition.
>
> Yes, understand the problem.
>
> COPY is always going to be faster than INSERTs anyhow and COPY doesn't
> allow views, nor utilise rules. You can set up a client-side program to
> pre-qualify the data and feed it to multiple simultaneous COPY commands,
> as the best current way to handle this.
>
> --
> Next section aimed at pgsql-hackers, relates directly to above:

I'm wondering if you see any issues with COPYing into a partitioned
table that's using triggers instead of rules to direct data to the
appropriate tables?

BTW, I think improved copy error handling would be great, and might
perform better than triggers, once we have it...
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Recent ecpg patch...
Next
From: Tom Lane
Date:
Subject: Some notes about redesigning planner data structures