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 1kkqea-0000iI-3a for pgsql-performance@arkaria.postgresql.org; Thu, 03 Dec 2020 15:36:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kkqeY-0002Iu-W2 for pgsql-performance@arkaria.postgresql.org; Thu, 03 Dec 2020 15:36:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkqeY-0002Im-J6 for pgsql-performance@lists.postgresql.org; Thu, 03 Dec 2020 15:36:18 +0000 Received: from mail-il1-x144.google.com ([2607:f8b0:4864:20::144]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kkqeV-0005jw-E3 for pgsql-performance@lists.postgresql.org; Thu, 03 Dec 2020 15:36:17 +0000 Received: by mail-il1-x144.google.com with SMTP id y9so2315506ilb.0 for ; Thu, 03 Dec 2020 07:36:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=vEqowfLoeusNPlK8LLUciiQ/2oS3XTzYLWLwS/026x0=; b=Msvu35sccvJjntQsPfBvyDAbpu8JcIJRnQ7DC8549U6ZKVXHMVQ6fz44rw3oIWyERY nwFbt+BddUaLvMs3ktZTEhv0xoOJubX3AGOvLExBmkhaQh9XcHVHA/q4l7fsBaOAGDWe jln0MbKQLtfW86TI6iwRpjkKCK9mJRzPOMaMKdCNlTWy9Cdq0GBN4ic+pGaWnxBS2IQa Z7UutPhL+OsvpnN6Ho1ad9hhiKL1AoZqKGGlceldwyB8Q56dnuADxDg8P5ElJ+mBplJK UB5AnN3aHfPNB9iUkvutx3N8cHsJr6u7i7Tz9qIRqou5Dh4chp3IrLYdOXbIBaWe2O/9 O0gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=vEqowfLoeusNPlK8LLUciiQ/2oS3XTzYLWLwS/026x0=; b=tYkd7XtzTLUBOFIXQ3qvggcRysNzKMa7Mz9Aqm5khjbn+nBAKkib87ALpGVc0eXpUZ IjhCieWtokHqPdF0ck843hFm5MISSe7aj+ZXw+fdtRv7UWq0Z7Zm6nOrlW6kvj/IA/5O BJ8hw7ydBf9ZHVXI9LJsfY1iBPNnZfWg1Ym2qKaAEHEjmkVAkSDfxXKetJpTzgziArJv YNkIQeSopU2AVSdMS7SGcK+T7ZDrXyRf9jVq281BkayzS4OW9qmkUyUfBL1kpc1xajgR wpVRc1M4QZhdE03BIonXDgnEMKA3hH20VGheWwcVxava2TPWY8CDWDIN0TZpQQreWDwZ oQoQ== X-Gm-Message-State: AOAM533yqm1o1ioRdBE/jWNpgP/timxjlxLoslYLI2OIaZOdK3XZOoWQ tEy88M+MZTpTdXImA6/Qzti6Cw== X-Google-Smtp-Source: ABdhPJw7WbVuD5VwULwILRfRGuftWy59QSqK4xL4j4PpQOsFGh79Tzplkkez9KDo2Vxv/nbQwaH9cA== X-Received: by 2002:a05:6e02:c2a:: with SMTP id q10mr3431590ilg.92.1607009774530; Thu, 03 Dec 2020 07:36:14 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id t21sm1016345ild.86.2020.12.03.07.36.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 07:36:13 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id AEE9080077E; Thu, 3 Dec 2020 09:36:12 -0600 (CST) Date: Thu, 3 Dec 2020 09:36:12 -0600 From: Justin Pryzby To: Ravikumar Reddy Cc: Atul Kumar , pgsql-performance Subject: Re: time taking deletion on large tables Message-ID: <20201203153612.GM24052@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Dec 03, 2020 at 08:43:57PM +0530, Ravikumar Reddy wrote: > Please try the code below. Execute all the statements in one transaction. > > select * into new_table from old_table where type = 'abcz'; > truncate table old_table; > inesrt into old_table select * from new_table; This looks like advice for when most of the rows are being deleted, but I don't think that's true here. It'd need to LOCK old_table, first, right? Also, truncate isn't MVCC safe. Atul: What server version? Do you have an index on feed_definition_id ? https://wiki.postgresql.org/wiki/Slow_Query_Questions If explain (analyze,buffers) SELECT runs in a reasonable time for that query, include its output. On Thu, Dec 3, 2020 at 8:16 PM Atul Kumar wrote: > The feed_posts table has over 50 Million rows. > > When I m deleting all rows of a certain type that are over 60 days old. > > When I try to do a delete like this: it hangs for an entire day, so I > need to kill it with pg_terminate_backend(pid). > > DELETE FROM feed_posts > WHERE feed_definition_id = 'bf33573d-936e-4e55-8607-72b685d2cbae' > AND created_at > '2020-05-11 00:00:00' > AND created_at < '2020-05-12 00:00:00'; > > So– I need help in figuring out how to do large deletes on a > production database during normal hours. > > please help me on deleting the rows, Do I need to anything in postgres > configuration ? > or in table structure ?