Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: improving GROUP BY estimation
From: Mark Dilger <hornschnorter@gmail.com>
In-Reply-To: <56D867C3.3040309@2ndquadrant.com>
Date: Thu, 3 Mar 2016 09:40:04 -0800
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <904EB795-BCDD-4D68-8D44-274B40C4B2E9@gmail.com>
References: <56CD0381.5060502@2ndquadrant.com>
 <03A3B58D-6A2D-44FE-9B03-E21948CFCBAA@gmail.com>
 <56CFA373.3060105@2ndquadrant.com>
 <7D1A65E8-7ED8-4268-9C24-8EA07E95D2BC@gmail.com>
 <56CFCE96.5080306@2ndquadrant.com>
 <CAPpHfdtEiXqj52kuGMEnw6EShrzj-0tFYwwxPqzdFvxYfCr+tQ@mail.gmail.com>
 <56D867C3.3040309@2ndquadrant.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


> On Mar 3, 2016, at 8:35 AM, Tomas Vondra <tomas.vondra@2ndquadrant.com> w=
rote:
>=20
> Hi,
>=20
> On 03/03/2016 12:53 PM, Alexander Korotkov wrote:
>> Hi, Tomas!
>>=20
>> I've assigned to review this patch.
>>=20
>> I've checked version estimate-num-groups-v2.txt by Mark Dilger.
>> It applies to head cleanly, passes corrected regression tests.
>>=20
>> About correlated/uncorrelated cases. I think now optimizer mostly assumes
>> all distributions to be independent. I think we should follow this
>> assumption in this case also until we have fundamentally better option (=
like
>> your multivariate statistics).
>>=20
>> @@ -3438,9 +3438,9 @@ estimate_num_groups(PlannerInfo *root, List *group=
Exprs,
>> double input_rows,
>> reldistinct =3D clamp;
>>=20
>> /*
>> -* Multiply by restriction selectivity.
>> +* Estimate number of distinct values expected in given number of rows.
>> */
>> -reldistinct *=3D rel->rows / rel->tuples;
>> +reldistinct *=3D (1 - powl((reldistinct - 1) / reldistinct, rel->rows));
>>=20
>> /*
>> * Update estimate of total distinct groups.
>>=20
>> I think we need way more explanation in comments here (possibly with
>> external links). For now, it looks like formula which appears from nowhe=
re.
>=20
> I thought the details (particularly the link to stackexchange, discussing=
 the formula) would be enough, but let me elaborate.
>=20
> The current formula
>=20
>    reldistinct *=3D rel->rows / rel->tuples;
>=20
> simply multiplies the ndistinct estimate with selectivity. So when you se=
lect 1% of the table, the estimate says we'll see 1% of ndistinct values. B=
ut clearly that's naive, because for example when you have 10k distinct val=
ues and you select 10M rows, you should expect nearly all of them in the sa=
mple.

The current formula assumes total dependence between the
columns.  You can create tables where this is true, and the
formula gives precisely the right estimate.  I'm not claiming this
is common, or that it should be the default assumption, but it
is one end of the spectrum of possible correct estimates.

> And that's what the formula does - it gives you the expected number of di=
stinct values, when selecting 'k' values from 'd' distinct values with repl=
acements:
>=20
>    count(k, d) =3D d * (1 - ((d-1)/d) ^ k)
>=20
> It's assuming the distinct values are equally probable (uniform distribut=
ion) and that the probabilities do not change (that's the "with replacement=
").

The new formula assumes total independence between the
columns.  You can likewise create tables where this is true,
and you did so upthread, and for those tables it gives precisely
the right estimate.  This is the other end of the spectrum of
possible correct estimates.

In the absence of multivariate statistics, either because you
haven't committed that work yet, or because the multivariate
data the planner needs hasn't been collected, choosing an
estimate exactly in the middle of the spectrum (whatever
that would mean mathematically) would minimize the
maximum possible error in the estimate.

I have the sense that my point of view is in the minority, because
the expectation is the problems caused by independence
assumptions will only be fixed when multivariate statistics are
implemented and available, and so we should just keep the
independence assumptions everywhere until that time.  I
tend to disagree with that, on the grounds that even when that
work is finished, we'll never have complete coverage of every
possible set of columns and what their degree of dependence
is.

Perhaps I am badly mistaken.

Can somebody more familiar with the issues than I am please
disabuse me of my wrongheadedness?

Mark Dilger


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