Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pG6Ju-0006k4-1j for pgsql-admin@arkaria.postgresql.org; Thu, 12 Jan 2023 22:45:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pG6Jr-0002wi-Lx for pgsql-admin@arkaria.postgresql.org; Thu, 12 Jan 2023 22:45:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pG6Jr-0002wZ-92 for pgsql-admin@lists.postgresql.org; Thu, 12 Jan 2023 22:45:11 +0000 Received: from mail-qt1-x82c.google.com ([2607:f8b0:4864:20::82c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pG6Jp-0000zN-3i for pgsql-admin@lists.postgresql.org; Thu, 12 Jan 2023 22:45:10 +0000 Received: by mail-qt1-x82c.google.com with SMTP id h21so17614797qta.12 for ; Thu, 12 Jan 2023 14:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=qYho5OyMB69+eAeTG94EBhOazB/96ahbnAuUvEDdkZk=; b=NM6RkMwQ/eG3z9RAOZSf4mLn7BOkgPuM7DjFcCBX3w9G5H/EcUXPMKFIbf/yoCV46j BT1qDXoHObCnJUS9pMIfhNWyFvn03ulQicunXgnmCz2pzYCms9gofa9uDPVE0xyPbb7T yln5ZKt6vlABLjPz0NbocMKfdbyGTZlWg8aCqOblSzNATh+Nw4p1gAR3Jxhe88h3uWil Dw/1miSY+PsZ3pW+kwAiS8tdba73GeRd01WkQo5pt8cQmabxXoJf7DoHLnan4A/zN4HR +fp4735RqXU1jZ9ncNwcu5cGhVsCrN1VgcpI+aneOwi2w+Xo70bGQOVWWbIhwR0nqErP EYiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=qYho5OyMB69+eAeTG94EBhOazB/96ahbnAuUvEDdkZk=; b=bjH/spnFhkmEiunXX7npCkEZTnZqTOfR5nXWufxV8cfqAc+qq3Qw0MVSl6I18xhxFj HtHd9LHGkKzS20EgIOcOaoMEz3FNkq3qCN5VNvs2YwM2+dEMMm0V7UNgkDu38x7j2p4R NNunaqOADcDSfWNXEH+tQwdYE9hbLlJEh3RxV2+Jp5Ri0U2yxE0sHIXFfDhl9VRkz5Gp ctUzc5REVRs+iilGWBTVyc0oAb3XitmtuWN0vTndCk7oEixJZ+zWjKJontZATUrTXkd1 wb/vkaH+1OcyuMr8XlowTjye0DWJM6RCOalEK+heuF/DctqGoC/K9Gs6shFOBFgVnF9Q P9pA== X-Gm-Message-State: AFqh2kpKgK6xrrECpPIJM048l6Tk6nBFB7FQIYeiytow070uiDdKGmgZ w5cl8wMm/XBFC8JH7uUEtFsu1W5uk7LD1Q== X-Google-Smtp-Source: AMrXdXvmTvtqNgnLmk5cJBAbDrjb+KO72AdUFlftYDJxQYh1kAE6n5piXmE8Ycn0o1vqWSclx0yQcQ== X-Received: by 2002:ac8:7542:0:b0:3ab:28ea:d849 with SMTP id b2-20020ac87542000000b003ab28ead849mr104356817qtr.10.1673563506735; Thu, 12 Jan 2023 14:45:06 -0800 (PST) Received: from [192.168.1.66] (108-250-206-84.lightspeed.nworla.sbcglobal.net. [108.250.206.84]) by smtp.googlemail.com with ESMTPSA id fv13-20020a05622a4a0d00b003ae189c7454sm5785761qtb.91.2023.01.12.14.45.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Jan 2023 14:45:06 -0800 (PST) Message-ID: Date: Thu, 12 Jan 2023 16:45:05 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 To: pgsql-admin@lists.postgresql.org Content-Language: en-US From: Ron Subject: Synthetic keys and index fillfactor Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk (This mostly pertains to recreating a PK on an existing table.) Is there any reason to have the PK index on an ever-increasing field (for example SERIAL, sequence or timestamp fed by clock_timestamp() at time zone 'UTC') be anything but fillfactor=100? New records will always be added to the "lower right hand corner" of the tree, so having 20% empty space in the rest of the tree would just waste space (mainly buffers, but disk space could even start to add up on Very Big Tables). -- Born in Arizona, moved to Babylonia.