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 1kVP6W-0007Cl-LB for pgsql-performance@arkaria.postgresql.org; Thu, 22 Oct 2020 01:09:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kVP6V-0001J1-1C for pgsql-performance@arkaria.postgresql.org; Thu, 22 Oct 2020 01:09:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVP6U-0001Iu-Kn for pgsql-performance@lists.postgresql.org; Thu, 22 Oct 2020 01:09:18 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kVP6O-0005NF-4u for pgsql-performance@lists.postgresql.org; Thu, 22 Oct 2020 01:09:17 +0000 Received: by mail-io1-xd35.google.com with SMTP id r9so5188847ioo.7 for ; Wed, 21 Oct 2020 18:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=YQivlVOzSkxxeAwfC/BNteLQ0AInBTqtw3aR4cwgD4E=; b=tAzvK3K/fbg1ycZSB533XI1pLx6OBEZcB0/AwbgmWx6Lagkpied6lTCvf7yKpoc94I AIkKOGkaAnaTnr948HhAJDjF/WQRPUea5NI6V8k/yKfyojPsP5lEo3lxfs9dpta2oiF3 9hNHI6iGXYgPViMJOSE8mKCe/oJA1OKHk+Ry/ZPSuF9xI45/fSnh3ahG9wR0zUitqD3Y TGHhGvHkkgj96RCGsuRRJ8ogyxI6g0i8vVPZbj/UDa7K5Y+1EMedfrDGeAhEJmBI4Gn/ gg55/bnoMcQSkjbIX29T6okIvuKY82Q9cQBZAaFRy6na6eFckuaCrjB/zciYRGpX264e +ZpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=YQivlVOzSkxxeAwfC/BNteLQ0AInBTqtw3aR4cwgD4E=; b=fCna973A0vl9ngL445FRDci9rx1bM/swzLCaCGEec/ldPMZPnh0G3QkR2QmWlTchiD 33isEjbWGUWQur6DTZRda3rGXhfdtR0hNFfqFf0IDdkfnAJ4+BzWQJsGTvD1Jv21vy/6 2h3ZZ7IhHkU0cKXj0XR6+im+qbNED8rg5MOthPTizph0/b1iYvLUyL3J2sZ7gOyJpUCK U5wHR+fVLbwUs7jLExltp4oCnNi9H+JzCuJxj6+GuX1y2LG6bLQpiqzDdi61dpvtjxV9 2KWvZ1mR4D5DtlPF8lgenvFDF0d//jEkk9WKpcvhrQ7DSK1j3zgijRmlP4sFfw9xqa5H RSyg== X-Gm-Message-State: AOAM531ta6iyErR/zNqthq7rQ9aGBh0JQoo8eOpgryEnrl5NXk7snBVj mZ8GWH6GdiWIANrUXejtm5z4NRQBmrJSvg== X-Google-Smtp-Source: ABdhPJyW51tHUsvDzCph9AY+ZhnHFDJnTmBbZ04k6YzdHhBEpOzWWfuNYCiIUTku6grBCq/d+ytlyQ== X-Received: by 2002:a6b:ce1a:: with SMTP id p26mr182959iob.94.1603328950841; Wed, 21 Oct 2020 18:09:10 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id m86sm106764ilb.44.2020.10.21.18.09.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2020 18:09:09 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id C2DAE800665; Wed, 21 Oct 2020 20:09:07 -0500 (CDT) Date: Wed, 21 Oct 2020 20:09:07 -0500 From: Justin Pryzby To: Nagaraj Raj Cc: pgsql-performance@lists.postgresql.org Subject: Re: Query performance Message-ID: <20201022010907.GQ9241@telsasoft.com> References: <2026306342.2139401.1603326749019.ref@mail.yahoo.com> <2026306342.2139401.1603326749019@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2026306342.2139401.1603326749019@mail.yahoo.com> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Oct 22, 2020 at 12:32:29AM +0000, Nagaraj Raj wrote: > Hi, I have long running query which running for long time and its planner always performing sequnce scan the table2.My gole is to reduce Read IO on the disk cause, this query runns more oftenly ( using this in funtion for ETL).  > > table1: transfer_order_header(records 2782678)table2: transfer_order_item ( records: 15995697)here is the query: > > set work_mem = '688552kB';explain (analyze,buffers)select     COALESCE(itm.serialnumber,'') AS SERIAL_NO,             COALESCE(itm.ITEM_SKU,'') AS SKU,             COALESCE(itm.receivingplant,'') AS RECEIVINGPLANT,  COALESCE(itm.STO_ID,'') AS STO, supplyingplant,            COALESCE(itm.deliveryitem,'') AS DELIVERYITEM,     min(eventtime) as eventtime  FROM sor_t.transfer_order_header hed,sor_t.transfer_order_item itm  where hed.eventid=itm.eventid group by 1,2,3,4,5,6 It spends most its time writing tempfiles for sorting, so it (still) seems to be starved for work_mem. |Sort (cost=1929380.04..1946051.01 rows=6668390 width=172) (actual time=50031.446..52823.352 rows=5332010 loops=3) First, can you get a better plan with 2GB work_mem or with enable_sort=off ? If so, maybe you could make it less expensive by moving all the coalesce() into a subquery, like | SELECT COALESCE(a,''), COALESCE(b,''), .. FROM (SELECT a,b, .. GROUP BY 1,2,..)x; Or, if you have a faster disks available, use them for temp_tablespace. -- Justin