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 1mcgQ1-0007vC-Pa for pgsql-sql@arkaria.postgresql.org; Tue, 19 Oct 2021 04:08:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mcgQ0-000893-7t for pgsql-sql@arkaria.postgresql.org; Tue, 19 Oct 2021 04:08:04 +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 1mcgPz-00088u-UG for pgsql-sql@lists.postgresql.org; Tue, 19 Oct 2021 04:08:04 +0000 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mcgPx-00066n-3w for pgsql-sql@lists.postgresql.org; Tue, 19 Oct 2021 04:08:03 +0000 Received: by mail-lj1-x233.google.com with SMTP id r6so3607252ljg.6 for ; Mon, 18 Oct 2021 21:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=y24WaiARKO7YqW9XD0TKIYUksm9alfdmFfWTG7XZEJs=; b=FjOfZsABaeavY9/XyJCF8bVc5JFijYim0ogWuq/fwGut2MvwyndS72qSsopg3Gz+YO sPmYvl39eVk+F9YQV95RAAvw13VdIrAsk0euUQKYfWCdc2YrL7+tWbFLIWALL7hfM9A0 ffnnhxrM07w9wf32JFk3YODSK+0MAWcO7Ml1bsnTLqjFlIXax9ajdEALrl7HDnyRcG/T SjiISjxu3VFMWjBKJ+zXzReZaQgFezYIpQYBTfAcfqmGoz6PnZnpnaWvWqwWeZDWNb/E cccxpNRaQu1icMX2aQo0Yc1eKq8uZhTOdV7B5Mjw+Ox7hj5oG0Pmbg40E6tXxCNRLfXd R6ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=y24WaiARKO7YqW9XD0TKIYUksm9alfdmFfWTG7XZEJs=; b=RxmMerImgwphuJikw+Ya9oM5dzHAM+h8hRScYdbbAXwfXFdspMZ4Lki0M96l+RdAR8 ejB/CYDa8LixxNO8/Bo5AXYmgRPuhAbEZGqhPPS638Rlppw3wOU2ukgRoG/Kdl/MwY0E lzFmslXItln8UfHJdkwXFSjr8WFBpDKQuyF0oCPdOzHciirhg4C4bMKE+5/XHhvFPBxd iR1z02DwNY2ORWTAipAtdKOc3y4cMqr6nbnjoJcCKzEl15LMVnCfu1SYR6R8DDnL/qil OggOo8YW3ZgWzhwf7k7CGqkWnn+7pYUQyL/FMonfc6No2r7VatrBK9CBUbWw5aDYrWKQ IuWg== X-Gm-Message-State: AOAM533RUf3vg2svqHvi8zBWjxcbsF+GuXAWzfXybcu0yS1TkyMWSYzp M5oyF4NWX2IcNbebQttlbDFE3LsHAbh1FHkXUD8= X-Google-Smtp-Source: ABdhPJxju036tholStO17W0ytgpVss1QRBIv8GJcktHTL1nBKtndyLBuPjhstPsISwXajzquQsGn0A1sVi1RxRfrDYY= X-Received: by 2002:a2e:9e07:: with SMTP id e7mr4130757ljk.457.1634616479795; Mon, 18 Oct 2021 21:07:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: aditya desai Date: Tue, 19 Oct 2021 09:37:48 +0530 Message-ID: Subject: Re: Query out of memory To: Geri Wright , pgsql-sql Content-Type: multipart/alternative; boundary="0000000000009f4ec705ceacceda" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000009f4ec705ceacceda Content-Type: text/plain; charset="UTF-8" This is how I received a query from the App Team. They have migrated from Oracle to Postgres. I see in Oracle where it is working fine and also has the same joins. Some of the developers increased the work_mem. I will try and tone it down. Will get back to you. Thanks. On Tue, Oct 19, 2021 at 1:28 AM Geri Wright wrote: > Hi, > It looks like you have Cartesian joins in the query. Try updating your > where clause to include > > And g.columnname = t.columnname > And t.columnname2 = a.columnname2 > > On Mon, Oct 18, 2021, 12:43 PM aditya desai wrote: > >> Hi, >> I am running the below query. Table has 21 million records. I get an Out >> Of Memory error after a while.(from both pgadmin and psql). Can someone >> review DB parameters given below. >> >> select t.*,g.column,a.column from >> gk_staging g, transaction t,account a >> where >> g.accountcodeis not null AND >> g.accountcode::text <> '' AND >> length(g.accountcode)=13 AND >> g.closeid::text=t.transactionid::text AND >> subsrting(g.accountcode::text,8)=a.mask_code::text >> >> Below are system parameters. >> shared_buffers=3GB >> work_mem=2GB >> effective_cache_size=10GB >> maintenance_work_mem=1GB >> max_connections=250 >> >> I am unable to paste explain plan here due to security concerns. >> >> Regards, >> Aditya. >> >> --0000000000009f4ec705ceacceda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is how I received a query from the App Team. They hav= e migrated from Oracle to Postgres. I see in Oracle where it is working fin= e and also has the same joins. Some of the developers increased the work_me= m. I will try and tone it down. Will get back to you. Thanks.

On Tue, Oct 19= , 2021 at 1:28 AM Geri Wright <ge= ri.w123@gmail.com> wrote:
Hi,
It looks like you h= ave Cartesian joins in the query.=C2=A0 =C2=A0Try updating your where claus= e to include

And g.columnname = =3D t.columnname=C2=A0
And t.columnname2 =3D a.colum= nname2

On Mon, Oct 18, 2021, 12:43 PM aditya desai <admad123@gmail.com>= wrote:
Hi,
I am running the below query. Table has 21 million rec= ords. I get an Out Of Memory error after a while.(from both pgadmin and psq= l). Can someone review DB parameters given below.

= select t.*,g.column,a.column from
gk_staging g, transaction t,acc= ount a
where
g.accountcodeis not null AND
g.a= ccountcode::text <> '' AND
length(g.accountcode)=3D= 13 AND
g.closeid::text=3Dt.transactionid::text AND
subs= rting(g.accountcode::text,8)=3Da.mask_code::text

B= elow are system parameters.
shared_buffers=3D3GB
work_m= em=3D2GB
effective_cache_size=3D10GB
maintenance_work_m= em=3D1GB
max_connections=3D250

I am unab= le to paste explain plan here due to security concerns.

Regards,
Aditya.

--0000000000009f4ec705ceacceda--