From: Tom Lane <tgl@sss.pgh.pa.us>
To: theolassonder@hotmail.com
cc: pgsql-docs@lists.postgresql.org
Subject: Re: Mistake in documentation for CREATE STATISTICS
In-reply-to: <156041783045.1348.6661129085836800862@wrigleys.postgresql.org>
References: <156041783045.1348.6661129085836800862@wrigleys.postgresql.org>
Comments: In-reply-to PG Doc comments form <noreply@postgresql.org>
	message dated "Thu, 13 Jun 2019 09:23:50 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29900.1560528066.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 14 Jun 2019 12:01:06 -0400
Message-ID: <29901.1560528066@sss.pgh.pa.us>
Precedence: bulk

PG Doc comments form <noreply@postgresql.org> writes:
> The example on https://www.postgresql.org/docs/11/sql-createstatistics.h=
tml
> seems wrong: instead of "EXPLAIN ANALYZE SELECT ..." it should say "EXPL=
AIN
> SELECT ...". If changed that way, the query optimizer estimates the numb=
er
> of rows at 1 and then 100 after statistics are created which is indeed h=
ow
> many the query returns. In the current wording, with ANALYZE, the query
> optimizer estimates the number of rows at 100 for both the first and sec=
ond
> select.

I think you're mistaking actual rows for estimated rows in the output
of EXPLAIN ANALYZE.

The point of using EXPLAIN ANALYZE here is just to make it easier to see
that the estimate is indeed wrong, by providing the actual count alongside
the estimate.  I don't think that taking out ANALYZE would be an
improvement.  For instance, in the first EXPLAIN I get

 Gather  (cost=3D1000.00..11675.10 rows=3D1 width=3D8) (actual time=3D1.21=
5..45.218 rows
=3D100 loops=3D1)

which without ANALYZE would just be

 Gather  (cost=3D1000.00..11675.10 rows=3D1 width=3D8)

The rows=3D1 estimate is equally wrong either way, but you don't get to
see the correct value without ANALYZE.

			regards, tom lane