Andres Freund Sent: Thursday, June 21, 2012 5:11 PM > 4.) > Log enough information in the walstream to make decoding possible using only > the walstream.
What I understood is that enough information is catalog data. Is that right or something else? > Advantages: > * Decoding can optionally be done on the master > * No catalog syncing/access required > * its possible to make this architecture independent > Disadvantage: > * high to very high implementation overhead depending on efficiency aims > * high space overhead in the wal because at least all the catalog information In Multiversion approach also, there will be overhead of space to maintain multiple versions irrespective of any approach you use. > needs to be logged in a transactional manner repeatedly Why it needs to be logged repeatedly, once we log the catalog information in WAL, during that time we can disallow/block other DDL's and after that changes to Catalog information can be retrievied from WAL only. > * misuses wal far more than other methods What is the misuse in this, I believe it can be later used for log mining purposes also. > * significant new complexity in somewhat cricital code paths (heapam.c) > * insanely high space overhead if the decoding should be possible architecture > independent The option 4 seems to be better as compare to others w.r.t top level approach to solve the problem. Some other databases also uses similar approach for the use cases similar to what you have described. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers