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.

Andrew