Tom Lane wrote:
> I'd expect plpgsql to suck at purely computational tasks, compared to
> the other PLs, but to win at tasks involving database access. These
There you go...pl/pgsql is pretty much required learning (it's not
hard). For classic data processing tasks, it is without peer. I would
Michael Fuhr <[EMAIL PROTECTED]> 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'
On Thu, Dec 22, 2005 at 02:08:23AM +0100, Steinar H. Gunderson wrote:
> On Wed, Dec 21, 2005 at 03:10:28PM -0700, Michael Fuhr wrote:
> >> That's funny, my biggest problems with PL/PgSQL have been (among others)
> >> exactly with large result sets...
> > Out of curiosity, do you have a simple test
On Wed, Dec 21, 2005 at 03:10:28PM -0700, Michael Fuhr wrote:
>> That's funny, my biggest problems with PL/PgSQL have been (among others)
>> exactly with large result sets...
> Out of curiosity, do you have a simple test case? I'd be interested
> in seeing what you're doing in PL/pgSQL that's cont
On Wed, Dec 21, 2005 at 10:38:10PM +0100, Steinar H. Gunderson wrote:
> On Wed, Dec 21, 2005 at 02:24:42PM -0700, Michael Fuhr wrote:
> > The difference is clear only in specific cases; just because you
> > saw a 10x increase in some cases doesn't mean you can expect that
> > kind of increase, or i
On Wed, Dec 21, 2005 at 02:24:42PM -0700, Michael Fuhr wrote:
> The difference is clear only in specific cases; just because you
> saw a 10x increase in some cases doesn't mean you can expect that
> kind of increase, or indeed any increase, in others. I've seen
> PL/pgSQL beat all other PL/* challe
On Wed, Dec 21, 2005 at 12:06:47PM +0100, Steinar H. Gunderson wrote:
> On Sun, Dec 18, 2005 at 01:10:21AM -, Ben Trewern wrote:
> > I know I should be writing these in C but that's a bit beyond me. I was
> > going to try PL/Python or PL/Perl or even PL/Ruby. Has anyone any idea
> > which l
> On Sun, Dec 18, 2005 at 01:10:21AM -, Ben Trewern wrote:
> > I know I should be writing these in C but that's a bit beyond me. I
was
> > going to try PL/Python or PL/Perl or even PL/Ruby. Has anyone any
idea
> > which language is fastest, or is the data access going to swamp the
> overhead
On Sun, Dec 18, 2005 at 01:10:21AM -, Ben Trewern wrote:
> I know I should be writing these in C but that's a bit beyond me. I was
> going to try PL/Python or PL/Perl or even PL/Ruby. Has anyone any idea
> which language is fastest, or is the data access going to swamp the overhead
> of sm
I have a few small functions which I need to write. They will be hopefully
quick running but will happen on almost every delete, insert and update on
my database (for audit purposes).
I know I should be writing these in C but that's a bit beyond me. I was
going to try PL/Python or PL/Perl or
10 matches
Mail list logo
