Re: final patch - plpgsql: for-in-array

2010/11/18 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Nov 18, 2010 at 1:03 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> 2010/11/18 Robert Haas <robertmhaas(at)gmail(dot)com>:
>>> On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> I would *much* rather we get the performance benefit by internal
>>>> optimization, and forego inventing syntax.
>>>
>>> +1.
>>
>> any optimization will be about 10-20% slower than direct access. See
>> my tests: on large arrays isn't significant if you use a simple
>> expression or full query. This is just overhead from building a
>> "tuplestore" and access to data via cursor. And you cannot to change a
>> SRF functions to returns just array. I would to see any optimization
>> on this level, but I think so it's unreal expecting.
>
> How can you possibly make a general statement like that?  What's slow
> is not the syntax; it's what the syntax is making happen under the
> hood.
>

ok, it is based on my tests, but it can be subjective. Probably is
possible to work with a tuplestore as result of SRF function. And
probably we can read from it without cursor. Maybe we can to teach a
SRF functions to store values as scalars not as tuple - tuplestore can
do it, but the we have to have a global state and we must to modify
buildin functions (not just "unnest" - if the feature should be
general). But newer we can to ensure a working with only necessary
data like a special PL statement. "unnest" returns all fields, but
these fields should not be used. There isn't possible to say - stop, I
don't need other fields. It's possible just with special PL statement,
because it is controlled by PL. So it is reason why I don't believe in
optimizations on PL level.

Regards

Pavel Stehule

> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>