From: | Ang Chin Han <angch(at)pintoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Functions too slow, even with iscachable? |
Date: | 2000-08-09 06:50:29 |
Message-ID: | 20000809145029.A5894@pintoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Mon, Aug 07, 2000 at 10:58:27AM -0400, Tom Lane wrote:
> (I assume the lack of "survey_id =" here is just a cut-and-paste error?)
Yup. :)
> I think what you're getting bit by is that the optimizer doesn't
> recognize "var = function(param)" as being a potential indexscan clause.
> Does EXPLAIN show that the first query is producing an indexscan plan?
It did. I'll try to make up a reproducible test case, if you need
it.
> I have not tried it, but I think you could get around this problem in
> plpgsql, along the lines of
> tmp1 = ticket2name($1);
> tmp2 = ticket2survey_id($1);
> SELECT passwd FROM ticket WHERE name = tmp1 AND survey_id = tmp2;
> since the tmp vars will look like params to the optimizer and "var = param"
> is indexable.
Yup, it did work. Thanks!
> Looks like we need to teach the optimizer that expressions involving
> params can be treated like simple params for the purposes of
> optimization.
That'll be good. Anything to speed up the stored procedures are good:
encourage people to put logic processing into the RDBMS where it should
be.
From | Date | Subject | |
---|---|---|---|
Next Message | Ang Chin Han | 2000-08-09 06:53:45 | Aggregate functions, fast! (long) |
Previous Message | Bernie Huang | 2000-08-08 15:53:37 | Re: Changing user passwords |