From: | Michael A Nachbaur <mike(at)nachbaur(dot)com> |
---|---|
To: | Cliff Wells <LogiplexSoftware(at)earthlink(dot)net>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Home-brewed table syncronization |
Date: | 2003-07-09 21:50:32 |
Message-ID: | 200307091450.32440.mike@nachbaur.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Wednesday 09 July 2003 02:28 pm, Cliff Wells wrote:
> On Wed, 2003-07-09 at 14:14, Michael A Nachbaur wrote:
> > So, I'm looking at syncronizing 4 tables from one master database to
> > several child databases. I'm thinking of doing the following with
> > DBD::Multiplex:
> >
> > DELETE FROM TableA;
> > INSERT INTO TableA (..) VALUES (...);
> > ....
> >
> > on all the child databases, but I'm not sure what kind of impact this
> > would have on my servers. My impression is that this would hammer the
> > indexes, and might blow any memory optimization out the window. Only a
> > few records in my dataset will change from time-to-time, but just the
> > process of determining what is different may take more effort than simply
> > rebuilding.
>
> Keep a timestamp associated with each record. Only update the records
> with timestamps later than your last sync.
I'm dealing with an existing database structure that, though I can change it,
has a lot of impact on the rest of my infrastructure. If I can find a way of
doing this without resorting to timestamps, I'd much rather do it that way.
--
/* Michael A. Nachbaur <mike(at)nachbaur(dot)com>
* http://nachbaur.com/pgpkey.asc
*/
"Rome wasn't burned in a day. "
From | Date | Subject | |
---|---|---|---|
Next Message | Jason Earl | 2003-07-09 22:13:56 | Re: Home-brewed table syncronization |
Previous Message | Cliff Wells | 2003-07-09 21:28:57 | Re: Home-brewed table syncronization |