Skip site navigation (1) Skip section navigation (2)

RE: func() & select func()

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: func() & select func()
Date: 2000-09-01 02:36:53
Message-ID: 000501c013bd$7d66a700$2801007e@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> 
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > 1) Using non-cachable function f()
> >   =# explain select * from pg_class where oid=f(1259);
> >   Seq Scan on pg_class  (cost=0.00..3.17 rows=1 width=92) 
> 
> > 2) Using select f() 
> >  =# explain select * from pg_class where oid=(select f(1259)); 
> >   Index Scan using pg_class_oid_index on pg_class  (cost=0.00..2.01
> > 	rows=1 width=92)
> >     InitPlan
> -> Result  (cost=0.00..0.00 rows=0 width=0) 
> 
> The sub-select is reduced to an initplan --- ie, executed only once,
> not once per row --- because it has no dependency on the outer select.
> 
> Currently we do not consider the presence of noncachable functions as
> a reason that prevents reducing a subplan to an initplan.  I thought
> about it but didn't like the performance penalty.  It seems to me that
> it's debatable which is the correct semantics, anyway.  Arguably an

After a little thought,it seems to me that the behavior of the subquery
is more reasonable than current evaluation of functions.

Under MVCC,SELECT returns the content of a database at the time
when the query started no matter how long time it takes to return
the resultset.
Shouldn't functions be evaluated once(per the combination of parameters)
at the time when a query started ?

Regards.

Hiroshi Inoue

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-09-01 13:17:45
Subject: Re: func() & select func()
Previous:From: Jan WieckDate: 2000-08-31 23:34:24
Subject: Re: Backend-internal SPI operations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group