Currently, whenever new (or filtered) catalog table is received, we send a request to the server to obtain central and/or corner points for each catalog row. (Search for doFetchTable call in CatalogWatcher.js) These points are then used to compute central point and maximum radius to get the coverage image. (See CatalogWatcher:computeSize.)

For doFetchTable request, we a get a few columns of the WHOLE table, which considerably slows the system when catalog table is huge.

A big improvement would be replacing doFetchTable call with a server call, which takes catalog table request and calculates central point and radius on the server.

Further optimization – if needed in future – could be adding central point and radius into table meta in prepareTableMeta of the search processor when we know it (cone search) or it is easy to calculate (polygon search).