<p>Well, replication is arguably a relevant case.<p>For Slony, the origin/master node never cares about logged changes
-that data is only processed on replicas. Now, that's certainly a little weaselly - the log data (sl_log_*) has got to
getread to get to the replica.<p>This suggests, nonetheless, a curiously different table structure than is usual, and I
couldsee this offering interesting possibilities.<p>The log tables are only useful to read in transaction order, which
ispretty well the order data gets written to WAL, so perhaps we could have savings by only writing data to WAL...<p>It
occursto me that this notion might exist as a special sort of table, interesting for pgq as well as Slony, which
consistsof:<p>- table data is stored only in WAL<br /> - an index supports quick access to this data, residing in
WAL<br/> - TOASTing perhaps unneeded?<br /> - index might want to be on additional attributes<br /> - the
triggers-on-log-tablesthing Slony 2.2 does means we want these tables to support triggers<br /> - if data is only held
inWAL, we need to hold the WAL until (mumble, later, when known to be replicated)<br /> - might want to mix local
updateswith updates imported from remote nodes<p>I think it's a misnomer to think this is about having the data not
locallyaccessible. Rather, it has a pretty curious access and storage pattern.<p>And a slick pgq queue would likely
makea good Slony log, too.
