| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Graham Vickrage" <graham(at)digitalplanit(dot)com> |
| Cc: | pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: Use of indexes in plpgsql functions |
| Date: | 2000-12-15 22:54:28 |
| Message-ID: | 13994.976920868@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
"Graham Vickrage" <graham(at)digitalplanit(dot)com> writes:
>> CREATE FUNCTION get_url_hits (varchar, int4) RETURNS int4 AS '
>> DECLARE
>> num INT4;
>> BEGIN
>> SELECT count(*) INTO num FROM statistics WHERE url = $1 and
>> website_id = $2;
> [ is slow ]
A possible gotcha is if the url and website_id columns are declared as
something other than varchar and int4 respectively. The planner's not
very smart about optimizing cross-datatype comparisons into indexscans.
When you write out a query with constants you are protected from this
because the constants have their types adjusted, but when you write "url
= $1" you'd best make sure $1 is declared exactly the same way as url.
7.1 fixes some instances of this gotcha, but not all of 'em IIRC.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvar Freude | 2000-12-15 23:14:56 | Re: How to represent a tree-structure in a relationaldatabase |
| Previous Message | Graham Vickrage | 2000-12-15 22:05:01 | Use of indexes in plpgsql functions |