> I guess it depends on what you're using it for -- disk space 
> is cheap and
> abundant anymore, I can see some advantages of having it 
> computed only once
> rather than X times, where X is the number of SELECTs as that 
> could get
> costly on really high traffic servers.. Costly not so much for simple
> computations like that but more complex ones.

Once and for all forget the argument in database technology, that disk space 
is cheap in regard to $/Mb. That is not the question. The issue is:
	1. amout of rows you can cache
	2. number of rows you can read from disk per second
	     (note that it is not pages/sec)
	3. how many rows you can sort in memory

In the above sence disk space is one of the most expensive things in a
database system. Saving disk space where possible will gain you drastic
performance advantages.

Andreas

Tue, 28 Nov 2000 17:19:45 +0100
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: Please advise features in 7.1  (SUMMARY)
On Tue, Nov 28, 2000 at 05:19:45PM +0100, Zeugswetter Andreas SB wrote:
> > I guess it depends on what you're using it for -- disk space 
> > is cheap and
> > abundant anymore, I can see some advantages of having it 
> > computed only once
> > rather than X times, where X is the number of SELECTs as that 
> > could get
> > costly on really high traffic servers.. Costly not so much for simple
> > computations like that but more complex ones.
> 

<snip good arguments about disk space>

As I said in my original post, my understanding of computed fields may
be in error. If they're computed at SELECT time, to avoid creating table
space, then a VIEW is exacly the right solution. However, it's easy to
come up with examples of complex calculations that it would be useful
to cache the results of, in the table. Then, computing at INSERT/UPDATE
is clearly the way to go.

So, having _both_ is the best thing.

Ross

Tue, 28 Nov 2000 10:54:54 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: Please advise features in 7.1  (SUMMARY)
> So, having _both_ is the best thing.

Absolutely, that's always what I meant -- we already have views and views
can do this type of stuff at SELECT time can't they? So it's not a change,
just an addition....

-Mitch


Tue, 28 Nov 2000 10:07:45 -0800
"Mitch Vincent" <mitch@venux.net>
Re: Please advise features in 7.1  (SUMMARY)
From: "Ross J. Reedstrom" <reedstrm@rice.edu>
> On Tue, Nov 28, 2000 at 05:19:45PM +0100, Zeugswetter Andreas SB wrote:
> > > I guess it depends on what you're using it for -- disk space 
> > > is cheap and
> > > abundant anymore, I can see some advantages of having it 
> > > computed only once
> > > rather than X times, where X is the number of SELECTs as that 
> > > could get
> > > costly on really high traffic servers.. Costly not so much for simple
> > > computations like that but more complex ones.
> > 
> 
> <snip good arguments about disk space>
> 
> As I said in my original post, my understanding of computed fields may
> be in error. If they're computed at SELECT time, to avoid creating table
> space, then a VIEW is exacly the right solution. However, it's easy to
> come up with examples of complex calculations that it would be useful
> to cache the results of, in the table. Then, computing at INSERT/UPDATE
> is clearly the way to go.
> 
> So, having _both_ is the best thing.
> 
> Ross
> 

I'm new at this, but the view thing?
Isn't that just the same as:

create table test2 ( i1 int4, i2 int4);
...insert...
select i1,i2,i1+i2 from test2;

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



Wed, 29 Nov 2000 12:07:45 +0100
"Magnus Naeslund\(f\)" <mag@fbab.net>
Re: Please advise features in 7.1  (SUMMARY)