Sorry for my english. May I ask? (i'm still learning postgresql). Isn't outer join forcing "join order"? The planner will resolve a, then ac in order to resolve left join previously and will not be able to choose the customer_id filter (more selective)... AFAIK (not too far :-)) this will be the join order, even if projects and deparments are not empty, no matter how much statistical info you (the engine) have (has).
Workaround: You should probably try to use a subquery to allow planner to choose join order (as long as you can modify source code :-O ). You know project and department are empty now so... SELECT aa.accno, aa.description, aa.link, aa.category, aa.project_id, aa.department, p.projectnumber, d.description from ( SELECT c.accno, c.description, c.link, c.category, ac.project_id, a.department_id AS department FROM chart c JOIN acc_trans ac ON (ac.chart_id = c.id) JOIN ar a ON (a.id = ac.trans_id) WHERE a.customer_id = 11373 AND a.id IN ( SELECT max(id) FROM ar WHERE customer_id = 11373) ) aa LEFT JOIN project p ON (aa.project_id = p.id) LEFT JOIN department d ON (d.id = aa.department) Doubt of it. I rewrite it at first sight. Long life, little spam and prosperity. -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Chris Travers Enviado el: viernes, 29 de julio de 2005 2:23 Para: Gnanavel S CC: Chris Travers; email@example.com Asunto: Re: [PERFORM] Left joining against two empty tables makes a query > > Secondly, the project table has *never* had anything in it. So where > are these numbers coming from? > > > pg_statistics I very much doubt that. I was unable to locate any rows in pg_statistic where the pg_class.oid for either table matched any row's starelid. Tom's argument that this is behavior by design makes sense. I assumed that something like that had to be going on, otherwise there would be nowhere for the numbers to come from. I.e. if there never were any rows in the table, then if pg_statistic is showing 1060 rows, we have bigger problems than a bad query plan. I hope however that eventually tables which are truly empty can be treated intelligently sometime in the future in Left Joins. Otherwise this limits the usefulness of out of the box solutions which may have functionality that we don't use. Such solutions can then kill the database performance quite easily. Chris Travers Metatron Technology Consulting ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq