Hi,
I did some further investigation and what I said, above, is a wee bit
wrong.
Looks like my dataset didn't have the datemod field populated, so geoserver
was doing extra work.
If the max visitor (B.a, above) returns null (no result), it will do
(B.b). In most cases "B.b" will NOT be done.
If it does find a max value, the B.c query will look like this;
SELECT "gid",encode(ST_AsBinary(ST_Force2D("geom")),'base64') as "geom"
FROM "public"."my_dataset" WHERE ("datafield" = '2014-05-26' AND
"datafield" IS NOT NULL AND "geom" && <poly>
(this is a point layer, so I expect this is why the simplify is not present)
For most non-database layers this will be a full scan of the data and a
spatial/attribute query.
For the get capabilities (layer Time dimension set to LIST and default=max
value) you will see two queries;
1. unique visitor (Postgis: SELECT DISTINCT ...) to get the LIST of values
2. max visitor (Postgis: SELECT max ...) to get the default value
For most datasets (i.e. non-database), this will be 2 full scans of the
dataset.
Thanks,
Dave
On Mon, Jan 23, 2017 at 12:57 PM, Dave Blasby <dbla...@boundlessgeo.com>
wrote:
> Hi,
>
> I'm just starting looking into some slow downs in geoserver when adding a
> time dimension to a vector layer (i.e. postgis or geogig). By this I mean
> editing the layer, going to the "Dimensions" Tab and "Enabling" Time or
> Elevation.
>
> A. GetCapabilities gets slow. It does a table scan for each
> GetCapabilities request to determine the min/max/unique values of the Time
> attribute (depending on how you set things up on the Layer's dimension's
> tab).
>
> B. GetMap gets slow. I tracked this down to it doing 2 table scans and an
> index scan.
>
> a. It does scan of the data to determine the max time. This is likely
> because the default is to have the max date be the "default" in a query;
>
> SELECT max("datemod") FROM "public"."my_dataset"
>
> b.It does a scan of the data to construct a FID-Time Index for the entire
> dataset (for each getmap request):
>
> SELECT "gid","datemod" FROM "public"."my_dataset"
>
> c. It then does a (normal) index scan to get data required to draw;
>
> SELECT "gid",encode(ST_AsBinary(ST_Simplify(ST_Force2D("geom"), 15.5,
> true)),'base64') as "geom" FROM "public"."my_dataset" WHERE "geom" &&
> <polygon>
>
> I haven't look into this in detail - but there's some obvious ways to make
> this smarter (i.e. caching time values for a layer like we cache extents -
> but that might not be what someone wants).
>
> Has anyone else looked into this? I've seen some earlier discussion, but
> nothing too concrete...
>
> Thanks,
> Dave
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
