2010/11/18 Robert Haas <robertmh...@gmail.com>: > On Thu, Nov 18, 2010 at 1:03 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: >> 2010/11/18 Robert Haas <robertmh...@gmail.com>: >>> On Thu, Nov 18, 2010 at 12:36 PM, Tom Lane <t...@sss.pgh.pa.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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers