Thanks to Bill, Andrew and Jan for their advice!

Based on the feedback I have decided on a new solution.

Again, I have a main database and a slon replicated copy that I use
for reporting. But the table I report from is big and unwieldy and I
want to speed up the reports as much as possible.

So I have created a new table that will contain a subset of the rows,
a subset of the columns and in some cases a subset of an individual
column when I don't need the whole column (i.e. my reports only need
the first 200 characters of the description). And I'm maintaining the
new table with triggers.

All works well, I have triggers for INSERT, DELETE and UPDATE and its
maintaining exactly the subset I want. And, since I'm maintaining the
reporting table on the Slon replicated server only, I'm keeping the
main database 'clean'.

Thanks to all for the help!

- Don Barthel


On 4/14/07, Jan Wieck <JanWieck at yahoo.com> wrote:
> On 4/13/2007 6:47 PM, Andrew Hammond 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).
>
> Or leave the triggers in place and pretend to be a slon.
>
>
> Jan