Hi,
Decibel! wrote:
> Currently, londiste triggers are per-row, not deferred. IIRC, londiste
> is the same. ISTM it'd be much better if we had per-statement triggers
> that could see what data had changed; that'd likely be a lot more
> efficient than doing stuff per-row.
Well, now that I think about it... there might be *lots* of changes.
Certainly something you don't want to collect in memory. At the moment,
Postgres-R cannot handle this, but I plan to add an upper limit on the
change set size, and just send it out as soon as it exceeds that limit,
then continue collecting. (Note for the GCS adept: this partial change
set may be sent via reliable multicast, only the very last change set
before the commit needs to be totally ordered.)
That would mean, introducing another 'change set full' hook...
> In any case, both replication systems should work with either sync or
> eager. I can't see them working with lazy.
Huh? AFAIK, londiste as well as Slony-I are both async. So what would
hooks for sync replication be good for? Why not rather only lazy hooks?
(Well, lazy hooks will pose yet another problem: those theoretically
need to run somewhen *after* the commit, but at that time we don't have
an open transaction, so where exactly shall we do this?)
> What about just making all three available?
Doh. Ehm. That's a lot of work for something we are not even sure it's
good for anything. I'm certainly willing to help. And if other projects
show enough interest, I might even add the appropriate triggers myself.
But as long as this is all unclear, I certainly have more important
things on my todo list for Postgres-R (see that TODO list ;-) ).
> Yeah. I suspect that Postgres-R could end up taking the place of the
> replica-hooks mailing list (and more, of course).
Let's hope so, yeah!
Regards
Markus Wanner
