<div dir="ltr">Hi Dan,<br><div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-25 18:47 GMT+02:00 Dan Lyke <span dir="ltr"><<a href="mailto:danlyke@flutterby.com" target="_blank">danlyke@flutterby.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm trying to figure out a performance issue between two quarters of<br>
map data. Both are using PosgreSQL 9.5.4 on Amazon RDS. The current<br>
quarter's data appears to be much slower than the old quarter's data.<br>
<br>
VACUUM ANALYZE has been run.<br>
<br>
EXPLAIN ... on the old data is doing a:<br>
<br>
->  Bitmap Heap Scan on foo_line (cost=<a href="tel:50.85..5380.25" value="+15085538025">50.85..5380.25</a> rows=1346<br>
width=306)<br>
    Recheck Cond: (way && '...'::geometry)<br>
    Filter: (highway IS NOT NULL)<br>
    ->  Bitmap Index Scan on foo_index  (cost=0.00..50.52 rows=1346<br>
width=0)<br>
        Index Cond: (way && '...'::geometry)<br>
<br>
<br>
And on the new data:<br>
<br>
->  Index Scan using foo_index on foo_line  (cost=0.55..1346.36<br>
rows=332 width=304)<br>
    Index Cond: (way &&  '...'::geometry)<br>
    Filter: (highway IS NOT NULL)<br>
<br>
Which looks to me like it's doing the filter before the Bitmap Index<br>
Scan?<br></blockquote><div><br></div><div>Actually, the planner is choosing a different strategy for query execution.<br><br></div><div>On old dataset, the index is scanned through the bitmap: there are two<br></div><div>phases, in the first the index is used to build a bitmap, then the query<br></div><div>bases to find matching entries through the bitmap itself. This strategy<br></div><div>is generally chosen if the index scan would involve several accesses<br></div><div>on same blocks of the indexes.<br><br></div><div>On new dataset, a simple index scan is executed, avoiding the bitmap<br></div><div>index/heap scan. This is generally faster if index blocks are singularly<br></div><div>accessed.<br><br></div><div>Basing on planner estimations attached in yours EXPLAIN outputs,<br></div><div>this could be indeed the case: on old datasets, the planner estimates<br></div><div>an higher numbers of involved records by the query execution through<br></div><div>the index scan (1346 vs. 332), and an higher cost in terms of inspected<br></div><div>index blocks (5380 vs. 1346), so the bitmap strategy is chosen.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In either case, the new database is substantially slower than the old<br>
database, and I need to fix that, and I'm down to asking strangers on<br>
the Internet while I continue to Google around for solutions.</blockquote></div><br><div>Could you provide further details in what could be changed between<br></div>old and new datasets? Is the content significantly changed (bounds of<br></div><div class="gmail_extra">geometries, etc.)?<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Furthermore, it could be useful also to have attached the output of the<br></div><div class="gmail_extra">EXPLAIN ANALYSE command, in order to compare what the planner<br></div><div class="gmail_extra">estimates with what it actually do.<br><br></div><div class="gmail_extra">Hope this helps,<br></div><div class="gmail_extra">Giuseppe.<br></div></div></div>