RE: A Data Reduction Proposal

["Richard Klappal" <klappal@xnet.com>]

Converting RA to sin & cos of the angle makes it a continuous function so
that you don't have to handle a 360-0 roll-over.  Admitted, it does add
overhead, but that should be significant only during initial data load.
Even as sin & cos, they could be scaled into integer ranges so that we
aren't doing floating point comparisons.  Throwing out the decimal point and
storing the rest as long int shouldn't cause a problem.

Richard



-----Original Message-----
From: owner-tass@listserv.wwa.com [mailto:owner-tass@listserv.wwa.com]On
Behalf Of Creager, Robert S
Sent: Monday, February 04, 2002 17:59
To: 'Chris Albertson'; Mark Pitts; tass@listserv.wwa.com
Subject: RE: A Data Reduction Proposal



Hey Chris,

I'll work on making my database huge, and see what happens.  In the next
week or so (hopefully), I'll get cycles of import/merge/use with random data
and see when/how performance breaks down.  I will attempt to use real
looking data (maybe perturbing one data set) so stuff 'makes sense'.

> One "got ya" that I found was that you should _not_ experiment
> with small numbers of records.  THere is a big "knee" in the
> performance graph when the data gets to big to cache in RAM.
> I found I needed a random data generator to populate a few
> table million rows.

I like your type idea, as this should get around the problem having 0,15 not
being near to 359.99,15 without doing multiple selects.  I'd thought about
this previously, but never did anything.

>
> I think we should just bite the bullet and go with Postgresql.
> It runs on every platform and OS under the sun, is free and
> is fully featured.  Doing this allows us to use Postgresql-
> specific extensions such as user defined data type and
> functions.  For example I would like to define an RA and DEC
> pair as a type.
>

Rob