Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 55E45133729E for ; Sat, 16 Oct 2010 15:30:57 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 43900-04 for ; Sat, 16 Oct 2010 18:30:50 +0000 (UTC) X-Greylist: delayed 01:01:46.69433 by SQLgrey-1.7.6 Received: from mail-yw0-f46.google.com (mail-yw0-f46.google.com [209.85.213.46]) by mail.postgresql.org (Postfix) with ESMTP id 921ED1337B84 for ; Sat, 16 Oct 2010 15:30:49 -0300 (ADT) Received: by ywi6 with SMTP id 6so833392ywi.19 for ; Sat, 16 Oct 2010 11:30:48 -0700 (PDT) Received: by 10.236.110.33 with SMTP id t21mr2808033yhg.62.1287250141528; Sat, 16 Oct 2010 10:29:01 -0700 (PDT) Received: from Craig-Jamess-MacBook-Pro.local (cpe-76-176-215-35.san.res.rr.com [76.176.215.35]) by mx.google.com with ESMTPS id m25sm11307237yha.43.2010.10.16.10.28.51 (version=SSLv3 cipher=RC4-MD5); Sat, 16 Oct 2010 10:29:00 -0700 (PDT) Message-ID: <4CB9E0C9.4090702@emolecules.com> Date: Sat, 16 Oct 2010 10:28:41 -0700 From: Craig James User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Navkirat Singh , pgsql-performance@postgresql.org Subject: Re: UUID performance as primary key References: <63CD89CB-22F6-441C-ACBF-F76906B7E468@gmail.com> In-Reply-To: <63CD89CB-22F6-441C-ACBF-F76906B7E468@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201010/277 X-Sequence-Number: 40695 On 10/15/10 6:58 PM, Navkirat Singh wrote: > I am interested in finding out the pros/cons of using UUID as a > primary key field. My requirement states that UUID would be perfect > in my case as I will be having many small databases which will link > up to a global database using the UUID. Hence, the need for a unique > key across all databases. You left out one piece of information: How many keys per second do you need? We put a sequence in the global database that all secondary databases use to get their IDs. It means an extra connect/disconnect (a pooler can minimize this), so if you're issuing thousands of IDs per second, this isn't a good idea. But for a small-ish number of IDs per second, it gets you the benefit of a universal ID without the size of the UUID field. Craig (the other one)