Re: Speed of locating tables?

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