I am trying to run the following query:
SELECT * FROM fences where ST_Intersects(geom, ST_GeomFromText('POINT(-73.990452 40.994184)', 4326))When I run Explain Analyze I get the following:
"Index Scan using fencegeomindex1 on fences (cost=0.41..8.68 rows=1 width=980) (actual time=0.231..0.353 rows=9 loops=1)"" Index Cond: (geom && '0101000020E61000008010C990637F52C06D1ADB6B417F4440'::geometry)"" Filter: _st_intersects(geom, '0101000020E61000008010C990637F52C06D1ADB6B417F4440'::geometry)""Planning time: 0.239 ms""Execution time: 0.393 ms"When I run this query which is using a normal postgresql polygon:
SELECT * FROM fences WHERE poly @> '(-73.990452,40.994184)'I get:
"Bitmap Heap Scan on public.fences (cost=464.69..24194.22 rows=6229 width=980) (actual time=0.058..0.087 rows=9 loops=1)"" Output: fencesid, name, description, customersid, fencetype, fencetypeid, latitude, longitude, minlatitude, maxlatitude, minlongitude, maxlongitude, radius, isactive, trackingon, updateddate, lognotifications, mindwelltime, maxdwelltime, pointdefinitioni (...)"" Recheck Cond: (fences.poly @> '((-73.990452,40.994184))':
olygon)"" Heap Blocks: exact=7"" Buffers: shared hit=14"" -> Bitmap Index Scan on fencepolyindex1 (cost=0.00..463.13 rows=6229 width=0) (actual time=0.042..0.042 rows=9 loops=1)"" Index Cond: (fences.poly @> '((-73.990452,40.994184))':olygon)"" Buffers: shared hit=7""Planning time: 0.094 ms""Execution time: 0.136 ms"From a cost perspective the query using the postgis ST_Intersects appears to be much cheaper however it is taking much longer to plan and then to execute. Any idea why this is happening. I have Vacuumed and Analyzed the table.
أكثر...
SELECT * FROM fences where ST_Intersects(geom, ST_GeomFromText('POINT(-73.990452 40.994184)', 4326))When I run Explain Analyze I get the following:
"Index Scan using fencegeomindex1 on fences (cost=0.41..8.68 rows=1 width=980) (actual time=0.231..0.353 rows=9 loops=1)"" Index Cond: (geom && '0101000020E61000008010C990637F52C06D1ADB6B417F4440'::geometry)"" Filter: _st_intersects(geom, '0101000020E61000008010C990637F52C06D1ADB6B417F4440'::geometry)""Planning time: 0.239 ms""Execution time: 0.393 ms"When I run this query which is using a normal postgresql polygon:
SELECT * FROM fences WHERE poly @> '(-73.990452,40.994184)'I get:
"Bitmap Heap Scan on public.fences (cost=464.69..24194.22 rows=6229 width=980) (actual time=0.058..0.087 rows=9 loops=1)"" Output: fencesid, name, description, customersid, fencetype, fencetypeid, latitude, longitude, minlatitude, maxlatitude, minlongitude, maxlongitude, radius, isactive, trackingon, updateddate, lognotifications, mindwelltime, maxdwelltime, pointdefinitioni (...)"" Recheck Cond: (fences.poly @> '((-73.990452,40.994184))':
olygon)"" Heap Blocks: exact=7"" Buffers: shared hit=14"" -> Bitmap Index Scan on fencepolyindex1 (cost=0.00..463.13 rows=6229 width=0) (actual time=0.042..0.042 rows=9 loops=1)"" Index Cond: (fences.poly @> '((-73.990452,40.994184))':olygon)"" Buffers: shared hit=7""Planning time: 0.094 ms""Execution time: 0.136 ms"From a cost perspective the query using the postgis ST_Intersects appears to be much cheaper however it is taking much longer to plan and then to execute. Any idea why this is happening. I have Vacuumed and Analyzed the table.أكثر...