Re: Large objects in one table patch
От | Denis Perchine |
---|---|
Тема | Re: Large objects in one table patch |
Дата | |
Msg-id | 00101111274323.02713@dyp.perchine.com обсуждение исходный текст |
Ответ на | Re: Large objects in one table patch (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-patches |
> 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 ----------------------------------
В списке pgsql-patches по дате отправления: