Re: code question: storing INTO relation

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Michael Paesold <mpaesold(at)gmx(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: code question: storing INTO relation
Date: 2004-10-25 19:49:31
Message-ID: 1098733771.6807.14.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2004-10-23 at 00:29, Greg Stark wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>
> > I agree, hence why this should be a user option. The usage of this is
> > restricted to particular classes of database usage: data warehousing or
> > very large database applications. This isn't intended for use in OLTP or
> > web-site databases.
>
> Well a lot of users also just don't use online backups. For these users
> there's no downside to CREATE INDEX/REINDEX/CREATE TABLE AS not logging.
>

Yes, you're right. I'm just aiming higher, that's all...

A DW with large fact tables will benefit from the optimisation, since
the data loading can often be used to recover the database if required.
Reference data tables don't benefit from the optimization since they are
smaller and much easier to backup/recover. We want to join the fact
tables to the reference data tables, so would like both to exist in a
database that has BOTH PITR and non-logged bulk operations.

The alternative is to have an ODS that uses PITR, alongside a DW that
doesn't, though with data copying from the ODS to the DW. The latter
step is a time-waster I see no reason to encourage.

Anyway... I see no huge agreement with my viewpoint, so I'll just add it
to my own list...

--
Best Regards, Simon Riggs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dennis Bjorklund 2004-10-25 20:08:14 Re: timestamp with time zone a la sql99
Previous Message Bruno Wolff III 2004-10-25 19:40:57 Re: timestamp with time zone a la sql99