From: Tom Lane <tgl@sss.pgh.pa.us>
To: Joe Conway <mail@joeconway.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: Richard Sydney-Smith <richard@ibisaustralia.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: Mystery function error
Date: Sun, 28 Sep 2003 14:29:14 -0400
Message-ID: <10187.1064773754@sss.pgh.pa.us> (raw)
In-Reply-To: <9634.1064767690@sss.pgh.pa.us>
References: <000c01c38572$73c03c50$251a32d2@athlon2000>
<200309272229.50601.josh@agliodbs.com>
<9398.1064765182@sss.pgh.pa.us>
<3F770A8D.9030400@joeconway.com>
<9634.1064767690@sss.pgh.pa.us>
I said:
> [hmm, I wonder why plpgsql seems to have gotten slower in 7.4...]
False alarm --- or at least, it wasn't plpgsql's fault. I copied Joe's
function definition, which was
CREATE OR REPLACE FUNCTION public.locate(bpchar, bpchar) RETURNS int4 AS '
But since position() takes arguments of type TEXT, there are two
bpchar->text coercions involved inside the function. This was a "free"
binary coercion in 7.3, but 7.4 interprets it as invoking rtrim().
The extra rtrim operations account for most of the slowdown.
Using functions declared like "locate(text, text)" to avoid the unwanted
type coercions, I get these kinds of numbers:
7.4 7.3
position() 1 usec/call 1 usec/call
SQL func 1 usec/call 90 usec/call
plpgsql func 110 usec/call 100 usec/call
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, mail@joeconway.com, josh@agliodbs.com, richard@ibisaustralia.com
Subject: Re: Mystery function error
In-Reply-To: <10187.1064773754@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox