Skip site navigation (1) Skip section navigation (2)

Re: Question about todo item

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Barry Lind <barry(at)xythos(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question about todo item
Date: 2001-09-06 20:36:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I have added to TODO:

        o -Add non-large-object binary field (already exists -- bytea)
        o -Make binary interface for TOAST columns (base64)
        o Improve vacuum of large objects (/contrib/vacuumlo)
        o Add security checking for large objects
        o Make file in/out interface for TOAST columns, similar to large object
          interface (force out-of-line storage and no compression)
        o Auto-delete large objects when referencing row is deleted

> Can this be added to the TODO list? (actually put back on the TODO list) 
> Along with this email thread?
> I feel that it is very important to have BLOB support in postgres that 
> is similar to what the commercial databases provide.  This could either 
> mean fixing the current implementation or adding additional capabilities 
> to toasted columns.
> The major problem with the current LargeObject implementation is that 
> when the row containing the LargeObject is deleted the LargeObject 
> isn't.  This can be a useful feature under some circumstances, but it 
> isn't how other databases handle BLOBs.  Thus porting code from other 
> databases is a challenge.  While it is true that this can be worked 
> around through triggers, I don't like the manual nature of the workarounds.
> thanks,
> --Barry
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > 
> >>>Offhand this seems like it would be doable for a column-value that
> >>>was actually moved out-of-line by TOAST, since the open_toast_object
> >>>function could see and return the TOAST pointer, and then the read/
> >>>write operations just hack on rows in pg_largeobject.  The hard part
> >>>
> > 
> >>I am confused how pg_largeobject is involved?
> >>
> > 
> > s/pg_largeobject/toast_table_for_relation/ ... sorry about that ...
> > 
> > 
> >>Don't forget compression of TOAST columns.  How do you fseek/read/write
> >>in there?
> >>
> > 
> > Well, you can *do* it, just don't expect it to be fast.  The
> > implementation would have to read or write most of the value, not just
> > the segment you wanted.  A person who actually expected to use this
> > stuff would likely want to disable compression on a column he wanted
> > random access within.
> > 
> > Hmm ... that provides an idea.  We could easily add some additional
> > 'attstorage' settings that say *all* values of a column must be forced
> > out-of-line (with or without allowing compression), regardless of size.
> > Then, open_toast_object would work reliably on such a column.  One
> > possible user API to such an infrastructure is to invent BLOB and CLOB
> > datatypes, which are just like bytea and text except that they force the
> > appropriate attstorage value.  Ugly as sin, ain't it ... but I bet it
> > could be made to work.
> > 
> > Okay, there's your idea.  Now, who can do better?
> > 
> > 			regards, tom lane
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> > 
> >
> > 
> > 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

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

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-09-06 20:41:33
Subject: Re: Idea for nested transactions / savepoints
Previous:From: Bruce MomjianDate: 2001-09-06 20:11:40
Subject: Re: TRUNCATE question

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group