|
|
|
Issue Type: |
|
|
Affects Versions: |
2.3.3 |
|
Assignee: |
|
|
Attachments: |
justin_email.txt, original_email.txt |
|
Components: |
PostGIS, WMS |
|
Created: |
16/Aug/13 3:27 PM |
|
Description: |
Opening issue at request of Justin Deoliveira in geoserver list discussion. Naming a layer in Geoserver “Edit Layer” differently from the underlying postgis table (and/or possibly the name of the store) causes aggregate functions such as distinct(), max(), and min() to be omitted from SQL queries supporting GetCapabilities, GetMap, GetFeatureInfo on layers with a time dimension (not sure about elevation dimension). This causes a significant delay as the time dimension (I call it timestamp) from every database row appears to be returned for these requests, rather than distinct timestamps for GetCapabilities and max() timestamp for GetMap and GetFeautreInfo. This issue crops up for GetMap and GetFeatureInfo when one defaults to the default time coordinate in a request rather than specifying it as a parameter. Extensive log excerpts and discussion are provided in attachments. E-mails are from original discussion started 30 Jul 2013 on geoserver mail list. A quick example of the issue, though, is shown below: The underlying postgis table is “latest”, as is the name of the store. If I name the layer “latest” in Geoserver “Edit Layer”, I see the following query upon a GetCapabilities: 12 Aug 16:36:08 DEBUG [org.geotools.jdbc] - CREATE CONNECTION If I rename the layer in Geoserver to something else … “latestxxx”, while leaving the postgis layer & store as “latest”, I see the following query: 12 Aug 16:37:09 DEBUG [org.geotools.jdbc] - CREATE CONNECTION So, the distinct() aggregate does seem to be disappearing if the layer name is not the same as the store/table name. Response slows significantly as all timestamps are returned, not just the distinct ones, when compiling the GetCapabilities response. |
|
Environment: |
Postgres 9.1 |
|
Project: |
|
|
Priority: |
|
|
Reporter: |
Minor