From: | Craig James <craig_james(at)emolecules(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL Function Language Performance: C vs PL/PGSQL |
Date: | 2010-05-26 17:09:41 |
Message-ID: | 4BFD55D5.4040907@emolecules.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 5/26/10 9:47 AM, Stephen Frost wrote:
> * Eliot Gable (egable+pgsql-performance(at)gmail(dot)com) wrote:
>> Since PostgreSQL is written in C, I assume there is no
>> such additional overhead. I assume that the PL/PGSQL implementation at its
>> heart also uses SPI to perform those executions. Is that a fair statement?
>
> Right, but I also wouldn't expect a huge improvment either, unless
> you're calling these queries a ton, or the queries that you're calling
> from the pl/pgsql are pretty short-lived.
>
> Don't get me wrong, C is going to be faster, but it depends on exactly
> what's going on as to if it's going to be an overall improvment of, say,
> 10%, or a 10-fold improvment. :)
Or a 0.1% improvement, which is more likely. Or that the PL/PGSQL version is even faster than the C version, because if you do any string regexp in your function, Perl has extremely efficient algorithms, probably better than you have time to write in C.
We use Perl extensively and have never had any complaints. The database activity completely dominates all queries, and the performance of Perl has never even been noticable.
We use a C functions for a few things, and it is a big nuisance. Every time you upgrade Postgres or your OS, there's a chance the recompile will fail because of changed header files. Any bugs in your code crash Postgres itself. We avoid C as much as possible (and I love C, been doing it since 1984).
Craig
From | Date | Subject | |
---|---|---|---|
Next Message | tv | 2010-05-26 18:16:28 | Re: Random Page Cost and Planner |
Previous Message | Grzegorz Jaśkiewicz | 2010-05-26 16:47:55 | Re: performance of temporary vs. regular tables |