On Tue, Sep 14, 2010 at 06:59:34PM +0200, Peter Körner wrote: > Of hilft es, die Statistik-Erfassung für die betroffenen Spalten zu erhöhen: > > ALTER TABLE ONLY table ALTER COLUMN column SET STATISTICS integer; > > integer > 250 wählen, danach ANALYZE ausführen. > > Oft erkennt dann Postgres, das ein Index-Scan besser wäre.
Ich habe definitiv gegenbeispiele gehabt da hat nichts geholfen ausser das statement anders zu zerlegen. Postgres wollte zur alten index nutzung nicht wieder zurueck. Das das nicht mit dem index sondern dem query planner und entsprechend den statistics auf den tables zusammenhaengt ist klar. Ich hatte joins ueber die way_tags und ways tabelle gemacht und die ways eingeschraenkt ueber ein ST_Intersects mit einem polygon. Postgres hat irgendwann entschieden das es pfiffiger ist erst alle ways mit "highway" zu finden ueber way_tags um dann zu gucken ob ich sie will. Das war - aeh - suboptimal - und vorher gings auch andersherum - d.h. erst selektieren ueber ways dann entsprechende tags raussuchen. Und dank super query optimizer kann man das auch in sub selects zerlegen wie man will - da kommt fast immer das selbe bei raus ;) Ich vermute das nach dem reboot einfach die kosten fuer den table scan auf der way_tags billiger wurden als die kosten fuer irgendwelche random accesses auf einer angenommenen anzahl von ways. Aber ich erwaehnte ja in einem anderen thread schonmal das wir uns den skalierungsgrenzen von SQL und OSM ziemlich schnell annaehern. Es macht sinn sich mal ueber eine spezialisierte OSM DB Gedanken zu machen. Flo -- Florian Lohoff [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
