X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 316C49DCC25 for ; Wed, 21 Dec 2005 23:45:12 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 95365-01 for ; Wed, 21 Dec 2005 23:45:16 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id B163F9DCC18 for ; Wed, 21 Dec 2005 23:45:08 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jBM3jB6b018611; Wed, 21 Dec 2005 22:45:11 -0500 (EST) To: Michael Fuhr cc: pgsql-performance@postgresql.org Subject: Re: Speed of different procedural language In-reply-to: <20051222021346.GA61585@winnie.fuhr.org> References: <20051221110647.GA17360@uio.no> <20051221212442.GA59736@winnie.fuhr.org> <20051221213810.GA27113@uio.no> <20051221221028.GA60176@winnie.fuhr.org> <20051222010823.GA6103@uio.no> <20051222021346.GA61585@winnie.fuhr.org> Comments: In-reply-to Michael Fuhr message dated "Wed, 21 Dec 2005 19:13:46 -0700" Date: Wed, 21 Dec 2005 22:45:11 -0500 Message-ID: <18610.1135223111@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.032 required=5 tests=[AWL=0.032] X-Spam-Score: 0.032 X-Spam-Level: X-Archive-Number: 200512/558 X-Sequence-Number: 16379 Michael Fuhr writes: > Try looping through two million rows with PL/Perl or PL/Tcl and > you'll probably see significantly worse performance than with > PL/pgSQL -- so much worse that I'd be surprised to see those languages > make up the difference with whatever processing they'd be doing for > each row unless it was something they're particularly good at and > PL/pgSQL is particularly bad at. I'd expect plpgsql to suck at purely computational tasks, compared to the other PLs, but to win at tasks involving database access. These are two sides of the same coin really --- plpgsql is tightly tied to the PG query execution engine, to the extent of using it even for simply adding 2 and 2, but that also gives it relatively low overhead for invoking a database query. Perl, Tcl, et al have their own computational engines and can easily beat the PG SQL engine for simple arithmetic and string-pushing. But they pay a high overhead for calling back into the database engine. regards, tom lane