Re: Query analyse

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Elielson Fontanezi <ElielsonF(at)prodam(dot)sp(dot)gov(dot)br>, pgsql-sql <pgsql-sql(at)postgresql(dot)org>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Query analyse
Date: 2003-07-25 19:39:38
Message-ID: 27750.1059161978@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-sql

Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> You're probably ending up with different plans since in one case it has
> a plain column reference and in the other it has a marginally complicated
> expression in the join condition.

Yeah. 7.3 and before cannot do merge or hash joins on conditions that
are any more complex than "var = var". The query with the trunc() is
undoubtedly falling back to the stupidest kind of nestloop.

> As something to try, perhaps make a function that returns
> trunc($1/100000.0)*100000 and index on that function for the column and
> see if that changes the plan you get.

It might help --- you might possibly get a nestloop-with-inner-indexscan
out of that. Not sure though, since the planner is likely to be using
bad guesstimates about the selectivity of the expression.

7.4 should do better on this.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Elielson Fontanezi 2003-07-25 19:43:34 ERROR: DefineIndex: index function must be marked iscachable
Previous Message Elielson Fontanezi 2003-07-25 19:27:45 RES: [SQL] ERROR: DefineIndex: index function must be marked iscachable

Browse pgsql-sql by date

  From Date Subject
Next Message Elielson Fontanezi 2003-07-25 19:43:34 ERROR: DefineIndex: index function must be marked iscachable
Previous Message Elielson Fontanezi 2003-07-25 19:27:45 RES: [SQL] ERROR: DefineIndex: index function must be marked iscachable