Re: Three types of functions, ala function redux.
| От | Tom Lane | 
|---|---|
| Тема | Re: Three types of functions, ala function redux. | 
| Дата | |
| Msg-id | 11191.977341834@sss.pgh.pa.us обсуждение исходный текст  | 
		
| Ответ на | Three types of functions, ala function redux. (mlw <markw@mohawksoft.com>) | 
| Список | pgsql-hackers | 
mlw <markw@mohawksoft.com> writes:
> There are three basic types of SQL behaviors that should be able to be
> performed.
> (1) "function()" returns a single value. Postgres should be able to
> understand how to optimize this to be: "select * from table where col =
> value" where value is the datum returned by function.
You get this now if the function is marked proiscachable.
> (2) "function()" returns a number of values that are independent of the
> query. Postgres should be able to optimize this to be: "select * from
> table where col in (val1, val2, val3, ..valn)." I guess Postgres can
> loop until done, using the isDone flag?
I object to the notion that "scalar = set" should be automatically
transformed into "scalar IN set".  It would be nice to be smarter about
optimizing IN operations where the subselect only returns a few rows
into multiple indexscans, but how should the planner know that in advance?
> (3) "function()" returns a value based on the query. (This seems to be
> how it currently functions.) where "select * from table where col =
> function()" will end up doing a full table scan. 
You get this now if the function is not marked proiscachable.
        regards, tom lane
		
	В списке pgsql-hackers по дате отправления: