From: | Matthew Wakeling <matthew(at)flymine(dot)org> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Eliot Gable <egable+pgsql-performance(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL Function Language Performance: C vs PL/PGSQL |
Date: | 2010-06-01 12:47:08 |
Message-ID: | alpine.DEB.2.00.1006011345220.4083@aragorn.flymine.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 28 May 2010, Merlin Moncure wrote:
> At best, if you are a ninja with the marginally documented backend
> api, you will create code that goes about as fast as your pl/pgsql
> function for 10 times the amount of input work, unless there are heavy
> amounts of 'other than sql' code in your function. The reason to
> write C in the backend is:
>
> *) Interface w/3rd party libraries w/C linkage
> *) Do things that are illegal in regular SQL (write files, etc)
> *) Make custom types
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.
Matthew
--
"The problem with defending the purity of the English language is that
English is about as pure as a cribhouse whore. We don't just borrow words;
on occasion, English has pursued other languages down alleyways to beat
them unconscious and rifle their pockets for new vocabulary." - James Nicoll
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2010-06-01 12:54:53 | Re: PostgreSQL Function Language Performance: C vs PL/PGSQL |
Previous Message | Matthew Wakeling | 2010-06-01 09:55:35 | Re: Optimize date query for large child tables: GiST or GIN? |