Hi, On Thursday, June 21, 2012 04:39:21 PM Simon Riggs wrote: > On 21 June 2012 12:41, Andres Freund <and...@2ndquadrant.com> wrote: > > 3) > > Multi-Versioned catalog > > > > Below are two possible implementation strategies for that concept > > > > Advantages: > > * Decoding is done on the master in an asynchronous fashion > > * low overhead during normal DML execution, not much additional code in > > that path > > * can be very efficient if architecture/version are the same > > * version/architecture compatibility can be done transparently by falling > > back to textual versions on mismatch > > > > Disadvantages: > > * decoding probably has to happen on the master which might not be what > > people want performancewise > > > > 3a) > > Change the system catalogs to be versioned > > > > Advantages. > > * catalog access is easy > > * might be interesting for other users > > > > Disadvantages: > > * catalog versioning is complex to implement > > * space overhead for all users, even without using logical replication > > * I can't see -hackers signing off > > Hmm, there's all sorts of stuff mixed up there in your description. Sure, it tried to compress a complex topic discussed in a long thread ;)
> ISTM we should maintain a lookup table on target system that has the > minimal required information on it. You need just about the whole catalog because the *_out procs might need to lookup types, operators and such again. Unless you want to rewrite those functions you need to provide a normal execution environment. I don't see how your idea works because of that? Am I missing something? Yes, that would be easier if we didn't want to support conversion to text and similar, but I don't see that flying. And even if it would be acceptable you would need to have enough information to construct a btree ScanKey which means you already need a lot of the catalogs. > There is no need to version the whole catalog. (Complete overkill - I > would oppose it ;-) Hey, that originally was your idea :P. But I definitely agree, its not a good idea. Greetings, Andres -- Andres Freund 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
