On Tue, Jan 16, 2007 at 02:55:08PM -0700, Nathan Bell wrote:
> Yeah, I saw the "not optimized out" typo as soon as I hit send.
>
> What if the item that is taking a long time isn't a function, but rather
> a sub-select?
The planner should be able to see that the item is non-volatile itself.
It o
I wrote:
> The point is that the view won't be flattened if there are nonvolatile
> functions in its SELECT list.
Sheesh ... s/nonvolatile/volatile/ of course ... this thread seems
afflicted with getting-it-backward disease :-(
regards, tom lane
--
Nathan Bell <[EMAIL PROTECTED]> writes:
> What if the item that is taking a long time isn't a function, but rather
> a sub-select?
The point is that the view won't be flattened if there are nonvolatile
functions in its SELECT list.
regards, tom lane
-
Yeah, I saw the "not optimized out" typo as soon as I hit send.
What if the item that is taking a long time isn't a function, but rather
a sub-select?
Can I set the sub-select to stable, or perhaps set the entire view to
non-volatile to achieve the same result?
If not, can I set the sub-select
Nathan Bell <[EMAIL PROTECTED]> writes:
> Firing up 8.2.1 I notice that sub-items in a view are optimized out if
> they aren't being selected.
You mean "not optimized out", I suppose. Declare your function as
non-volatile if you want the optimizer to assume it's OK to discard.
Firing up 8.2.1 I notice that sub-items in a view are optimized out if
they aren't being selected.
For example, "select item1, item2 from a_view" would take just as long
as "select item1, item2, item3, item4 from a_view"
This isn't usually a problem, but if item3 or item4 are significantly
m
