Given that all the point intersection queries are executed with srid of 3857:
|
SELECT |
|
${geometry} AS center, |
|
1 AS size, |
|
0 AS clusterNo, |
|
${maxZoomLevel + 1} AS expansionZoom${attributes} |
|
FROM ${table} |
|
WHERE |
|
ST_Intersects(TileBBox(${z}, ${x}, ${y}, 3857), ST_Transform(${geometry}, 3857)) |
|
${query.length > 0 ? `AND ${query.join(' AND ')}` : ''} |
A standard spatial index on the point geometry column won't be used (unless maybe the points are stored in 3857, but most I suspect are probably 4326). However regardless of srid on the geometry column, we can always add an expression (functional) index:
CREATE INDEX mytable_geom_3857_idx on mytable USING gist (ST_Transform(geom, 3857));
Which will of course speed up ST_INTERSECTS queries for all the tile requests.
PS - Was https://github.com/datalanche/node-pg-format or similar considered to more safely create parameterized queries?
Given that all the point intersection queries are executed with srid of 3857:
clusterbuster/lib/queries/base.ts
Lines 16 to 24 in a47d246
A standard spatial index on the point geometry column won't be used (unless maybe the points are stored in 3857, but most I suspect are probably 4326). However regardless of srid on the geometry column, we can always add an expression (functional) index:
Which will of course speed up ST_INTERSECTS queries for all the tile requests.
PS - Was https://github.com/datalanche/node-pg-format or similar considered to more safely create parameterized queries?