Petascope use of sdom

[Dimitar Misev]

I see this in the logs:

select sdom(c[0:180258,-29295:-27372]) from haiti_vnir AS c

This is an obvious inefficiency, there's no need to call sdom since we already know the domain apparently, if this subset is done: c[0:180258,-29295:-27372]

[Piero Campalani]

I see.
I can look at this in January, if not extremely urgent.
It is mainly about adding a check in the WCS setBounds() function probably.

[Dimitar Misev]

Yes sure; the offending place is probably AbstractFormatExtension:68

[Dimitar Misev]

But we should definitely optimize this somehow, it's doubling evaluation time more or less, e.g. 5s for the sdom and 5s for getting the actual data..

[Piero Campalani]

I agree with you.

I believe the sdom request should actually reside in the DbMetadataSource.read() method when the cellDomain objects are created, whereas the setting the bounds (setBounds()) shouldn't be actually needed since:

• asterisks are allowed in the rasql queries, in case the subsets in the W*S request apply only on a subset of the coverage's dimensions (e.g. `mean_summer_airtemp[0:10,*:*]);
• rasql does not break in case the pixel bounds are outside the range (e.g. mean_summer_airtemp[-10:10,-10:10]=mean_summer_airtemp[0:10,0:10]),
• Petascope anyway knows about the grid-domain ranges (now by means of ps_cellDomain, in new implementations by means of sdom).

This way still a sdom would be thrown for each request, but we might build a cache of coverages metadata that is checked at every DbMetadataSource.read() and refreshed e.g. when the domain extents (ps_domain currently) change ?

[Dimitar Misev]

Yeah that's all good, but also we need to push some optimizations to rasdaman as the problem is that the sdom() function requires evaluation of its arguments in order to compute the result.

E.g. sdom© alone is instant, but sdom(c[*:*,*:*,..]) requires loading c from the database and that's very inefficient.

[Dimitar Misev]

Ok forget about my talk above, it's a bit wrong But your post is valid.

[Piero Campalani]

Ah, I see.. but if sdom(c) is instant, then the extents of the mdd are somewhere in some table right?
Then sdom(c[*:*,...]) as well should just look there when it detects "no operations" to be done like in this case. Whereas it must load the mdd in the remaining cases (e.g. sdom(scale(...))?

[abeccati]

Does not look so critical, unless it slows the show down considerably. Setting prio to minor for now.

[Dimitar Misev]

A 2x slow-down is considerable I'd say. Rasdaman enterprise is not affected because it has some query optimizations, but for community we need to fix petascope.

[Piero Campalani]

We can fix this:

commit fc3a97ba0e43a1546eeb01da543e200c43560797
Author: Piero Campalani <cmppri@unife.it>
Date:   Fri Jan 25 18:16:04 2013 +0100

    Avoid sdom request when updating GetCoverage metadata (ticket #266).