On Sun, 2005-23-10 at 21:36 -0700, Josh Berkus wrote:
> 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
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.
On 10/23/2005 04:02:35 PM, Josh Berkus wrote:
I'm wondering in what context it makes sense to call PERFORM on a
constant.
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.
(Programs should be wri
On 10/23/2005 04:02:35 PM, Josh Berkus wrote:
Karl,
> PERFORM 1 FROM foo;
> IF FOUND THEN ...
>
> is any slower than:
>
> PERFORM 1 FROM foo LIMIT 1;
> IF FOUND THEN ...
I'm wondering in what context it makes sense to call PERFORM on a
constant.
If you want to find out if the table has any r
Karl,
> PERFORM 1 FROM foo;
> IF FOUND THEN ...
>
> is any slower than:
>
> PERFORM 1 FROM foo LIMIT 1;
> IF FOUND THEN ...
I'm wondering in what context it makes sense to call PERFORM on a constant.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broad
Hi,
I'm wondering if the plpgsql code:
PERFORM 1 FROM foo;
IF FOUND THEN ...
is any slower than:
PERFORM 1 FROM foo LIMIT 1;
IF FOUND THEN ...
Seems like it _could_ be smart enough to know that
1) It's selecting from a real table and not a function
2) GET DIAGNOSTICS is not used
and theref
