Re: Speed of locating tables?

This sounds doable. It would probably also remove the problem I have
that unlinks of large objects can't be rolled back.

thanks,
--Barry

Tom Lane wrote:
>
> Barry Lind <barry(at)xythos(dot)com> writes:
> > Does this also mean that if you are using large objects that you really
> > won't be able to store large numbers of large objects in a database?
> > (If I am correct, each large object creates two files, one for the large
> > object and one for it's index.)
>
> Yup.
>
> > If this is true for Large Objects, is
> > there any workaround? The application I am porting from Oracle will be
> > storing on the order of 1,000,000 large objects.
>
> You are going to have some serious problems :-(
>
> There's never been much enthusiasm among the core developers for large
> objects at all --- we see them as a poor substitute for allowing large
> values directly. (The "TOAST" work scheduled for 7.1 will finally
> resolve that issue, I hope.) So no one's felt like working on improving
> the large-object implementation.
>
> If someone did want to work on it, what would probably make sense is to
> eliminate the separate-table-per-object setup in favor of one big table
> holding all the large objects of a database. It'd be easy enough to do;
> the big table would be built just like LO tables are now, but with an
> extra column holding the large object OID associated with each row. And
> you'd add that column to the index of course. You might have to think a
> little about how the existing LO locking semantics should translate into
> that environment, but I see no showstoppers.
>
> (It might've been done the way it was done because there didn't use to
> be support for tables > 2gig, but in the current system I see no reason
> to be afraid of having one big table for LOs instead of many not-so-big
> ones.)
>
> I doubt this would be a big project ... it just needs someone who cares
> enough about large objects to do the work ...
>
> regards, tom lane