From: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Versionning (was: Whole-row comparison) |
Date: | 2007-06-01 18:51:25 |
Message-ID: | 20070601185125.GJ24299@phlogiston.dyndns.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Fri, Jun 01, 2007 at 09:07:10PM +0300, christian(dot)roche(dot)ext(at)nsn(dot)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(at)crankycanuck(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Karthikeyan Sundaram | 2007-06-04 05:10:19 | pguuid for windows |
Previous Message | chester c young | 2007-06-01 18:16:29 | schema propagation |