On 17 June 2013 00:43, Kevin Grittner <kgri...@ymail.com> wrote: >> Especially when one is known to be better than the other already. > > What is the hypothetical technique you're arguing is inferior? For > my own part, I haven't gotten beyond the phase of knowing that to > meet all requests for the feature, it would need to be available at > about the same point that AFTER EACH STATEMENT triggers fire, but > that it should not involve any user-written triggers. Have you > implemented something similar to what you think I might be > considering? Do you have benchmark results? Can you share > details?
Recording the changeset required by replication is known to be more efficient using WAL based extraction than using triggers. WAL writes are effectively free and using WAL concentrates the reads to avoid random I/O in large databases. That would be the most suitable approach for continuously updated matviews, or frequently updates. Extraction using multiple snapshots is also possible, using a technique similar to "concurrently" mechanism. That would require re-scanning the whole table which might be overkill depending upon the number of changes. That would work for reasonably infrequent updates. >> Given that we also want to do concurrent CLUSTER and ALTER TABLE >> ... SET TABLESPACE using changeset extraction I think its time >> that discussion happened on hackers. > > No objections to that here; but please don't hijack this thread for > that discussion. There are multiple features all requiring efficient change set extraction. It seems extremely relevant to begin discussing what that mechanism might be in each case, so we don't develop 2 or even 3 different ones while everybody ignores each other. As you said, we should be helping each other and working together, and I agree. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
