Re: Functions too slow, even with iscachable?

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.

In response to

Browse pgsql-sql by date

  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