Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gy2UY-0005Jd-Th for pgsql-performance@arkaria.postgresql.org; Sun, 24 Feb 2019 22:43:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gy2UX-0006Qi-B8 for pgsql-performance@arkaria.postgresql.org; Sun, 24 Feb 2019 22:43:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gy2UW-0006Qb-VD for pgsql-performance@lists.postgresql.org; Sun, 24 Feb 2019 22:43:25 +0000 Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gy2UT-0001B7-SE for pgsql-performance@postgresql.org; Sun, 24 Feb 2019 22:43:24 +0000 Received: by mail-io1-xd2c.google.com with SMTP id x4so6070828ion.2 for ; Sun, 24 Feb 2019 14:43:21 -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:in-reply-to:user-agent; bh=6n6qUp8NBI/kd4hUq3Axi50DTSB039OMa1gaveWUUcs=; b=1Ydb7X2hLHXEaxx2SkSlg7ipd5NRYdMPb3DdqKCkSNPGIQDhiYWZG7bVHyDYin0pAt RfNm90X3Xs721nkq9Pm9eVjSnUBU4+WVmHjXZ0564Sk02lrVTv2yQbeh3sc+lnobsg4r FjVRksSNdR1ETenh4CeJlIUd7/TIj9dGlUP6Hu87y1bAu1dGZDi/8cCZwOVVbOs2jaoZ gpNecQqarY5HgVSmQPxpAR56esJ870O6NtRBM9rCmjg+FsvXooZY9HohbttDfW2sJLws V7gW4M4s3hsIDD6YUhgfpz4fjJ8Fni+9giQB0b1FrD7cpRvr5vvoS/ZhBOzw/bCzPkI8 OWQw== 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:in-reply-to:user-agent; bh=6n6qUp8NBI/kd4hUq3Axi50DTSB039OMa1gaveWUUcs=; b=l6lGEucFidVwJ08N0xA9m2RGFxbtmWzWlMTy2Tagl+EAJf5qHjQ04sc1AOsyfbk3W0 XkpodUcnwVLlxK1fVTFLP0vKltaF2Sp/HaofW/sEkhI6YsBuyrQiMaCo/Cg3gQVWzBgT ZP8SezRRZzTBjw5RrFE13gaotsh38qccgk+eUN2EHLZST/W9NrwTmEqrhWxJ6rZyX7Az Jnic4Rvat/nNZ9fPoYDypCpw8F5Gsp4C0DxiUMqYUa89Jm37cJfF13C1NwKw5KEo9N1P F0BDf9MqCaX5Kn5FwaiicQYNcmtNEPZA0+mSK0sm3GkZJRU4ubKrVYDL1BiU6O1bV/rO +RSA== X-Gm-Message-State: AHQUAuZRKCb8gEJ2Ise5mJ3VGRE/VPWHEnkR510RNkAXV+gJtrgSoHyU 5vUlcjcd2JXCUs9qVXKcbyavTw== X-Google-Smtp-Source: AHgI3IaKa+tG+wZI7cKK+INNyYBFEESIxlzv9d0RscmmtEXpEXtRPq4GdE+RvPnjxPRDKGfuihU1NQ== X-Received: by 2002:a5d:8190:: with SMTP id u16mr8658200ion.238.1551048199760; Sun, 24 Feb 2019 14:43:19 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id v202sm4091112ita.13.2019.02.24.14.43.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Feb 2019 14:43:19 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id D2C78800C83; Sun, 24 Feb 2019 16:43:17 -0600 (CST) Date: Sun, 24 Feb 2019 16:43:17 -0600 From: Justin Pryzby To: Corey Huinker Cc: Gunther , pgsql-performance@postgresql.org Subject: Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks. Message-ID: <20190224224317.GL28750@telsasoft.com> References: <33bae6e3-1c5a-77f0-ee99-408fbf0fbb83@gusw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Feb 24, 2019 at 04:34:34PM -0500, Corey Huinker wrote: > I think your solution may be something like this: > 1. Create a new table, same columns, partitioned on the pending column. > 2. Rename your existing queue table old_queue to the partitioned table as a > default partition. > 3. Rename new table to queue > 4. add old_queue as the default partition of queue > 5. add a new partition for pending = true rows, set the fillfactor kind of FYI, the "default partition" isn't just for various and sundry uncategorized tuples (like a relkind='r' inheritence without any constraint). It's for "tuples which are excluded by every other partition". And "row migration" doesn't happen during "ALTER..ATTACH", only UPDATE. So you'll be unable to attach a partition for pending=true if the default partition includes any such rows: |ERROR: updated partition constraint for default partition "t0" would be violated by some row I think you'll need to schedule a maintenance window, create a new partitioned heirarchy, and INSERT INTO queue SELECT * FROM old_queue, or similar. Justin