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(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