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 1lFL91-0006Ik-Qg for pgsql-performance@arkaria.postgresql.org; Thu, 25 Feb 2021 18:13:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lFL90-0008G1-IV for pgsql-performance@arkaria.postgresql.org; Thu, 25 Feb 2021 18:13:46 +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 1lFL90-0008Fs-7I for pgsql-performance@lists.postgresql.org; Thu, 25 Feb 2021 18:13:46 +0000 Received: from mail-qk1-x732.google.com ([2607:f8b0:4864:20::732]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lFL8s-0005SL-Ca for pgsql-performance@lists.postgresql.org; Thu, 25 Feb 2021 18:13:45 +0000 Received: by mail-qk1-x732.google.com with SMTP id q85so6525688qke.8 for ; Thu, 25 Feb 2021 10:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=americanefficient-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oU7MlsiSRjKWSeRaHcAHSKPRDyEe0jKfntAgs/oZfPI=; b=kHkHDh+IZ6nm6n5t5jq2kCsg18iS1lBcWJzVvwg4ly/VzO/xMj5vHYkGFfKq3jXf42 b6cc5pCGhdKAMRwo92F18oHF/6u8BdUgc5Ls8Iq/N6qUNcORuIawWUkdF2YyAzxChnUR LVCCz7av/Yzq+RL+Nw2Hyeapa13O7hTAWm19RQ/XIpR5vMewpZkSRxodD/Iri53CsGWN s6p+HxYa9HkPOJYNNhOEXFu9RtpTm8t6zX9iAj9VRPiwH+CErFdSRUpBEUKXvDA4ILpY g6l0On5jnQac4flMrQDZmuQ01ZBlHYc5n/STUoNHIsz14OmpHcFOp46ue66egmmYvCfO 5yKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oU7MlsiSRjKWSeRaHcAHSKPRDyEe0jKfntAgs/oZfPI=; b=hE6e5jSaCqH/dWq42tC1z7+EEouohjS2BeIHE5y4Erjz0dUZexYrjxcMqvtl8+TisX PxO6tRxgH8qnvp6DO3hzymeTsn1Qutp9SP0N0dE5ijM259knJeJoncNFbhtVay1aZB0/ F6R9PKauyvqP3AFFHAPh2eHOTYl92pg2zuxqDKU1/zBNwjGk3PkBfE8o8gvSe51rBBe0 opFJDFQ72KQmLh6rXIptUgr91h+JtNRNm6F/ss/kvU9ao9UBNZEi2X28krFa1LlrAINu zJvUQ2XWfHOn7eMUGabaV+O1yaXFcqxY6hQFwybYUEcSxRh2rn+64X1J0b1ZyihsUnrM kNoA== X-Gm-Message-State: AOAM530CEQwLFQgyqEMJV5RwKLaBP2JXEF3IZH7Fje6MvTeUhQXcADy6 Zcv+0o5fMMBT6CNHjMU+/YePIg== X-Google-Smtp-Source: ABdhPJxlhQ51V6qx8+5OeDxNNTTp96iZZVcMf+Ppyn3kfAl3Qpnqw2o2knt7CjhmAFyXuRGeRQ83cw== X-Received: by 2002:a05:620a:22f7:: with SMTP id p23mr3774750qki.435.1614276816542; Thu, 25 Feb 2021 10:13:36 -0800 (PST) Received: from [10.0.1.7] (cpe-98-26-29-163.nc.res.rr.com. [98.26.29.163]) by smtp.gmail.com with ESMTPSA id p35sm4059537qtb.23.2021.02.25.10.13.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Feb 2021 10:13:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: Postgres performance comparing GCP and AWS From: Philip Semanchuk In-Reply-To: Date: Thu, 25 Feb 2021 13:13:33 -0500 Cc: Julien Rouhaud , Maurici Meneghetti , pgsql-performance@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: <4BD5DB5D-972B-4683-8E2B-88EEDBDFDC7D@americanefficient.com> References: To: Igor Gois X-Mailer: Apple Mail (2.3654.60.0.2.21) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Feb 24, 2021, at 10:11 AM, Igor Gois = wrote: >=20 > Hi, Julien >=20 > Your hypothesis about network transfer makes sense. The query returns = a big size byte array blobs. >=20 > Is there a way to test the network speed against the instances? I have = access to the network speed in gcp (5 Mb/s), but don't have access in = aws rds. Perhaps what you should run is EXPLAIN ANALYZE SELECT...? My = understanding is that EXPLAIN ANALYZE executes the query but discards = the results. That doesn=E2=80=99t tell you the network speed of your = AWS instance, but it does isolate the query execution speed (which is = what I think you=E2=80=99re trying to measure) from the network speed. Hope this is useful. Cheers Philip >=20 >=20 > Em qua., 24 de fev. de 2021 =C3=A0s 10:35, Julien Rouhaud = escreveu: > Hi, >=20 > On Wed, Feb 24, 2021 at 6:14 AM Maurici Meneghetti > wrote: > > > > I have 2 postgres instances created from the same dump (backup), one = on a GCP VM and the other on AWS RDS. The first instance takes 18 = minutes and the second one takes less than 20s to run this simples = query: > > SELECT "Id", "DateTime", "SignalRegisterId", "Raw" FROM = "SignalRecordsBlobs" WHERE "SignalSettingId" =3D 103 AND "DateTime" = BETWEEN '2019-11-28T14:00:12.540200000' AND = '2020-07-23T21:12:32.249000000'; > > I=E2=80=99ve run this query a few times to make sure both should be = reading data from cache. > > I expect my postgres on GPC to be at least similar to the one = managed by AWS RDS so that I can work on improvements parallelly and = compare. > > > > DETAILS: > > [...] > > Planning time: 456.315 ms > > Execution time: 776.976 ms > > > > Query explain for Postgres on AWS RDS: > > [...] > > Planning time: 0.407 ms > > Execution time: 14.87 ms >=20 > Those queries were executed in respectively ~1s and ~15ms (one thing > to note is that the slower one had less data in cache, which may or > may note account for the difference). Does those plans reflect the > reality of your slow executions? If yes it's likely due to quite slow > network transfer. Otherwise we would need an explain plan from the > slow execution, for which auto_explain can help you. See > https://www.postgresql.org/docs/11/auto-explain.html for more details. >=20 >=20 > --=20 > Att, >=20 > Igor Gois | S=C3=B3cio Consultor > (48) 99169-9889 | Skype: igor_msg > Site | Blog | LinkedIn | Facebook | Instagram >=20 > =20