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 1lpA4Q-0006rX-K0 for pgsql-performance@arkaria.postgresql.org; Fri, 04 Jun 2021 13:41:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lpA4P-00048a-AV for pgsql-performance@arkaria.postgresql.org; Fri, 04 Jun 2021 13:41:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lpA4P-00047g-20 for pgsql-performance@lists.postgresql.org; Fri, 04 Jun 2021 13:41:05 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lpA4K-0007dg-MQ for pgsql-performance@lists.postgresql.org; Fri, 04 Jun 2021 13:41:04 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 154Deolf143098; Fri, 4 Jun 2021 09:40:50 -0400 From: Tom Lane To: David Rowley cc: Taras Savchuk , "pgsql-performance@lists.postgresql.org" Subject: Re: PgSQL 12 on WinSrv ~3x faster than on Linux In-reply-to: References: Comments: In-reply-to David Rowley message dated "Sat, 05 Jun 2021 00:42:34 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <143096.1622814050.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 04 Jun 2021 09:40:50 -0400 Message-ID: <143097.1622814050@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > On Fri, 4 Jun 2021 at 23:53, Taras Savchuk wrote: >> Any ideas what's wrong? For me such a big difference on identical datab= ases/queries looks strange. > It's pretty difficult to say. You've not provided any useful details > about the workload you're running. > If this "register 10 _same_ documents" thing requires running some > query, then you might want to look at EXPLAIN (ANALYZE, BUFFERS) for > that query. You might want to consider doing SET track_io_timing =3D > on; Perhaps Linux is having to read more buffers from disk than > Windows. The first thing that comes to mind for me is fsync working correctly (i.e. actually waiting for the disk write) in Linux but not in Windows. On a weird VM stack like you've got, it's not hard for that sort of thing to go wrong. Needless to say, if that's the issue then the apparent performance win is coming at the cost of crash safety. pg_test_fsync might help detect such a problem. regards, tom lane