Jan Wieck <JanWieck@yahoo.com> writes:
>     For  all  the  default operations, the system would treat the
>     datums still like regular attributes. That means, that an

>         INSERT ... SELECT ...

>     copying a BLOB from one table to another (and that's correct,
>     BLOB's  should  have  copy  semantics) would force the entire
>     BLOB data into memory ... and ...  then ...  after  ...  some
>     ... time ... run out of memory.

This does not seem expensive or difficult to solve.  tuptoaster.c
will be handed a TOAST pointer as part of heap_insert, and it will
know that it has to duplicate the value.  It seems an easy, localized
change to persuade it to do that copying chunk-at-a-time instead of
suck-it-all-in-then-spew-it-all-out.

			regards, tom lane

Wed, 08 Aug 2001 09:45:30 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Question about todo item 
I wrote:
> Tom Lane wrote:
> >
> > Implementation is left as an exercise for the reader ;-).
> >
> > 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
> > is how to provide equivalent functionality (transparent to the client
> > of course) when the particular value you select has *not* been moved
> > out-of-line.  Ideas anyone?
>
>     TOAST  values aren't stored in pg_largeobject. And how do you
>     seek to a position in a compressed and then sliced object? We
>     need  a  way  to  force the object over a streaming interface
>     into uncompressed toast slices first. Let me think  about  it
>     for two days, Okay?
>
>     The  interface  lacks  imho a mode (r/w/rw/a) argument. Other
>     than that I'd like this part.

    The  idea of making BLOB and CLOB simply toast forced special
    datatypes  and  add  streaming  access  functions  lacks  one
    important requirement.

    For  all  the  default operations, the system would treat the
    datums still like regular attributes. That means, that an

        INSERT ... SELECT ...

    copying a BLOB from one table to another (and that's correct,
    BLOB's  should  have  copy  semantics) would force the entire
    BLOB data into memory ... and ...  then ...  after  ...  some
    ... time ... run out of memory.

    We  don't  get  far  without  a real new datatype and special
    support on the heap access level. We should  for  sure  reuse
    the toast shadow table to store the data. But that's the only
    connection to toast here.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Wed, 8 Aug 2001 09:47:55 -0400 (EDT)
Jan Wieck <JanWieck@Yahoo.com>
Re: Question about todo item