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 1izOJm-0008M7-GX for pgsql-performance@arkaria.postgresql.org; Wed, 05 Feb 2020 17:18:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1izOJk-0008DQ-Op for pgsql-performance@arkaria.postgresql.org; Wed, 05 Feb 2020 17:18:24 +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 1izOHM-0003sI-8z for pgsql-performance@lists.postgresql.org; Wed, 05 Feb 2020 17:15:56 +0000 Received: from mail-yw1-xc34.google.com ([2607:f8b0:4864:20::c34]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1izOHJ-0000rt-KW for pgsql-performance@lists.postgresql.org; Wed, 05 Feb 2020 17:15:55 +0000 Received: by mail-yw1-xc34.google.com with SMTP id a125so2990510ywe.12 for ; Wed, 05 Feb 2020 09:15:53 -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=F/7R8+KXyI9JFngRdu0wxeh3N1ByJW4WKiq91QraYbQ=; b=fbOmHGxd819M1MU1OA5RLmHaBCePl0inlk2FTGOQ4qaMAkoy13LPgp3zuXqZnNlVm6 /V+GuwLrjGGR+IMzA83+KDyC0TJz9QahXaMCXsxl0dTQtU1mEVDMV96Ax6QBZk9kmG+t WmqxGnOYp2U9DK0SUAxIw+ljMGiYPfATBfkKNoqcFqqvqH/Qfa8o2M7MDH9+MlhKgFSt jXAfbewJwsonlj8/gvL8jIZC3a+30oc40an6WQL0djCpry0nVvl7iscezhPIHnIJ4sAD Ew3yaFzecTjnIY0F3VPnegeLVIkZjqUBwA1P7cq0M0wdnHTzMj+mJ+OzingJlQ9Nlu4h klew== 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=F/7R8+KXyI9JFngRdu0wxeh3N1ByJW4WKiq91QraYbQ=; b=rpklPWfJpV0u9tn2J2sgdxSQGRRXruKgJMnFalhjQw45jhED1vRaLr3PyQqHcuv5Hv XK9JaR0EOTtn3G6VXDOF7eWaZs7QLp8wyigU9EHfGGsAzxneBHE8ZQm1cFkDeehSpKT4 btpma24y7DefgXJ5jw47rlsKd1d66me5gs9KPrd4Uc1iVgiQW21DZfL4TiWO/Y4ZTSEz ugKaay6GFsL+R8jf5ALQ9aLmY9W/Kl9LrLLd82PPAIOonQPV2hx6UdTqILjDT3HaqfJc Dqj12najcCThnfrGOyfPGDQNaO/dsY5NUdRFsic6qISgjIDxR7omd93wObiG7ayFtYgr aX2w== X-Gm-Message-State: APjAAAV1XCQkBhm/Ph3GyjGyQvWosG32fcRbDiHsbJUY1hLMZ55Pg/Jo iV0EVLU/JZ8iEJ6FFCiZU3VJfg== X-Google-Smtp-Source: APXvYqx1DZPBH8K0PDAlS3T3sa/mbwxSXK5pSKhojW4IKc6VDVbAfEWXAQi646HchZ9HuhHzA333EQ== X-Received: by 2002:a81:6c8b:: with SMTP id h133mr11246942ywc.239.1580922951301; Wed, 05 Feb 2020 09:15:51 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id x184sm174947ywg.4.2020.02.05.09.15.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Feb 2020 09:15:50 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 213E58006F0; Wed, 5 Feb 2020 11:15:49 -0600 (CST) Date: Wed, 5 Feb 2020 11:15:49 -0600 From: Justin Pryzby To: Arya F Cc: pgsql-performance@lists.postgresql.org Subject: Re: Writing 1100 rows per second Message-ID: <20200205171548.GB403@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Feb 05, 2020 at 12:03:52PM -0500, Arya F wrote: > I'm looking to write about 1100 rows per second to tables up to 100 million > rows. I'm trying to come up with a design that I can do all the writes to a > database with no indexes. When having indexes the write performance slows > down dramatically after the table gets bigger than 30 million rows. > > I was thinking of having a server dedicated for all the writes and have > another server for reads that has indexes and use logical replication to > update the read only server. Wouldn't the readonly server still have bad performance for all the wites being replicated to it ? > Would that work? Or any recommendations how I can achieve good performance > for a lot of writes? Can you use partitioning so the updates are mostly affecting only one table at once, and its indices are of reasonable size, such that they can fit easily in shared_buffers. brin indices may help for some, but likely not for all your indices. Justin