Thread: Large objects in one table patch
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
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 ----------------------------------