[postgis-tickets] [PostGIS] #4362: generic plan slowness

[PostGIS]

#4362: generic plan slowness
-----------------------------+---------------------------
  Reporter:  Taro Matsuzawa  |      Owner:  pramsey
      Type:  defect          |     Status:  new
  Priority:  medium          |  Milestone:  PostGIS 2.5.3
 Component:  postgis         |    Version:  trunk
Resolution:                  |   Keywords:
-----------------------------+---------------------------

Comment (by pramsey):

 Question one: does it still display the fast-fast-fast-fast-fast-slow
 pattern? (Good until execution number six?)
 Question two: if number one is "yes", then for each table in the query,
 can you generate the planned selectivity relative to your query box using
 _postgis_selectivity() and also the *actual* selectivity, by comparing the
 number of rows returned when you query with that box to the number of rows
 in the table?

 The five-fast-then-slow is a symptom of the selectivity estimate for some
 query boxes being overly pessimistic, and overestimating how many rows a
 given box will return.

 I talked about this with your project colleague here at foss4g-na and
 while this is an interesting nit, for your particular usage you will be
 better off just dropping the prepare/execute pattern: your queries are not
 nearly fast enough to reap measurable benefit from stripping out the
 planning overhead.

 That said, I'd still like to confirm if there's some bad selectivity
 estimates being generated for particular combinations of data and query
 key and see if we can rectify that.

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4362#comment:3>
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.