On Jan 15, 2004, at 6:50 PM, Chris Travers wrote:
>> Would you mind explaining this a little more, or pointing me to where
>> I
>> can learn more about this? I looked through the html docs for TOAST,
>> and only found a brief mention regarding large objects and
>> user-defined
>> types, but it doesn't get into it in very much detail. (Well, there's
>> the sliced bread index entry, also. :)
>
> Tom can correct me if I am wrong, but iirc, there is a limit to how
> much
> information can be stored inline in a table. In order to store larger
> rows,
> these can be compressed or moved out of the table into TOAST.
> PostgreSQL
> needs to be able to know how to handle these issues. TOAST is then
> significant because it allows you to store, say 1GB of text in a field
> without using a large number of pages in the table and thus slowing
> down the
> seq_scan's, and possibly introducing other problems.
Okay. This much I think I follow.
> With complex types, this could become far harder, especially if you
> want to
> move only parts of the complex type into TOAST...
This part I'm not sure I understand. (Again, you're meaning composite
types in general, not complex types (x + yi) in particular, right?). I
did find the TOAST developers site where there's a little more
information about TOAST. What you're saying is that it might be
difficult to figure out how to split a composite type to off-load part
of it onto a TOAST table?
> I would settle for an implimentation that:
> 1: Moved all or none of the entity into TOAST, (i.e. not moving
> individual
> components) as this is not done for other datatypes.
Thus you don't need to figure out how to split it, right?
> 2: Could only do functional indexing of complex types, as this would
> get
> around the issues of display and searching.
> 3: Required explicit casting to simple data types.
Could you give an example of this last one?
Michael Glaesemann
grzm myrealbox com