content, format, ctype, or xtype ?

[Tom McGlynn]

Arnold Rots wrote:
> Francois,
> 
> Here is the issue:
> If a user queries a catalog for, say 90 < l <270 AND -30 < b < 30
> you have to do an on-the-fly transformation of almost all your RA,Dec
> entries in order to make sure you get the right subset.
> 
> With storage getting cheaper and cheaper it is far more cost-effective
> to take the hit there and be able to perform the queries very efficiently.
> 
> The only ones you need are (FK4 or FK5 or ICRS) and Galactic and Ecliptic.
> 
>   - Arnold

If you eliminate FK4 from that list (and I don't see need to have high 
performance for queries in that system), then all of the coordinate 
systems are related by simple rotations (at least to within the 
precision that we need for the querying databases).  While you're right 
that disk is getting cheaper, so are CPUs, so that it's not at all clear 
to me what best tradeoff in terms of performance would be.  Large 
queries are often dominated by I/O costs, so slimming down the tables is 
nice.  Does it take longer to read 16 bytes of coordinate information, 
or calculate a few transcendental functions to do the conversion?  If 
you save the coordinates that you can create indices on them, but at 
least for Postgres you can do that on expressions too.

If one defines the appropriate geometric transformations once as stored 
functions or procedures and then one has the ability to query any table 
using the supported coordinate systems without touching them.

I don't know which would turn out to be more efficient.  At the HEASARC 
we've historically gone the approach that Arnold suggests, but that's 
not because we've actually tested the alternative.

The question that I think we should be posing is what capabilities do we 
provide the user in querying the system and in seeing the results.  The 
internals of how one site stores things internally is something that we 
might chat about, but I don't see that it should be mandated or even 
discussed in the standard.

	Regards,
	Tom