Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, Bruce Momjian
<bruce@momjian.us>, Alvaro Herrera <alvherre@2ndquadrant.com>,
Andres Freund <andres@anarazel.de>, Mark Dilger <hornschnorter@gmail.com>,
Adrien Nayrat <adrien.nayrat@dalibo.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-01-07T00:45:20Z
Lists: pgsql-hackers
FWIW the main unsolved issue (at least on the MCV part) is how it decides which items to keep in the list. As explained in [1], in the multivariate case we can't simply look at the group frequency and compare it to the average frequency (of the non-MCV items), which is what analyze_mcv_list() does in the single-column case. In the multivariate case we also case about observed vs. base frequency, i.e. we want the MCV list to include groups that are present singificantly more/less than product of per-column stats. I've repeatedly tried to come up with a criteria that would address that, but it seems rather difficult because we can't abandon the other criteria either. So the MCV list should include groups that match both (a) items that are statistically more common than the non-MCV part (i.e. the rule from per-column analyze_mcv_list) (b) items that are statistically more/less common than estimated from per-column stats (i.e. the new rule) Enforcing rule (a) seems reasonable because it ensures the MCV list includes all items more frequent than the last one. Without it, it's difficult to decide know whether the absent item is very common (but close to base frequency) or very uncommon (so less frequent than the last MCV item). So it's not clear to me how to best marry these two things. So far the only thing I came up with is looking for the last item where the frequency and base frequency are very different (not sure how exactly to decide when the difference becomes statistically significant), include all items with higher frequencies, and then do analyze_mcv_list() to also enforce (a). But it seems a bit cumbersome :-( [1] https://www.postgresql.org/message-id/8ac8bd94-478d-215d-e6bd-339f1f20a74c%402ndquadrant.com regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Convert pre-existing stats_ext tests to new style
- dbb984128ebf 12.0 landed
-
Add support for multivariate MCV lists
- 7300a699502f 12.0 landed
-
Improve ANALYZE's strategy for finding MCVs.
- b5db1d93d2a6 11.0 cited
-
Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL)
- 5564c1181548 11.0 cited
-
Try again to fix accumulation of parallel worker instrumentation.
- 8526bcb2df76 11.0 cited
-
Adjust psql \d query to avoid use of @> operator.
- 471d55859c11 11.0 cited
-
Message style fixes
- 821fb8cdbf70 11.0 cited
-
Add security checks to selectivity estimation functions
- e2d4ef8de869 10.0 cited