Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id 870D32E0106 for ; Mon, 31 Mar 2008 21:23:36 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 63151-01-7 for ; Mon, 31 Mar 2008 21:23:19 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by developer.postgresql.org (Postfix) with ESMTP id D44B02E0055 for ; Mon, 31 Mar 2008 21:20:35 -0300 (ADT) Received: by ug-out-1314.google.com with SMTP id j3so704877ugf.49 for ; Mon, 31 Mar 2008 17:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=32FQjwuqq21x1vlN1GLO+dsZkVFat2gZ58KozyV9BT4=; b=W7l1QZESmBmc3VRm/9blest+t6CAY+veDGGO4wLw8t1uWCSyQeFdqpTCbXdmH/NdHhx4Gm2/VhvZmkWcYlcS4EZMtfBNcC/nktnEGS+9wIUSwonxAm8rAEvuAI/4KskIVkQrbU6Gv4LhHBfM0cKuBOE1k9F3hjIfGZVCvu8h0d4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=sdrYD897i+GUnidPCcI4b6PDJLX/mDpsf9gOiUJgKGUIJDAdF5ozlXW1rmkzgIoYf4gbahQFjE4+GqpoCwxYpVBDsvHvR0edjko3MqKHsrnyPGpmd2Hnvgolnc5oSGPEVNhrp9LLC9j8BxZ/6Na4D8kqeQ194f/8u4FeC2MO/V0= Received: by 10.67.196.2 with SMTP id y2mr2486300ugp.60.1207009234526; Mon, 31 Mar 2008 17:20:34 -0700 (PDT) Received: by 10.67.16.18 with HTTP; Mon, 31 Mar 2008 17:20:34 -0700 (PDT) Message-ID: <7a4208ef0803311720s1dac8362gff2477d3dc534968@mail.gmail.com> Date: Tue, 1 Apr 2008 13:20:34 +1300 From: "Ravi Chemudugunta" To: pgsql-performance@postgresql.org Subject: Performance Implications of Using Exceptions MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200803/535 X-Sequence-Number: 29489 Hello, I have a typical many to many join table, in this instance it is capturing the multiplicity described as "one person can have many rooms and one room can have many persons". Further the join expresses where in the room the person is sitting, a seat number. I am creating a function to abstract this away, if there is no record with the same person and room the insert otherwise if it already exists update the record with the new seat value. create table person_room ( id serial, person_id int, room_id int, seat varchar(255), unique (person_id, room_id) ); -- version 1 create or replace function add_person_to_room(person int, room int, s varchar(255)) as $$ begin insert into person_room(person_id, room_id, seat) values (person, room, s); exception when unique_violation then update person_room set seat = s where (person_id = person) and (room_id = room); end; $$ language 'plpgsql'; -- version 2 create or replace function add_person_to_room(person int, room int, s varchar(255)) as $$ declare i int; begin select into i id from person_room where (person_id = person) and (room_id = room); if (not found) then insert into person_room(person_id, room_id, seat) values (person, room, s); else update person_room set seat = s where (person_id = person) and (room_id = room); end; $$ language 'plpgsql'; Which version is faster? Does the exception mechanism add any overhead? Which is more cleaner? -ravi