| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Kyle Bateman <kyle(at)actarg(dot)com> | 
| Cc: | pgsql-sql(at)postgresql(dot)org, merrill(at)actarg(dot)com | 
| Subject: | Re: Index not used in functions in 7.0? | 
| Date: | 2000-05-16 19:11:56 | 
| Message-ID: | 14055.958504316@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-sql | 
Kyle Bateman <kyle(at)actarg(dot)com> writes:
> create function summtr_ocpt2(text, int4) returns int4 as '
>     select sum(tquant) from mtr_reg where to_proj = $2 and pnum = $1 and
> (status = \'open\' or status = \'clsd\' or status = \'prip\');
>     ' language 'sql';
Ah, I've sussed it.  The difference between the environment in your
function and the environment in a hand-entered query is that you've
declared $1 to be type 'text', whereas in the hand-entered query the
parser resolves the unknown-type string literal into type 'varchar'
to match the type of what it's being compared to.  What you effectively
have inside the function is pnum::text = $1::text, and the planner is
not able to figure out that it can use a varchar index for that.  If you
had written the hand-entered query as "... pnum = '1051'::text ..."
it wouldn't have been done with an indexscan either.
Best short-term solution is to declare the function as taking varchar
in the first place.
This behavior is a regression from 6.5, which handled implicit coercions
differently and could recognize the clause as indexable despite the
inserted coercion.  I'll look into whether it's patchable for 7.0.1.
A proper fix might be too complex to risk patching into 7.0.1 though :-(
... might have to wait for 7.1.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyle Bateman | 2000-05-17 00:17:10 | question on update/delete rules on views | 
| Previous Message | Kyle Bateman | 2000-05-16 18:13:10 | Re: Index not used in functions in 7.0? |