> 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
----------------------------------
