Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYwSe-0000Ru-Hn for pgsql-docs@arkaria.postgresql.org; Tue, 09 Jan 2018 16:09:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYwSd-0005m0-La for pgsql-docs@arkaria.postgresql.org; Tue, 09 Jan 2018 16:09:11 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eYprk-0005wR-JN for pgsql-docs@lists.postgresql.org; Tue, 09 Jan 2018 09:06:40 +0000 Received: from mail-io0-x22a.google.com ([2607:f8b0:4001:c06::22a]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eYprh-0008Cc-SB for pgsql-docs@postgresql.org; Tue, 09 Jan 2018 09:06:39 +0000 Received: by mail-io0-x22a.google.com with SMTP id k18so17764969ioc.11 for ; Tue, 09 Jan 2018 01:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=firstcircle-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:date:message-id:from:to; bh=WbpdptUtWD5VJbrimMyLkzWUtUxKDxJb9HYG6V5Yw1g=; b=V7lSRHwPSrh0LWmMeIZdumlT+1sRhk/ntjs9FXDxgCBSwGzQy8Hefh2I28xNVXYBRC Q2wvaxabqod64BA7AWqahIUd9G5ZzaykdEyq2UVKFr9GOchVoAJXrYfeqedmY/ilcLxk bc/2C/r8opXeWihYMUNBFkH0KAnX4zsXrtIXmlhEhS/87fGs4MMnghYUF3OPhSNKDsan vizuQGltqx4W0aGpykbpMoidc1survjOmF5tZVE3othmlzFhs6CjtgrRDvp+SU0Arf1y Oylh6BzoYSnSoGDq35I2bh/je1eH7In8sDwWr+XcLeEfaUG5UGZbEaMn+frzm2VoDiuC khkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:date:message-id:from:to; bh=WbpdptUtWD5VJbrimMyLkzWUtUxKDxJb9HYG6V5Yw1g=; b=tE9xOEkeQ+HLm1bqF0LHydnlEvvm5AK4n5h//aMJMrnao5/wOW1kcR4CKciolIp94c F2Giy5Nj560h4+GfkWFSJF7yOWR9xIy6xG2QhB3fv2h59+BZpOSQi3Pwa53d5a0YgEir mjOjeY1Z/BAi0No3CF2zrrCDRjGE3c072VlOgQ2+JeUp0w8SJyujYLPfmmIQhGXJYxli V7rEkY0fJXMDEKX7Ko8uard5uaZ6CtULhw7SW/2WrOLK9TXEhgxrJxW9uQyi5gMFLBIY hVl1mBU/FQwt7SYclPZiP/a6nNI4f4ZXQni3ERrUN+7PH1Aglr0eqpc3d1nu8S9sk3QT ezxg== X-Gm-Message-State: AKGB3mJLN1DXG8KW6YoYV1tlnS4SJwfDk+jSJ1+qUBH7ju9SDu7RGC/t v/PAWmmxyGVibD9lrgOiLyXBhMzX4L8= X-Google-Smtp-Source: ACJfBouT6Qog1FUthAidz7tOO58dwQVQ84GlhFkpfN4q8IG7yvg2N5Xan/319lktoFxG/3lTI5TIbg== X-Received: by 10.107.13.12 with SMTP id 12mr14561834ion.174.1515488796497; Tue, 09 Jan 2018 01:06:36 -0800 (PST) Received: from localhost (128.78.198.104.bc.googleusercontent.com. [104.198.78.128]) by smtp.gmail.com with ESMTPSA id m34sm8355211iti.24.2018.01.09.01.06.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 01:06:35 -0800 (PST) Mime-Version: 1.0 Subject: Advice on Contiguous IDs Date: Tue, 09 Jan 2018 01:06:26 -0800 X-Mailer: Polymail Message-ID: <5a546fcab6ae2e0000bdb8e4@polymail.io> From: "Brian McKiernan" To: pgsql-docs@postgresql.org Content-Type: multipart/alternative; boundary=fe2b427c7ca1e9ba9268224cad304e2e1512225e510203022714394badb2 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --fe2b427c7ca1e9ba9268224cad304e2e1512225e510203022714394badb2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hi Folks, Looking for some help/advice - not sure if this is the appropriate channel. My Issue: My primary keys in a certain table are not contiguous. What I have done so far: I have checked the documentation and found:=C2=A0https://wiki.postgresql.or= g/wiki/FAQ#Why_are_there_gaps_in_the_numbering_of_my_sequence.2FSERIAL_colu= mn.3F_Why_aren.27t_my_sequence_nu ( https://wiki.postgresql.org/wiki/FAQ#Wh= y_are_there_gaps_in_the_numbering_of_my_sequence.2FSERIAL_column.3F_Why_are= n.27t_my_sequence_numbers_reused_on_transaction_abort.3F ) mbers_reused_on_transaction_abort.3F ( https://wiki.postgresql.org/wiki/FAQ= #Why_are_there_gaps_in_the_numbering_of_my_sequence.2FSERIAL_column.3F_Why_= aren.27t_my_sequence_numbers_reused_on_transaction_abort.3F ) My Question: 1) What event would cause the=C2=A0CACHE clause in CREATE SEQUENCE to make = an out of sequence next number? 2) In all cases am I correct in my thinking that in order to create contigu= ous primary key IDs then performance will greatly suffer? Do we have an ide= a of how bad this will generally be or what does that depend upon? Many thanks in advance, Brian --fe2b427c7ca1e9ba9268224cad304e2e1512225e510203022714394badb2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 3D""
Hi Folks,

Looking for some help/advice - not = sure if this is the appropriate channel.

My Issue:=
My primary keys in a certain table are not contiguous.

What I have done so far:

<= /div>
My Question:
1) What event would cause the CACH= E clause in CREATE SEQUENCE to make an out of sequence next number?<= /div>
2) In all cases am I correct in my thinking that in order to c= reate contiguous primary key IDs then performance will greatly suffer? Do w= e have an idea of how bad this will generally be or what does that depend u= pon?

Many thanks in advance,
Brian

--fe2b427c7ca1e9ba9268224cad304e2e1512225e510203022714394badb2--