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 1ibhdF-0002kZ-2G for pgsql-performance@arkaria.postgresql.org; Mon, 02 Dec 2019 09:04:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ibhdD-0005e5-Qi for pgsql-performance@arkaria.postgresql.org; Mon, 02 Dec 2019 09:04:35 +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 1ibhdD-0005dy-Da for pgsql-performance@lists.postgresql.org; Mon, 02 Dec 2019 09:04:35 +0000 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ibhdA-0006qX-Jk for pgsql-performance@lists.postgresql.org; Mon, 02 Dec 2019 09:04:35 +0000 Received: by mail-wm1-x343.google.com with SMTP id f129so22243287wmf.2 for ; Mon, 02 Dec 2019 01:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=EjdU4xRAQX0DIkRhnmfx08tCEbYn7dcct2OzwH0pahE=; b=GJi04gaPz3zqsSjuq6x+4sFv5NflkKK0Ne6oxRDcRRonAqdhC69LaboK9Vv5IrApj+ 94Nrn6PBTf2gu0olNSNU9mJG6qsQ6ZZyDvFAi0Z20jSO/pmh47qRsRETqL8WWxK7FmEw Ll8KfBT/2nz3/qNUy0nUF3LYMBR4HAi9z2NmQcH1chAcL87KY39/3sHBp9z40p9t4fg+ 3qF0mrLbh58OszQnYstNtDIuSStZGu9LpGNyreEiWfYaexd9LeO064YqtVaVX+agLju0 6Funbn3eEwRXUKph5W2Eq85kPh9NIcp7oTBZmaquHApnH66QkKy2rjBh5Ie03ycV3rUd Pd6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=EjdU4xRAQX0DIkRhnmfx08tCEbYn7dcct2OzwH0pahE=; b=RVBgKIjCyw6+Na3kDkfGymjFShO2M53e0mUdm1QIiucjMKQD3dDo1PggyRNSBS5ugu vX9+wy5BMHIRQMbNzn7H8TTzNSgP+IeOkC6za4ESbKKpAjnc/6RhLeqgnrm69j2p/7dM GrulzMih9BxkdmMB4tM79n7uMlniucOA2EvXTjDMKdT6QigUBICsJaTHHUF5ZHKQIu5c nSdDaTkhnywtSRg/3hNcqdibksSUTFQuimfJPaZ9vgu8kAgviCu8PYTdGBHnxpCxWf9j hVmwKiarEFuaJht7Gt5atE5JQTt4vM5/kIbRgbd7PlZx2TRwP3HNmmxk4iTIoyxSlOd4 hL+w== X-Gm-Message-State: APjAAAVtm/Pxf4SbLA5yDQFuNOn3kpfSyPBWeLumF9t/U5k2n4gEPN7c kSyrNM2PRpLO54jIBy1u8hLYYA== X-Google-Smtp-Source: APXvYqwiehS3g+ZDFKAOi9u0b1iyK9OGO7RB2NgCxfEeX+6r6kqbtrZSmSBLW4mbk3Mh6YXCckNDag== X-Received: by 2002:a1c:f407:: with SMTP id z7mr25597815wma.148.1575277471217; Mon, 02 Dec 2019 01:04:31 -0800 (PST) Received: from localhost.localdomain (217-149-169-193.nat.highway.telekom.at. [217.149.169.193]) by smtp.gmail.com with ESMTPSA id h2sm40583337wrt.45.2019.12.02.01.04.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2019 01:04:30 -0800 (PST) Message-ID: Subject: Re: Considerable performance downgrade of v11 and 12 on Windows From: Laurenz Albe To: Eugene Podshivalov , pgsql-performance@lists.postgresql.org Date: Mon, 02 Dec 2019 10:04:29 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sat, 2019-11-30 at 22:47 +0300, Eugene Podshivalov wrote: > It sounds strange but the "type" is indeed impacting the overall > performance somehow. > I've just tried to execute the following sequence of commands on a > fresh new database with PostreSQL v10 and both the copy and primary > key commands performed as slow as in v11 and 12. > > SET synchronous_commit TO OFF; > SET client_encoding TO 'UTF8'; > COPY ways FROM program 'cmd /c "type D:\ways.txt"'; > ALTER TABLE ONLY ways ADD CONSTRAINT pk_ways PRIMARY KEY (id); > > Regards > > пт, 29 нояб. 2019 г. в 15:22, Eugene Podshivalov : > > Laurenz, > > There is no way to run copy without the "type" on v11. See this thread > > https://www.postgresql.org/message-id/CAKHmqNCfTMM6%3DPqc6RUMEQ_2BPfo5KGGG-0fzRXZCVooo%3DwdNA%40mail.gmail.com > > > > My machine is running on NVMe disks, so the I/O subsystem very strong. > > The 100% overload is not constant but periodical, as if there are some > > kind of dumps for recovery performed in the background. Is it an option to split the file into parts of less than 2GB in size? Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com