Re: Followup - expression (functional) index use in joins - Mailing list pgsql-performance

From Tom Lane
Subject Re: Followup - expression (functional) index use in joins
Date
Msg-id 18733.1069891765@sss.pgh.pa.us
Whole thread Raw
In response to Re: Followup - expression (functional) index use in joins  (Roger Ging <rging@paccomsys.com>)
Responses Re: Followup - expression (functional) index use in joins  (Roger Ging <rging@paccomsys.com>)
Re: Followup - expression (functional) index use in joins  (Roger Ging <roger@musicreports.com>)
List pgsql-performance
Roger Ging <rging@paccomsys.com> writes:
> Ran vacuum analyse on both program and logfile tables.  Estimates are
> more in line with reality now,

And they are what now?  You really can't expect to get useful help here
when you're being so miserly with the details ...

FWIW, I suspect you could force 7.4 to generate 7.3's plan by setting
enable_mergejoin to off (might have to also set enable_hashjoin to off,
if it then tries for a hash join).  7.3 could not even consider those
join types in this example, while 7.4 can.  The interesting question
from my perspective is why the planner is guessing wrong about the
relative costs of the plans.  EXPLAIN ANALYZE results with each type of
join forced would be useful to look at.

            regards, tom lane

pgsql-performance by date:

Previous
From: LIANHE SHAO
Date:
Subject: Re: very large db performance question
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: For full text indexing, which is better, tsearch2 or