From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: pgsql-performance@postgresql.org
Subject: Re: overestimate on empty table
In-reply-to: <20171111171945.GA2167@telsasoft.com>
References: <20171110204043.GS8563@telsasoft.com>
 <9772.1510348781@sss.pgh.pa.us> <20171111171945.GA2167@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Sat, 11 Nov 2017 11:19:45 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3999.1510422184.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 11 Nov 2017 12:43:04 -0500
Message-ID: <4000.1510422184@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Justin Pryzby <pryzby@telsasoft.com> writes:
> On Fri, Nov 10, 2017 at 04:19:41PM -0500, Tom Lane wrote:
>> One idea is to say that relpages =3D reltuples =3D 0 is only the state t=
hat
>> prevails for a freshly-created table, and that VACUUM or ANALYZE should
>> always set relpages to at least 1 even if the physical size is zero.

>> Dunno if that would confuse people.

> What about adding && rel->rd_rel->reltuples=3D=3D0, and make VACUUM/ANALY=
ZE instead
> set only reltuples=3D1, since that's already done at costsize.c: clamp_ro=
w_est()
> and therefor no additional confusion?

1 tuple in 0 pages is a physically impossible situation, so I'm quite
sure that way *would* confuse people.

			regards, tom lane


--=20
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance