Re: [HACKERS] PATCH: multivariate histograms and MCV lists
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>, Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@enterprisedb.com>,
Bruce Momjian <bruce@momjian.us>, Mark Dilger <hornschnorter@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-03-10T22:27:54Z
Lists: pgsql-hackers
On Mon, 11 Mar 2019 at 06:36, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > > On 3/9/19 7:33 PM, Dean Rasheed wrote: > > I wonder if it's possible to write smaller, more targeted tests. > > Currently "stats_ext" is by far the slowest test in its group, and I'm > > not sure that some of those tests add much. It ought to be possible to > > write a function that calls EXPLAIN and returns a query's row > > estimate, and then you could write tests to confirm the effect of the > > new stats by verifying the row estimates change as expected. > > Sure, if we can write more targeted tests, that would be good. But it's > not quite clear to me how wrapping EXPLAIN in a function makes those > tests any faster? I've not looked at the tests in question, but if they're executing an inferior plan is used when no extended stats exists, then maybe that's why they're slow. I think Dean might mean to create a function similar to explain_parallel_append() in partition_prune.sql then write tests that check the row estimate with EXPLAIN (COSTS ON) but strip out the other costing stuff instead of validating that the poor plan was chosen. > On 3/10/19 2:09 PM, Dean Rasheed wrote: > > 12). bms_member_index() should surely be in bitmapset.c. It could be > > more efficient by just traversing the bitmap words and making use of > > bmw_popcount(). Also, its second argument should be of type 'int' for > > consistency with other bms_* functions. > > Yes, moving to bitmapset.c definitely makes sense. I don't see how it > could use bms_popcount() though. I think it could be done by first checking if the parameter is a member of the set, and then if so, count all the bits that come on and before that member. You can use bmw_popcount() for whole words before the specific member's word then just bitwise-and a bit mask of a bitmapword that has all bits set for all bits on and before your parameter's BITNUM(), and add the bmw_popcount of the final word bitwise-anding the mask. bms_add_range() has some masking code you could copy. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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