Just as a random performance tip, try reducing your random_page_cost
from 4 to 2 in small increments (0.2?) and see if at any point you get a
better plan and faster response. Also, I assume you've given yourself
enough work_mem and shared_buffers already.
Paul
Mark Cave-Ayland wrote:
On Thu, 2007-07-26 at 11:51 +0000, Alan Cunnane wrote:
I have actually already looked at PG routing however because of the
constraints of this particular project I cannot use it. I have to use
SQL queries as I was attempting however it seems that the query runs
smoothly enough up until the 8th or 9th table is added to the join. Is
this my own fault in the query or is this just the performance of
Postgresql in handling a large number of joins? I do appreciate your
help and advice,
Alan
Tricky :(
I guess the only thing you can do in that case is check the query plans
just before and just after the point at which the query plan
deteriorates and try and spot the difference.
Are you allowed to use stored procedures for your solution? Due to the
recursive-type nature of some of the queries you will need, it may be
possible to come up with something more efficient that way.
HTH,
Mark.
--
Paul Ramsey
Refractions Research
http://www.refractions.net
[EMAIL PROTECTED]
Phone: 250-383-3022
Cell: 250-885-0632
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
