Re: Limiting factors of pg_largeobject

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Limiting factors of pg_largeobject
Date: 2003-11-26 22:06:47
Message-ID: 18066.1069884407@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> pg_largeobject uses a loid identifier for the loid. What do we think it
> would take to move that identifier to something like bigint?

Breaking all the client-visible LO APIs, for one thing ...

> I don't really
> know the underlying internals of pg_largeboject but it does seem that
> if we made it have:

> 1. A larger identifier
> 2. An identifier that is not typed to the underlying system (oid)
> 3. The ability to be indexed

> We may benefit. Am I on crack?

I don't see what you're getting at with #2 and #3 at all. OID is
perfectly indexable.

As for #1, it'd theoretically be useful, but I'm not sure about the
real-world usefulness. If your large objects are even moderately
"large" (for whatever value of "large" applies this week), you're not
likely to be expecting to cram 4 billion of them into your database.

If we were doing LOs over for some reason it might be interesting to
consider this, but I think they're largely a legacy feature at this
point, and not worth that kind of effort. It would be better to put the
development effort on creating serial access capability to toasted
fields, whereupon LOs would really be obsolete.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2003-11-26 22:12:50 Re: ALTER COLUMN/logical column position
Previous Message Tom Lane 2003-11-26 21:33:19 Re: pg_restore and create FK without verification check