KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)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

In response to

• Re: Largeobject Access Controls (r2460) at 2010-01-22 05:45:15 from KaiGai Kohei

Responses

• Re: Largeobject Access Controls (r2460) at 2010-01-22 20:46:40 from Kevin Grittner
• Re: Largeobject Access Controls (r2460) at 2010-01-23 07:39:17 from KaiGai Kohei

pgsql-hackers by date

Next:	From: Kevin Grittner	Date: 2010-01-22 20:46:40
	Subject: Re: Largeobject Access Controls (r2460)
Previous:	From: Robert Haas	Date: 2010-01-22 20:09:29
	Subject: Re: review: More frame options in window functions