| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Query's fast standalone - slow as a subquery. |
| Date: | 2005-03-04 15:22:56 |
| Message-ID: | 27481.1109949776@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | stig erikson | 2005-03-04 15:46:28 | Re: name search query speed |
| Previous Message | Ron Mayer | 2005-03-04 11:27:23 | Query's fast standalone - slow as a subquery. |