On Thu, 24 Apr 2008, Vlad Arkhipov wrote:
It was written below in my first post: "These queries are part of big query and optimizer put them on the leaf of query tree, so rows miscount causes a real problem. " actual rows count for the first query is 294, estimate - 11; for the second -- 283 and 0. Postgres tries to use nested loops when it should use merge/hash join and vice versa.
The queries are taking less than three milliseconds. You only have three hundred rows in each table. The precise algorithm Postgres uses probably won't make much of a difference. Have you tried turning off the relevant join plans to see how long Postgres takes with your desired plan?
When you have millions of rows, the algorithm matters a lot more. Matthew -- Richards' Laws of Data Security: 1. Don't buy a computer. 2. If you must buy a computer, don't turn it on. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
