KaiGai Kohei <kai...@ak.jp.nec.com> writes: > The attached patch is a revised version.
I'm inclined to wonder whether this patch doesn't prove that we've reached the end of the line for the current representation of blobs in pg_dump archives. The alternative that I'm thinking about is to treat each blob as an independent object (hence, with its own TOC entry). If we did that, then the standard pg_dump mechanisms for ownership, ACLs, and comments would apply, and we could get rid of the messy hacks that this patch is just adding to. That would also open the door to future improvements like being able to selectively restore blobs. (Actually you could do it immediately if you didn't mind editing a -l file...) And it would for instance allow loading of blobs to be parallelized. Now the argument against that is that it won't scale terribly well to situations with very large numbers of blobs. However, I'm not convinced that the current approach of cramming them all into one TOC entry scales so well either. If your large objects are actually large, there's not going to be an enormous number of them. We've heard of people with many tens of thousands of tables, and pg_dump speed didn't seem to be a huge bottleneck for them (at least not in recent versions). So I'm feeling we should not dismiss the idea of one TOC entry per blob. Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers