On Thu, 2007-01-11 at 15:01 -0600, Jim C. Nasby wrote:
> 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?
The data demographics usually guides you towards what to do.
You could COPY into
On Thu, Jan 11, 2007 at 12:15:50PM +, Simon Riggs wrote:
> On Wed, 2007-01-10 at 16:00 -0500, Steven Flatt wrote:
> > On 1/9/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > If you are doing date range partitioning it should be fairly
> > simple to
> > load data into the
On Wed, 2007-01-10 at 16:00 -0500, Steven Flatt wrote:
> On 1/9/07, Simon Riggs <[EMAIL PROTECTED]> 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
>
On Wed, Jan 10, 2007 at 04:39:06PM -0500, Steven Flatt wrote:
> On 1/10/07, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> >
> >Except for the simplest partitioning cases, you'll be much better off
> >using a trigger on the parent table to direct inserts/updates/deletes to
> >the children. As a bonus, u
On 1/10/07, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
Except for the simplest partitioning cases, you'll be much better off
using a trigger on the parent table to direct inserts/updates/deletes to
the children. As a bonus, using a trigger makes it a lot more realistic
to deal with an update moving
On 1/9/07, Simon Riggs <[EMAIL PROTECTED]> 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 a
On Mon, Jan 08, 2007 at 03:02:24PM -0500, Steven Flatt wrote:
> We use partitioned tables extensively and we have observed linear
> performance degradation on inserts as the number of rules on the master
> table grows (i.e. number of rules = number of partitions). We had to come
> up with a soluti
On Mon, 2007-01-08 at 15:02 -0500, Steven Flatt wrote:
> On 1/6/07, Colin Taylor <[EMAIL PROTECTED]> wrote:
> Hi there, we've partioned a table (using 8.2) by day due to
> the 50TB of data (500k row size, 100G rows) we expect to store
> it in a year.
> Our performa
On 1/7/07, Colin Taylor <[EMAIL PROTECTED]> wrote:
Hi there, we've partioned a table (using 8.2) by day due to the 50TB of
data (500k row size, 100G rows) we expect to store it in a year.
Our performance on inserts and selects against the master table is
disappointing, 10x slower (with ony 1 par
On 1/6/07, Colin Taylor <[EMAIL PROTECTED]> wrote:
Hi there, we've partioned a table (using 8.2) by day due to the 50TB of
data (500k row size, 100G rows) we expect to store it in a year.
Our performance on inserts and selects against the master table is
disappointing, 10x slower (with ony 1 pa
Colin,
On 1/6/07 8:37 PM, "Colin Taylor" <[EMAIL PROTECTED]> wrote:
> Hi there, we've partioned a table (using 8.2) by day due to the 50TB of data
> (500k row size, 100G rows) we expect to store it in a year.
> Our performance on inserts and selects against the master table is
> disappointing,
Hi there, we've partioned a table (using 8.2) by day due to the 50TB of
data (500k row size, 100G rows) we expect to store it in a year.
Our performance on inserts and selects against the master table is
disappointing, 10x slower (with ony 1 partition constraint) than we get by
going to the part
12 matches
Mail list logo
