Large objects in one table patch

Now that we have TOAST, I wonder if we should just build large objects
on top of that, rather than have all large objects in one file.

Hello all,

As promised.
Here is the patch for large objects in one table.
There's new system table pg_largeobject.
create table pg_largeobject (
loid Oid,
pageno int4,
data bytea
);

It has 2 indices: on (loid) and on (loid,pageno). (Is it neccessary to have
both? Can I search on the second one for loid only?)

BLOB is divided by virtual pages, which is maximum tuple size - some internal data.
Access to the data is based on pageno, which is similar block number on FS.

I am not sure that it is optimized and have no memory/resource leaks. Could
please someone better familiar with postgres review the patch.

It perfectly works with my database.

Patch is against the latest CVS.

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

[ Attachment, skipping... ]

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Now that we have TOAST, I wonder if we should just build large objects
on top of that, rather than have all large objects in one file.

Here the question is in speed. What will be faster? But I better would rely on Jan's opinion about this.

BTW, I ported a patch to the current CVS... And it does not work... Will need
some time to figure out what's wrong.

Hello all,

As promised.
Here is the patch for large objects in one table.
There's new system table pg_largeobject.
create table pg_largeobject (
loid Oid,
pageno int4,
data bytea
);

It has 2 indices: on (loid) and on (loid,pageno). (Is it neccessary to
have both? Can I search on the second one for loid only?)

BLOB is divided by virtual pages, which is maximum tuple size - some
internal data. Access to the data is based on pageno, which is similar
block number on FS.

I am not sure that it is optimized and have no memory/resource leaks.
Could please someone better familiar with postgres review the patch.

It perfectly works with my database.

Patch is against the latest CVS.

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

[ Attachment, skipping... ]

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------