I have a table of several thousand tuples - each tuple has a geometry column. The problem is, these geometries have a large vertex count. The max vertex count is 400, while the average is 200. Obviously "large" is somewhat ambiguous. I "think" that's large, but maybe it's not. For some of these large geometries, I'm considering applying a smoothing algorithm to trim some of the points, IF a performance benefit can be gained.

I'm wondering how these high-vertex polygons affect performance? There is a GIS index on the geometry column. I would think performing an ST_Intersects or other similar functions that are exact would be MUCH slower, whereas a bounding box check, such as the && operator, would be negligibly slower.

In addition, would Postgres store these high-vertex polygons different? I have a basic understanding of the TOAST tables used for "extended" data - I wonder if Postgres would be utilizing this for the large polygons?

As for indexing, there probably isn't much gain, because the index already uses the bounding box for lookup, so whether you have 400 or 5 vertex points, your BB is going to be (roughly) the same, and the lookup will be roughly the same.

Any other considerations?