[postgis-tickets] [PostGIS] #4635: ST_3DDwithin speed slow down between 2.5 and 3.0
PostGIS
trac at osgeo.org
Wed Mar 25 10:44:19 PDT 2020
#4635: ST_3DDwithin speed slow down between 2.5 and 3.0
----------------------+---------------------------
Reporter: robe | Owner: pramsey
Type: defect | Status: new
Priority: high | Milestone: PostGIS 3.0.2
Component: postgis | Version: 3.0.x
Resolution: | Keywords:
----------------------+---------------------------
Comment (by tomka):
I was just looking into this again and wanted to make the initial query
and the resulting plans a bit simpler, like we did on the mailing list.
Therefore I am basically reposting the last results from a few days ago
into this ticket, so they don't get lost. The test was done in a database
with 50 million geometry entries (simple lines) using 11.7/2.5.3,
12.2/2.5.3 and 12.2/3.0.1. All databases had REINDEX run, VACUUM FULL was
run as well and so was ANALYZE.
This is relevant part of above query:
{{{
EXPLAIN (ANALYZE, BUFFERS)
SELECT te.id, te.parent_id
FROM treenode_edge te
WHERE te.edge &&& ST_MakeLine(ARRAY[
ST_MakePoint(471548.0, 330140.0, 160440.0),
ST_MakePoint(542460.0, 290140.0, 160400.0)] ::geometry[])
AND ST_3DDWithin(te.edge, ST_MakePolygon(ST_MakeLine(ARRAY[
ST_MakePoint(471548.0, 290140.0, 160420.0),
ST_MakePoint(542460.0, 290140.0, 160420.0),
ST_MakePoint(542460.0, 330140.0, 160420.0),
ST_MakePoint(471548.0, 330140.0, 160420.0),
ST_MakePoint(471548.0, 290140.0, 160420.0)]::geometry[])),
20.0)
AND te.project_id = 1;
}}}
And these are the plans for the three different test setups. Since the
result for 11/2.5 and 12/2.5 are basically the same (with all data in
memory), I only post the 12/2.5 plan and the 12/3 plan, each yielding
about 1000 result rows (difference due to very small difference in DB
entries):
12/2.5:
{{{
Index Scan using treenode_edge_gix on treenode_edge te
(cost=0.42..391.68 rows=1 width=16) (actual time=0.936..27.404 rows=1005
loops=1)
Index Cond: (edge &&&
'01020000800200000000000000F0C71C41000000007026144100000000C095034100000000F88D20410000000070B511410000000080940341'::geometry)
Filter: ((edge &&
'0103000080010000000500000000000000A0C71C410000000020B51141000000008094034100000000A0C71C4100000000C0261441000000008094034100000000208E204100000000C026144100000000C095034100000000208E20410000000020B5114100000000C095034100000000A0C71C410000000020B511410000
000080940341'::geometry) AND (project_id = 1) AND
('0103000080010000000500000000000000F0C71C410000000070B51141000000002095034100000000F88D20410000000070B51141000000002095034100000000F88D20410000000070261441000000002095034100000000F0C71C410000000070261441000000002095034100000000F0C71C410000000070B51141000
0000020950341'::geometry && st_expand(edge, '20'::double precision)) AND
_st_3ddwithin(edge,
'0103000080010000000500000000000000F0C71C410000000070B51141000000002095034100000000F88D20410000000070B51141000000002095034100000000F88D20410000000070261441000000002095034100000000F0C71C410000000070261441000000002095034100000000F0C71C410000000070B511410000
000020950341'::geometry, '20'::double precision))
Rows Removed by Filter: 5
Buffers: shared hit=1370
Planning Time: 0.782 ms
Execution Time: 27.518 ms
}}}
12/3:
{{{
Index Scan using treenode_edge_gix on treenode_edge te
(cost=0.67..28.71 rows=1 width=16) (actual time=0.730..163.358 rows=1004
loops=1)
Index Cond: ((edge &&&
'01020000800200000000000000F0C71C41000000007026144100000000C095034100000000F88D20410000000070B511410000000080940341'::geometry)
AND (edge &&&
st_expand('0103000080010000000500000000000000F0C71C410000000070B51141000000002095034100000000F88D20410000000070B51141000000002095034100000000F88D20410000000070261441000000002095034100000000F0C71C410000000070261441000000002095034100000000F0C71C410000000070
B511410000000020950341'::geometry, '20'::double precision)))
Filter: ((project_id = 1) AND st_3ddwithin(edge,
'0103000080010000000500000000000000F0C71C410000000070B51141000000002095034100000000F88D20410000000070B51141000000002095034100000000F88D20410000000070261441000000002095034100000000F0C71C410000000070261441000000002095034100000000F0C71C410000000070B511410000
000020950341'::geometry, '20'::double precision))
Rows Removed by Filter: 5
Buffers: shared hit=6546
Planning Time: 1.312 ms
Execution Time: 163.471 ms
}}}
The only difference is that more pages are hit in 12/3.0 it seems
(Buffers: shared hit
1370 vs 6546). This difference becomes even more apparent after the VACUUM
FULL in 12/3.0 (doesn't change for 11/3.0 after VACUUM FULL):
{{{
Index Scan using treenode_edge_gix on treenode_edge te
(cost=0.67..28.71 rows=1 width=16) (actual time=2.673..206.723 rows=1004
loops=1)
Index Cond: ((edge &&&
'01020000800200000000000000F0C71C41000000007026144100000000C095034100000000F88D20410000000070B511410000000080940341'::geometry)
AND (edge &&&
st_expand('0103000080010000000500000000000000F0C71C410000000070B51141000000002095034100000000F88D20410000000070B51141000000002095034100000000F88D20410000000070261441000000002095034100000000F0C71C410000000070261441000000002095034100000000F0C71C410000000070
B511410000000020950341'::geometry, '20'::double precision)))
Filter: ((project_id = 1) AND st_3ddwithin(edge,
'0103000080010000000500000000000000F0C71C410000000070B51141000000002095034100000000F88D20410000000070B51141000000002095034100000000F88D20410000000070261441000000002095034100000000F0C71C410000000070261441000000002095034100000000F0C71C410000000070B511410000
000020950341'::geometry, '20'::double precision))
Rows Removed by Filter: 5
Buffers: shared hit=8195
Planning Time: 1.209 ms
Execution Time: 207.005 ms
}}}
This reduces the noise a bit and and highlights the plan differences a bit
better then my original query.
--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4635#comment:6>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
More information about the postgis-tickets
mailing list