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.92) (envelope-from ) id 1jE0G4-0005ib-9a for pgsql-admin@arkaria.postgresql.org; Tue, 17 Mar 2020 00:39:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jE0G2-00040x-0M for pgsql-admin@arkaria.postgresql.org; Tue, 17 Mar 2020 00:38:58 +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 1jE0G1-00040o-KR for pgsql-admin@lists.postgresql.org; Tue, 17 Mar 2020 00:38:57 +0000 Received: from mail-qk1-x731.google.com ([2607:f8b0:4864:20::731]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jE0Fu-0000fd-L9 for pgsql-admin@postgresql.org; Tue, 17 Mar 2020 00:38:57 +0000 Received: by mail-qk1-x731.google.com with SMTP id e11so29670215qkg.9 for ; Mon, 16 Mar 2020 17:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=8Phs8ovMbwTNn7Hli4gUUcKr1eTUpKWcx1HIt9zRSUI=; b=Avb5MNZMlTlD6mp4ErBh9sv+lQT7LZHK0wNd9U3Vg4voCLyxeuCJ1NKaZ4VF+Wdddx dLPA22Ec3TnLgUS2WtuKfexQ13wDRmtAbqcWZbgkzahAxRZlu3hqNZh+keDApV0TZHas by9MOTM38bILoaUFlAMDlKRT5aQUugY6JgSgc/xKpJzznCkQOujopaAeTrDT3TUU0ITf zpinpgcAa0hJ9NUHNRxgd2fuesVVhJ0Egzn9leLH/5/bmNXktU6pTHDCgNMLIHzrJnpf m0x3Bjp4+TzueaLmxCtuCjIEhFxQq5NlP7w3EwqnVs5X83QImDaIc3wqbSDXGUpor05K a9WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=8Phs8ovMbwTNn7Hli4gUUcKr1eTUpKWcx1HIt9zRSUI=; b=eIN8YIGs5X7m7Jv0iB7PBc9hpk4dBS0mWAtTjuHk+G8wMRU5Fm5TU09ZDHEBp9F9PM MzBeX9S3quGlY7la+dGP1JaY5H6qXEaDNtaOdaVlgRMVvD1WJIt8I0ZpOlWsNyFUmSuy 2jH6SYSD/3tgTiO46KO3Iu3AsxGcAwCcMMzPAA6/q0JpPt3k4TVutP6BLpoWdp76yl8R N6An6pHmhEiHA8gzGqvb/qCw7vemflEJtePEQmIQpKgl29eP3TYNUYsxaHiWZ8PXeZXB t0mQZmO1Bvr0zSEe2EY3dHI+lxxqqBGIEapeidbxgiU7c/u7eGXi2DtmtoKSG+vL3vd6 2PxQ== X-Gm-Message-State: ANhLgQ1unQaoTznRtn1FuH27hturz0DEoKCFsd+vO2n5BPoyrMtgN92i oAcYj8N6fqmYbkmjYshcOnm8Ah1Y X-Google-Smtp-Source: ADFU+vth5m/vfNIy7mokye4MOXv/FWvh5KY8Fq7aoY9aVH28cVATLQcnXqEEGXZvUVu6Y8Z4Jneadw== X-Received: by 2002:ae9:edc4:: with SMTP id c187mr2527806qkg.369.1584405527832; Mon, 16 Mar 2020 17:38:47 -0700 (PDT) Received: from ?IPv6:2603:9000:f609:a03d:f531:e5f8:e2be:4926? ([2603:9000:f609:a03d:f531:e5f8:e2be:4926]) by smtp.gmail.com with ESMTPSA id p65sm907136qke.42.2020.03.16.17.38.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Mar 2020 17:38:47 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-52E8BE75-A1DB-41F5-A7D8-2355CDA4D68E Content-Transfer-Encoding: 7bit From: John Scalia Mime-Version: 1.0 (1.0) Subject: Re: Explain plan on a Select query Date: Mon, 16 Mar 2020 20:38:45 -0400 Message-Id: <62998F18-D770-4521-9CE0-C11A565825FE@gmail.com> References: Cc: Pgsql-admin In-Reply-To: To: Jeff Janes X-Mailer: iPad Mail (17D50) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --Apple-Mail-52E8BE75-A1DB-41F5-A7D8-2355CDA4D68E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Well, after rebuilding the statistics on the table at least three separate t= imes, the errant messages finally disappeared. BTW, this was on an AWS RDS i= nstance, which I know is not the favorite of any development team member. It= just threw me a bit, as the first analyze did not clear the issue. Sent from my iPad > On Mar 16, 2020, at 6:43 PM, Jeff Janes wrote: >=20 > =EF=BB=BF >> On Mon, Mar 16, 2020 at 12:26 PM John Scalia wro= te: >=20 >> I=E2=80=99m a bit confused on an explain plan I just generated for a sele= ct statement. The plan=E2=80=99s first line begins with the word =E2=80=9CAp= pend=E2=80=9D followed by the usual (cost....) data. What in the world is an= Append doing here? I=E2=80=99ve recently performed another analyze on the t= able, btw.=20 >=20 > A top level Append would generally be used when you use a UNION ALL, or yo= u have inheritance. > =20 >>=20 >> Also, the query does not seem to be using an index, as the explain shows a= pair of sequential scans, speaking of which, the second sequential scan sho= ws it=E2=80=99s on a table, called _test. Which is a little strange, c= onsidering that does not exist. >=20 > Is that the name of the table, or the alias for that table? >=20 > "-> Seq Scan on pgbench_accounts pa_alias (cost=3D0.00..527869.00 rows= =3D20000000 width=3D97)" >=20 > "pgbench_accounts" is the actual table, "pa_alias" is the alias for it.=20= >=20 >=20 > PostgreSQL will create alias for table when it needs to, but I've never se= en it do so by adding "_test" to the end. Usually it adds "_" and an intege= r. >=20 > It would really help to be able to see either the plan or the query, or bo= th. >=20 > Cheers, >=20 > Jeff --Apple-Mail-52E8BE75-A1DB-41F5-A7D8-2355CDA4D68E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Well, after rebuilding the statistics on th= e table at least three separate times, the errant messages finally disappear= ed. BTW, this was on an AWS RDS instance, which I know is not the favorite o= f any development team member. It just threw me a bit, as the first analyze d= id not clear the issue.

Sent from my iPad

On Mar 16, 2020, at 6:43 PM, Jeff J= anes <jeff.janes@gmail.com> wrote:

=EF=BB=BF
On Mon, Mar 16, 2020 at 12:26 PM John Scalia <jayknowsunix@gmail.com> wrote:
I=E2=80=99m a b= it confused on an explain plan I just generated for a select statement. The p= lan=E2=80=99s first line begins with the word =E2=80=9CAppend=E2=80=9D follo= wed by the usual (cost....) data. What in the world is an Append doing here?= I=E2=80=99ve recently performed  another analyze on the table, btw.

A top level Append would generally be use= d when you use a UNION ALL, or you have inheritance.
 
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex">
Also, the query does not seem to be using an index, as the explain shows a p= air of sequential scans, speaking of which, the second sequential scan shows= it=E2=80=99s on a table, called <table>_test. Which is a little stran= ge, considering that does not exist.

Is t= hat the name of the table, or the alias for that table?

=
  "->  Seq Scan on pgbench_accounts pa_alias  (cost=3D= 0.00..527869.00 rows=3D20000000 width=3D97)"

"p= gbench_accounts" is the actual table, "pa_alias" is the alias for it. <= br>


PostgreSQL will create alias for= table when it needs to, but I've never seen it do so by adding "_test" to t= he end.  Usually it adds "_" and an integer.

I= t would really help to be able to see either the plan or the query, or both.=

Cheers,

Jeff
<= /div>
= --Apple-Mail-52E8BE75-A1DB-41F5-A7D8-2355CDA4D68E--