From: Josh Berkus <josh@agliodbs.com>
Organization: Aglio Database Solutions
To: "Karl O. Pinc" <kop@meme.com>
Subject: Re: Using LIMIT 1 in plpgsql PERFORM statements
Date: Sun, 23 Oct 2005 21:36:35 -0700
User-Agent: KMail/1.8
Cc: pgsql-performance@postgresql.org
References: <1129957521l.27845l.2l@mofo>
 <200510231402.35612.josh@agliodbs.com>
	<1130114418l.8670l.2l@mofo>
In-Reply-To: <1130114418l.8670l.2l@mofo>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200510232136.35790.josh@agliodbs.com>

Karl,

> I like to write PERFORMs that return a constant when
> selecting from a table.  It emphasizes that the
> selection is being done for its side effects.

Well, there's always the destruction test: run each version of the function 
10,000 times and see if there's an execution time difference.

> (Programs should be written for people to read
> and only incidentally for computers to execute.
> Programs that people can't read quickly
> become useless whereas programs that can't run
> quickly can be fixed.  Computers are easy.
> People are difficult.)

That's a nice sentiment, but I don't see how it applies.  For example, if I 
do:

SELECT id INTO v_check
FROM some_table ORDER BY id LIMIT 1;

IF id > 0 THEN ....

... that says pretty clearly to code maintainers that I'm only interested in 
finding out whether there's any rows in the table, while making sure I use 
the index on ID.  If I want to make it more clear, I do:

-- check whether the table is populated

Not that there's anything wrong with your IF FOUND approach, but let's not mix 
up optimizations and making your code pretty ... especially for a SQL 
scripting language.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco