Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qrlpx-005lAI-A9 for pgsql-admin@arkaria.postgresql.org; Sat, 14 Oct 2023 21:06:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qrlpu-008moH-OH for pgsql-admin@arkaria.postgresql.org; Sat, 14 Oct 2023 21:06:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qrlpu-008mo8-D0 for pgsql-admin@lists.postgresql.org; Sat, 14 Oct 2023 21:06:15 +0000 Received: from mail-yw1-x1136.google.com ([2607:f8b0:4864:20::1136]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qrlpo-000UvH-DO for pgsql-admin@lists.postgresql.org; Sat, 14 Oct 2023 21:06:13 +0000 Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-5a7ab31fb8bso37728527b3.1 for ; Sat, 14 Oct 2023 14:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697317566; x=1697922366; darn=lists.postgresql.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YXUZOPd+RBclgDNUUIcYuxgAn0ucGR4rs3d27dOhM+8=; b=fbkP0FlYSV+RAIOZDkTDm9QJOjS985wpEudhltqK4FM0L6ihaqeJ3E4bskw/LvMdbN 3lcO77Xg1sU0r83zgibUlUAQxt8zFSVa9vhrvf1bG3sVZwmNg762fUod9jJ2+z8RK4jl lsUYhO4+4TotUHEln5fPYFNbwCcbwzqA5sGeSfzpbzUVjdmflLmL4Ah1hVIjkVUtOzwk eS9A/4NG3Rc86AABwBgwhCvxBiyR7/ezbCPLHwhYv9ohrixYhxCy4PlCPA6dqHQsmfa0 Awdka9bjcrVss7JxR5cbJ7HB0OQE64NAI3LOHsihNMA4YlTUXhQHsfkJDhHy8sxgVuhz tl5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697317566; x=1697922366; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YXUZOPd+RBclgDNUUIcYuxgAn0ucGR4rs3d27dOhM+8=; b=kd9i80BzJ/Jug91nllLcQdd+lj5/YMHdSz+pnBT20cZRP1Mh5dmFIDfbXJwmKiY54r 20HvcTqhUv9kQiVZ/D7VFXuQPzscQY/4CglTfziqRI56jhubOymLkhYe9DTDnPeb8gqu hDCy1DDEdLCPAdSVJpCLLsXE5NToD23AhsqSTO12JKJYK2MOeo42oYNuDdiIDPz0M8LI PCY4P+EVgi0sJED61Q/HxHoV4UYuoW/qzd/GYFCV9c0k1HMdOtXRhh6tcHv7vpWS/D3A FBfvJUbaVJPSld//xGjKX6Ce75OdH6Sej22XhQdcFXz/SerNT+M5lVWQXam8Yte0yJGb U0QQ== X-Gm-Message-State: AOJu0Yy+mfzZ6cqlYl7H+9od/ia8/YR+mAIjcYedXjlnXgUlJStlLbPZ c0q7s0qsEpf8N2ILpJjTqy7JKe1mb3M= X-Google-Smtp-Source: AGHT+IHQBfTkPicybb/EDlSGPvz9kOfAhkZRIk+2MYjw6u35t9lvqG19NsVjt/k0QJHbkefhPw6x2Q== X-Received: by 2002:a0d:f8c4:0:b0:59c:b61:898b with SMTP id i187-20020a0df8c4000000b0059c0b61898bmr30670713ywf.52.1697317566129; Sat, 14 Oct 2023 14:06:06 -0700 (PDT) Received: from ?IPV6:2600:1700:bd2c:b810:514a:d454:bbd8:a150? ([2600:1700:bd2c:b810:514a:d454:bbd8:a150]) by smtp.googlemail.com with ESMTPSA id z84-20020a816557000000b0059b2be24f88sm818927ywb.143.2023.10.14.14.06.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Oct 2023 14:06:05 -0700 (PDT) Message-ID: <7a373e01-e93a-4059-93cb-cdcd484aa972@gmail.com> Date: Sat, 14 Oct 2023 16:06:05 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Big table and partition Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: From: Ron In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 10/14/23 15:46, Rajesh Kumar wrote: > Hi > > In my env, I have a table 30GB That's not necessarily huge. > where data is getting inserted directly whenever the new block is created > in block chain... How many records for that 30GB? How many days (or months)? Will the rate of insertion increase? What retention is required? > Sometimes, there is a query running to check whether the recent block is > created ? > > I have been asked to do partition, i said manager since we are not at all > using the past data, partition is not required. Instead we can stop the > sync (downtime not required), change the name of table , create a new > table with same structure with original name and keep only tis month data. > Then sync the blockchain so that new data will come to newly created table > and old data will be there simply as a storage as we r not selecting any > query from old data... I've been burned by inefficient queries when having to add a date column to the primary key.  We "departitioned" every table except the two that had large bytea columns and stored up to 200GB per month. > > Note: on a longer run, data will keep on coming in whenever new block is > created. > > Is that right ? Any suggestions ? Better options ? In my experience, Postgresql deletes based on an indexed date field are pretty efficient.  Sometimes I delete a month of data at once, and sometimes one day of data at a time. -- Born in Arizona, moved to Babylonia.