"Andrew Hammond" <andrew.george.hammond at gmail.com> wrote:
>
> On 4/13/07, Bill Moran <wmoran at collaborativefusion.com> wrote:
> > In response to "Don Barthel" <dbarthel at usedeverywhere.com>:
> >
> > > Hi, I use slony to make a replication copy to run queries against to
> > > offload those from the main database for performance purposes.
> > >
> > > I would like to optimize even further by periodically removing records
> > > from the copy without removing them from the main database.
> > >
> > > Will I upset slony if I do this?
> > >
> > > My main concern is that if I delete from the copy and then later that
> > > record is deleted from the main database, will slony handle the error
> > > gracefully when the DELETE FROM command comes through?
> > >
> > > Thanks in advance!
> > >
> > > I run Postgres 8.0 with Slony 1.1.5
> >
> > This will break Slony.  It may cause data corruption.  It has also been
> > shown to cause cancer in laboratory animals.
> 
> Well, you _might_ be able to do this as long as
> 1) you don't ever try to subscribe another node from your hacked
> subscriber (obviously)
> 2) there are no RI constraint issues
> 3) you're comfortable futzing around with the triggers on your replica
> (you'll need to drop the slony Don't Touch trigger, delete the data,
> and then replace the trigger).
> 
> > A more correct approach would be to reorganize your schema so the unneeded
> > records are in tables that don't get replicated.
> 
> +1 on fixing your design. Consider parent / child tables with CBE and
> then you can simply remove tables you don't need to examine anymore
> from the set.

As an aside on this, I don't entirely feel that this indicates that his
design is "broken" and requires fixing.

One of the things I've been realizing is that planning a database well
is different from planning a database to replicate well.  You have to
make decisions about what data is worth replicating and what is not.
Depending on available resources (bandwidth, etc) you may have to make
tough choices about what you aren't able to replicate, and this may
result in changes to your schema that would seem silly outside the
context of replicated data.

If you design your database without considering replication, and then
try to tack replication on later, it will probably be an inferior
design -- even if it was a good design without replication considered.

The decision to move old records to an "archive" table that doesn't
get replicated is a good example of this, but not the only one.

-- 
Bill Moran
Collaborative Fusion Inc.

wmoran at collaborativefusion.com
Phone: 412-422-3463x4023

****************************************************************
IMPORTANT: This message contains confidential information
and is intended only for the individual named. If the reader of
this message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************