Mark,
I'm crossing this over to the performance list; it's really appropriate on
both lists. So I'm quoting you in full as well.
> I have a question regarding the performance of a function returning a
> set of a view as opposed to just selecting the view with the same
> where clause. Please
Mark Bronnimann wrote:
I was hoping to eliminate the parse call on the view because I was doing
the where clause on the view instead of putting the where in the view.
In all, I was hoping to keep a single view called from multiple functions
with different where clauses. Yep... I shoulda known
Thanks for the reply.
I was hoping to eliminate the parse call on the view because I was doing
the where clause on the view instead of putting the where in the view.
In all, I was hoping to keep a single view called from multiple functions
with different where clauses. Yep... I shoulda kn
> The performance hit is tiny, we're talking less than 1/2 a second,
> but when I've done this sort of thing in Oracle I've seen a performance
> increase, not a decrease.
Thats just plain strange (never tried on Oracle). Why in the world
would adding the overhead of a function call (with no ot
I have a question regarding the performance of a function returning a
set of a view as opposed to just selecting the view with the same
where clause. Please, if this should go to the performance list instead,
let me know. I'm just wondering about this from the sql end of things.
Here's th
