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.96) (envelope-from ) id 1wPLgz-000fbQ-1P for pgsql-general@arkaria.postgresql.org; Tue, 19 May 2026 14:45:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPLgw-004eKt-2z for pgsql-general@arkaria.postgresql.org; Tue, 19 May 2026 14:45:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPLgw-004eKl-0S for pgsql-general@lists.postgresql.org; Tue, 19 May 2026 14:45:07 +0000 Received: from fout-b4-smtp.messagingengine.com ([202.12.124.147]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wPLgs-00000000O6X-0BdE for pgsql-general@postgresql.org; Tue, 19 May 2026 14:45:06 +0000 Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49]) by mailfout.stl.internal (Postfix) with ESMTP id 9BF7D1D0016D; Tue, 19 May 2026 10:44:58 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-09.internal (MEProxy); Tue, 19 May 2026 10:44:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1779201898; x=1779288298; bh=gfJk91JglFDtLpNZWQhG9YeryzUg86tf8RUhMp1CApk=; b= BpIULZ0yFlEtrBAeTFtPh/TY25H+57FfnZRatomwjvMw6bYwX+5sgYLPmjOjaSHj z0E6ceHH2uWemozF5e+gdNVeWmYoNb3R9zCfIISHr2A5sY6BM9qMB2qDu+POYOdE BeOLm6jB4c31ble41jwi+IU1MPt4a6pCpjTStBqfRuEQLuAastElD6i1XX07DFK1 mdCg0REF9P6H6HWZfV5DB3Oe8qBmVB+rg/OwMH/XtyZm6YFxvTdXNn5ndov2QOvQ OX9KJ2ZTGXyaYJvdCDwCHaFnfxCbfU0eag+IVhwOshckqAMdVWH2t6PomSrF+RzR rGssno7HdgrM5S7byinv7w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1779201898; x=1779288298; bh=g fJk91JglFDtLpNZWQhG9YeryzUg86tf8RUhMp1CApk=; b=GkwDnmlflFu8OQBne t7UCBXGIvfVwXHOZ5DRmyOXRQNLPuTXtmYoNF1UgVT4n0C2AXOalk/XKCrXwXAPz ehf2crYLBE+14YLxTDMckTSiWJJ9gtnU1A/oilfJI6LRSc2PgbQVnuomJVll7aSP qXt9rjDVXjZ3gY2CWcMbxqVeJtX9JLa38hN4a2XLJeTxQC7fTIMyEl77L1eneooI tzQogyWVe5js4yTXJztz1jp7IqXaiIQkpEG9tZ/A0oXwMiujp3AtnqLw9kKstkaD QnJZcbDUcIwvsXyeDFnVRPXMtb6vtcyQ9AQzPUBNs8gifBurS8GjZAml/G4fbgnN RV3zw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgddugedvtddvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvfhfhjggtgfesthekredttddvjeenucfhrhhomheptegurhhirghn ucfmlhgrvhgvrhcuoegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhmqe enucggtffrrghtthgvrhhnpeffleegieefgfevudehtdfhkeeutdffjeevgeffgeejvedt hefgudeiteefheejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhmpdhnsggp rhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehmrghrthhinh hmuhgvlhhlvghrsehnohhrthhhfigvshhtvghrnhdrvgguuhdprhgtphhtthhopehpghhs qhhlqdhgvghnvghrrghlsehpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 May 2026 10:44:57 -0400 (EDT) Message-ID: Date: Tue, 19 May 2026 07:44:57 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: scaling up from t1n to 60 million records To: Martin Mueller , "pgsql-general@postgresql.org" References: Content-Language: en-US From: Adrian Klaver 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 5/19/26 7:27 AM, Martin Mueller wrote: > I use Postgres with a GUI frontend (Aquafold) as a very large > spreadsheet on steroids that analyzes rare or defective spellings in a > corpus of 65,000 texts and1.5 billion words.  I typically extract  data > from the corpus with python scripts, turn them into tables and load them > into the database. > > > On my Mac with 32 GB of memory performance is OK with queries that > typically within seconds extract data rows from tables  with up to ten > million rows.  If the result set is large, I suspect that most of time > machine's time is spent displaying result sets. I have used indexing > sparingly. While it helps, the time savings often don't matter much. This is going to need more information: 1) Postgres version. 2) The table schema including indexes. 3) An example of the query. 4) Where you are measuring the time. 5) The client you are displaying the results in. > > > I am thinking about scaling up to table with about 60 million rows.  Are > there things to do or watch out for? Or should I proceed on the > assumption that that 60 million records are within scope and that the > added timecost is roughly linear? > > Martin Mueller > > Professor emeritus of English and Classics > > Northwestern University > -- Adrian Klaver adrian.klaver@aklaver.com