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 1jlJn5-0006jK-7w for pgsql-performance@arkaria.postgresql.org; Tue, 16 Jun 2020 22:10: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 1jlJn3-00020M-S4 for pgsql-performance@arkaria.postgresql.org; Tue, 16 Jun 2020 22:10:45 +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 1jlJn3-00020E-Kg for pgsql-performance@lists.postgresql.org; Tue, 16 Jun 2020 22:10:45 +0000 Received: from post.visena.com ([46.226.10.50]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.92) (envelope-from ) id 1jlJmx-0002f5-JG for pgsql-performance@lists.postgresql.org; Tue, 16 Jun 2020 22:10:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=visena.com; s=20141101.wh; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:To:From:Date; bh=x7FgURLr4YWBr9AyOvmVAf0zjdOB5csz43hTrMiwacc=; b=NXgG10i+TmP769P1W5/pCyma1nE5kB6+qbrPRjGJwPhwgy/bBW2cfrJ52jOhBTmQEon7m7sN/GZwk3WJ5rxwAkBt1nLe8k1d7KtxjnmBj0bbz4C4sMZ64BCPEpbzl5puki4SeaNXNJBUhxQUHS096lYCSRzCvLVEyW0PES+1uT0=; Received: from [10.0.1.10] (helo=tc7-visena.wh.internal.visena.com) by post.visena.com with esmtp (Exim 4.82) (envelope-from ) id 1jlJmw-0000If-4E for pgsql-performance@lists.postgresql.org; Wed, 17 Jun 2020 00:10:38 +0200 Received: from localhost ([127.0.0.1] helo=tc7-visena.wh.internal.visena.com) by tc7-visena.wh.internal.visena.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jlJmw-0007Z4-2M for pgsql-performance@lists.postgresql.org; Wed, 17 Jun 2020 00:10:38 +0200 Date: Wed, 17 Jun 2020 00:10:37 +0200 (CEST) From: Andreas Joseph Krogh To: pgsql-performance@lists.postgresql.org Message-ID: In-Reply-To: <20200616220526.GK20404@telsasoft.com> References: <574079062.1873527.1592339731136.ref@mail.yahoo.com> <574079062.1873527.1592339731136@mail.yahoo.com> <20200616220526.GK20404@telsasoft.com> Subject: Re: simple query running for ever MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_545_50424812.1592345437927" X-Mailer: Visena Mail 2.2.326 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------=_Part_545_50424812.1592345437927 Content-Type: multipart/related; boundary="----=_Part_546_1961463882.1592345437927" ------=_Part_546_1961463882.1592345437927 Content-Type: multipart/alternative; boundary="----=_Part_547_1538774442.1592345437936" ------=_Part_547_1538774442.1592345437936 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable P=C3=A5 onsdag 17. juni 2020 kl. 00:05:26, skrev Justin Pryzby >:=20 On Tue, Jun 16, 2020 at 08:35:31PM +0000, Nagaraj Raj wrote: > I wrote a simple query, and it is taking too long, not sure what is wron= g=20 in it, even its not giving EXPLAIN ANALYZE. > > select T0."physical_address_sid", T0."individual_entity_proxy_id",=20 T2."infrrd_hh_rank_nbr" > from "cms_prospects".PROSPECT T0 > --inner join "sas_prs_tmp".DEDUPE3583E3F18 T1 on=20 T0."individual_entity_proxy_id" =3D T1."individual_entity_proxy_id" > left join "cms_prospects".INDIVIDUAL_DEMOGRAPHIC T2 on=20 T0."individual_entity_proxy_id" =3D T2."individual_entity_proxy_id" Pardon me for saying so, but this query seems silly. It's self-joining a table on its PK, which I don't think could ever be use= ful. Where is the self-join?=20 -- Andreas Joseph Krogh=20 ------=_Part_547_1538774442.1592345437936 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable
P=C3=A5 onsdag 17. juni 2020 kl. 00:05:26, skrev Justin Pryzby <pryzby@telsasoft.com>:
On = Tue, Jun 16, 2020 at 08:35:31PM +0000, Nagaraj Raj wrote:
> I wrote a simple query, and it is taking too long, not sure what is wr= ong in it, even its not giving EXPLAIN ANALYZE.
>
> select T0."physical_address_sid", T0."individual_entity= _proxy_id", T2."infrrd_hh_rank_nbr"
> from "cms_prospects".PROSPECT T0
> --inner join "sas_prs_tmp".DEDUPE3583E3F18 T1 on T0."in= dividual_entity_proxy_id" =3D T1."individual_entity_proxy_id"= ;
> left join "cms_prospects".INDIVIDUAL_DEMOGRAPHIC T2 on T0.&q= uot;individual_entity_proxy_id" =3D T2."individual_entity_proxy_i= d"

Pardon me for saying so, but this query seems silly.

It's self-joining a table on its PK, which I don't think could ever be usef= ul.
=C2=A0
Where is the self-join?
=C2=A0
">
--
Andreas Joseph Krogh
------=_Part_547_1538774442.1592345437936-- ------=_Part_546_1961463882.1592345437927-- ------=_Part_545_50424812.1592345437927--