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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: final patch - plpgsql: for-in-array
Date: 2010-11-18 16:00:55
Message-ID: 4CE54DB7.9050800@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/18/2010 10:33 AM, Robert Haas wrote:
> On Thu, Nov 18, 2010 at 10:24 AM, Merlin Moncure<mmoncure(at)gmail(dot)com> wrote:
>>
>> Pavel's performance argument is imnsho valid. arrays at present are
>> the best way to pass data around functions and any optimizations here
>> are very welcome. Given that, is there any way to mitigate your
>> concerns on the syntax side?
> Can we get the performance benefit any other way? I hate to think
> that it will still be slow for people using the already-supported
> syntax.

It's not disastrously slower. AFAICT from a very quick glance over the
patch, he's getting the speedup by bypassing the normal mechanism for
evaluating "for x in select ...". So we'd have to special-case that to
trap calls to unnest in the general form. That would be pretty ugly. Or
else make unnest and SPI faster. But that's a much bigger project.

Syntactic sugar is not entirely to be despised, anyway.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Cédric Villemain 2010-11-18 16:02:35 Re: final patch - plpgsql: for-in-array
Previous Message Pavel Stehule 2010-11-18 15:57:53 Re: final patch - plpgsql: for-in-array