Re: Versionning (was: Whole-row comparison) - Mailing list pgsql-sql

From Andrew Sullivan
Subject Re: Versionning (was: Whole-row comparison)
Date
Msg-id 20070601185125.GJ24299@phlogiston.dyndns.org
Whole thread Raw
In response to Re: Versionning (was: Whole-row comparison)  (<christian.roche.ext@nsn.com>)
Responses Re: Versionning (was: Whole-row comparison)  (<christian.roche.ext@nsn.com>)
List pgsql-sql
On Fri, Jun 01, 2007 at 09:07:10PM +0300, christian.roche.ext@nsn.com wrote:
>  
> Hi Andrew,
> 
> I must admit I don't really understand what you say.  I don't know what
> SRF stand for, and what you say about generic case is not clear to me,
> sorry.

Sorry, it stands for set returning function.  I thought someone
upthread suggested that instead of a view.

> and the following statement would be optimized:
> 
> UPDATE param_table SET ver_id = xxx;
> SELECT * FROM bsc_view WHERE obj_id = yyy; 
> 
> which would not be the case would I have used a multi-row function.
> 
> Does this make sense ?

Yes, but I don't think it's true.  Because you change the value of
ver_id all the time, the actual result can't be collapsed to a
constant, so you end up having to execute the query with the
additional value, and you still have to plan that.  The same thing is
true of a function, which will have its plan prepared the first time
you execute it.  (I could be wrong about this; I suppose the only way
would be to try it.)

A
-- 
Andrew Sullivan  | ajs@crankycanuck.ca
However important originality may be in some fields, restraint and 
adherence to procedure emerge as the more significant virtues in a 
great many others.   --Alain de Botton


pgsql-sql by date:

Previous
From: chester c young
Date:
Subject: schema propagation
Next
From: Karthikeyan Sundaram
Date:
Subject: pguuid for windows