Re: PostgreSQL Function Language Performance: C vs PL/PGSQL

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Eliot Gable <egable+pgsql-performance(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
Date: 2010-06-01 16:28:25
Message-ID: AANLkTinV3TnVPT496_Q3cB0p-DGs7RJggh7TCWdyzyEJ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Jun 1, 2010 at 8:59 AM, Matthew Wakeling <matthew(at)flymine(dot)org> wrote:
> On Tue, 1 Jun 2010, Stephen Frost wrote:
>>
>> * Matthew Wakeling (matthew(at)flymine(dot)org) wrote:
>>>
>>> The major case I found when writing pl/pgsql was when trying to build
>>> arrays row by row. AFAIK when I tried it, adding a row to an array caused
>>> the whole array to be copied, which put a bit of a damper on performance.
>>
>> Using the built-ins now available in 8.4 (array_agg), that copying
>> doesn't happen any more.
>
> Thanks. I had wondered if that had been improved.

even better is array(query) -- which has been around for a while. not
too many people know about it because it's syntactically weird but
it's the preferred way to build arrays when you don't need true
aggregation (group by and such).

generally speaking, concatenation of any kind in loops should be
avoided in pl/pgsql. in fact, whenever writing pl/pgsql, it's all to
easy to over-use the loop construct...every time you're looping it's
always good to ask yourself: 'can this be done in a query?'.

merlin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Alvaro Herrera 2010-06-01 17:14:06 Re: Optimize date query for large child tables: GiST or GIN?
Previous Message Torsten Zühlsdorff 2010-06-01 15:03:48 How to insert a bulk of data with unique-violations very fast