Postgres Pro
Downloads
Home   >   mailing lists

Thread: AW: Please advise features in 7.1 (SUMMARY)

AW: Please advise features in 7.1 (SUMMARY)

From
Zeugswetter Andreas SB
Date:
> 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 cache2. number of rows you
canread 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

Re: Please advise features in 7.1 (SUMMARY)

From
"Ross J. Reedstrom"
Date:
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

Re: Please advise features in 7.1 (SUMMARY)

From
"Mitch Vincent"
Date:
> 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

Re: Please advise features in 7.1 (SUMMARY)

From
"Magnus Naeslund\(f\)"
Date:
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 NaeslundPGP Key:
http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-