> Will anybody want to use this when TOAST comes to be?
1. There's no any TOAST at the moment.
2. For really large objects TOAST will be really inefficient for quite small < 64K other
way around.
> > Here is a patch attached which implement the following strategy of large object handling:
> > 1. There's new system table: pg_largeobject.
> > 2. All large objects are stored inside files not relations.
> > 3. Large objects stored in dir $PGDATA/base/$DATABASE/lo in hashed dirs.
> > Hashing density can be tuned in config.h.in.
> > 4. For search in pg_largeobject we always use index scan.
> >
> > That's all. This strategy is better than existing due to:
> > 1. pg_class, pg_index, pg_attributes system tables are not bloated with large objects.
> > 2. Hashing dir mechanism is faster than lots of files in one dir.
> > 3. Files are much faster than relations. Also we save lots of space on indices.
> >
> > What is not done:
> > 1. Dirs are not removed if there's no any lo's inside. (Is it neccessary???)
> >
> > --
> > Sincerely Yours,
> > Denis Perchine
> >
> > ----------------------------------
> > E-Mail: dyp@perchine.com
> > HomePage: http://www.perchine.com/dyp/
> > FidoNet: 2:5000/120.5
> > ----------------------------------
> >
> > ------------------------------------------------------------------------
> > Name: pgsql.lo.new.patch.gz
> > pgsql.lo.new.patch.gz Type: application/x-gzip
> > Encoding: base64
--
Sincerely Yours,
Denis Perchine
----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------
