Re: [HACKERS] PATCH: multivariate histograms and MCV lists

Tomas Vondra <tomas.vondra@2ndquadrant.com>

From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, Alvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@enterprisedb.com>, Mark Dilger <hornschnorter@gmail.com>, Adrien Nayrat <adrien.nayrat@dalibo.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-16T12:23:52Z
Lists: pgsql-hackers

On 07/15/2018 11:36 AM, Dean Rasheed wrote:
> On 13 July 2018 at 18:27, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>> I'm not so sure. The issue is that a lot of the MCV deductions depends
>> on whether we can answer questions like "Is there a single match?" or
>> "If we got a match in MCV, do we need to look at the non-MCV part?" This
>> is not very different from the single-column estimates, except of course
>> here we need to look at multiple columns.
>>
>> The top-level clauses allow us to make such deductions, with deeper
>> clauses it's much more difficult (perhaps impossible). Because for
>> example with (a=1 AND b=1) there can be just a single match, so if we
>> find it in MCV we're done. With clauses like ((a=1 OR a=2) AND (b=1 OR
>> b=2)) it's not that simple, because there may be multiple combinations
>> and so a match in MCV does not guarantee anything.
> 
> Actually, it guarantees a lower bound on the overall selectivity, and
> maybe that's the best that we can do in the absence of any other
> stats.
> 

Hmmm, is that actually true? Let's consider a simple example, with two 
columns, each with just 2 values, and a "perfect" MCV list:

     a | b | frequency
    -------------------
     1 | 1 | 0.5
     2 | 2 | 0.5

And let's estimate sel(a=1 & b=2). Your proposed algorithm does this:

1) sel(a=1) = 0.5
2) sel(b=2) = 0.5
3) total_sel = sel(a=1) * sel(b=2) = 0.25
4) mcv_sel = 0.0
5) total_sel = Max(total_sel, mcv_sel) = 0.25

How is that a lower bound? Or what is it lower than?


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. Convert pre-existing stats_ext tests to new style

  2. Add support for multivariate MCV lists

  3. Improve ANALYZE's strategy for finding MCVs.

  4. Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL)

  5. Try again to fix accumulation of parallel worker instrumentation.

  6. Adjust psql \d query to avoid use of @> operator.

  7. Message style fixes

  8. Add security checks to selectivity estimation functions