2009/9/15 Tom Lane :
> Ivan Voras writes:
>> Are functions in language 'sql' handled differently than those of
>> language 'plpgsql'?
>
> Yes.
>
>> I think they're not so in any case a function will behave as a black box
>> with regards to the planner and optimizer (and views are always
>> 'transp
Ivan Voras writes:
> Are functions in language 'sql' handled differently than those of
> language 'plpgsql'?
Yes.
> I think they're not so in any case a function will behave as a black box
> with regards to the planner and optimizer (and views are always
> 'transparent').
No.
Merlin Moncure wrote:
On Sat, Sep 12, 2009 at 7:51 AM, Dimitri Fontaine
wrote:
Merlin Moncure writes:
like joining the result to another table...the planner can see
'through' the view, etc. in a function, the result is fetched first
and materialized without looking at the rest of the query.
On Sat, Sep 12, 2009 at 7:51 AM, Dimitri Fontaine
wrote:
> Merlin Moncure writes:
>> like joining the result to another table...the planner can see
>> 'through' the view, etc. in a function, the result is fetched first
>> and materialized without looking at the rest of the query.
>
> I though th
Merlin Moncure writes:
> like joining the result to another table...the planner can see
> 'through' the view, etc. in a function, the result is fetched first
> and materialized without looking at the rest of the query.
I though the planner would "see through" SQL language functions and
inline t
On Fri, Sep 11, 2009 at 5:27 PM, Jason Tesser wrote:
> Right what I was wondering is is this better done in a view? or a stored
> proc? I am guessing based on your initial response the view is better
> performance. These are the types of queries I will be doing though.
>
in performance terms t
Right what I was wondering is is this better done in a view? or a stored
proc? I am guessing based on your initial response the view is better
performance. These are the types of queries I will be doing though.
On Fri, Sep 11, 2009 at 5:01 PM, Merlin Moncure wrote:
> On Fri, Sep 11, 2009 at 2
On Fri, Sep 11, 2009 at 2:56 PM, Jason Tesser wrote:
> OK so in my case I have a Person, Email, Phone and Address table. I want to
> return the Person and an Array of the others. so my return type would be
> something like Person, Email[], Phone[], Address[]
>
> When passed a personId.
>
> Are yo
OK so in my case I have a Person, Email, Phone and Address table. I want to
return the Person and an Array of the others. so my return type would be
something like Person, Email[], Phone[], Address[]
When passed a personId.
Are you saying this is better in a view. Create a view that can return
On Fri, Sep 11, 2009 at 11:46 AM, Jason Tesser wrote:
> Is it faster to use a Stored Proc that returns a Type or has Out Parameters
> then a View? Views are easier to maintain I feel. I remember testing this
> around 8.0 days and the view seemed slower with a lot of data.
for the most part, a v
Is it faster to use a Stored Proc that returns a Type or has Out Parameters
then a View? Views are easier to maintain I feel. I remember testing this
around 8.0 days and the view seemed slower with a lot of data.
11 matches
Mail list logo
