Re: Using LIMIT 1 in plpgsql PERFORM statements

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Using LIMIT 1 in plpgsql PERFORM statements
Date: 2005-10-24 04:36:35
Message-ID: 200510232136.35790.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Neil Conway 2005-10-24 04:40:10 Re: Using LIMIT 1 in plpgsql PERFORM statements
Previous Message Robert Edmonds 2005-10-24 03:58:09 performance of implicit join vs. explicit conditions on inet queries?