Re: Jesus, what have I done (was: LONG)

>     around independently.  As you agreed somewhere  else  (on  my
>     TRUNCATE  issue),  it would be better to keep the long values
>     in a per table expansion relation.  Thus, you need the Oid of
>     that too at least. Also, it would be good to know the size of
>     the data before fetching it, so you need that to.
> 

Yes, I guess you could store the size, but the length is known by
looking at the long relation.  We already have an index to get them in
order, so there is no need to load them in random order.


>     The installed base currently  uses  varsize  attributes  with
>     indices  on  them  to  condition, sort and group on them. Now
>     pushing such a field into "secondary" occationally will cause
>     a substantial loss of performance.

We could allow indexes on long values by storing only 4k of the value. 
If there is no other index value with a matching 4k value, the index of
4k length is fine.  If no, you fail the insert with an error.


>     I'd  better like to have another LONG data type, that enables
>     me to store huge string into but where I exactly know what  I
>     can't  do  with, than having some automatic detection process
>     that I cannot force to do what I want. It  happened  just  to
>     often  to me, that these "user friendly better knowing what I
>     might want"  systems  got  me  by  the  ball's.  I'm  a  real
>     programmer,  so  there's  allway  a  way out for me, but what
>     shoud a real user do?

Automatic allows small values to be inline, and long values to be moved
to long tables in the same column.  This is a nice feature.  It
maximizes performance and capabilities.  I can't imagine why someone
would want a LONG column if they can have a column that does both inline
and long automatically and efficiently.

>     No I won't. As explained, I would return a tuple as is,  just
>     with  the  LONG reference information. It will only, but then
>     allways again, be expanded if needed to compare, store  again
>     or  beeing output to the client.  This "allways again" is one
>     of my drawbacks against your "treating all varsize  pushable"
>     concept.  In  one  of  my  early  projects, I had to manage a
>     microVax for a year, and I love  systems  that  can  be  fine
>     tuned  since  then, really! Auto detection is a nice feature,
>     but if that failes and you don't have  any  override  option,
>     you're hosed.

So you expand it when you need it?  That's fine.  We can do that, except
if you are accessing a real in-buffer tuple, and I am not sure you are
going to know that at the time in all routines.  By looking up each time
it is needed and not changing the tuple, you make changes to the system
minimal.  And in my system, you have long entries only when the data
requires it.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026