Re: Predicates not getting pushed into SQL function?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jay Levitt <jay(dot)levitt(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Predicates not getting pushed into SQL function?
Date: 2011-11-03 18:41:16
Message-ID: 6646.1320345676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Jay Levitt <jay(dot)levitt(at)gmail(dot)com> writes:
> I'm confused. I have a now-trivial SQL function that, unrestricted, would
> scan my whole users table. When I paste the body of the function as a
> subquery and restrict it to one row, it only produces one row. When I paste
> the body of the function into a view and restrict it to one row, it produces
> one row. But when I put it in a SQL function... it scans the whole users
> table and then throws the other rows away.

> I thought SQL functions were generally inline-able, push-down-able, etc.

inline-able, yes, but if they're not inlined you don't get any such
thing as pushdown of external conditions into the function body.
A non-inlined function is a black box.

The interesting question here is why the function doesn't get inlined
into the calling query. You got the obvious showstoppers: it has a
SETOF result, it's not volatile, nor strict. The only other possibility
I can see offhand is that there's some sort of result datatype mismatch,
but you've not provided enough info to be sure about that.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2011-11-03 18:45:36 Re: Blocking excessively in FOR UPDATE
Previous Message Kevin Grittner 2011-11-03 18:32:48 Re: Optimization required for multiple insertions in PostgreSQL