Ron Mayer <[EMAIL PROTECTED]> writes:
> -> Seq Scan on points (cost=0.00..444.43 rows=1 width=82) (actual
> time=0.096..132.255 rows=15743 loops=1)
> Filter: (the_geom &&
> '010300000001000000050000009A99999999D95EC0295C8FC2F5A839409A99999999D95EC0F6285C8FC295454048E17A14AE7758C0F6285C8FC295454048E17A14AE7758C0295C8FC2F5A839409A99999999D95EC0295C8FC2F5A83940'::geometry)
> -> Seq Scan on points (cost=0.00..444.43 rows=15794 width=82) (actual
> time=0.067..94.307 rows=15743 loops=1)
> Filter: (the_geom &&
> '010300000001000000050000009A99999999D95EC0295C8FC2F5A839409A99999999D95EC0F6285C8FC295454048E17A14AE7758C0F6285C8FC295454048E17A14AE7758C0295C8FC2F5A839409A99999999D95EC0295C8FC2F5A83940'::geometry)
Apparently the selectivity of the && condition is misestimated in the
first case (note the radically wrong rowcount estimate), leading to an
inefficient join plan choice. I suppose this is a bug in the postgis
selectivity routines --- better complain to them.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
