mirror of
https://github.com/zebrajr/postgres.git
synced 2025-12-06 12:20:15 +01:00
261f89a976
The lossy-counting algorithm that ANALYZE uses to identify most-common array elements has a notion of cutoff frequency: elements with frequency greater than that are guaranteed to be collected, elements with smaller frequencies are not. In cases where we find fewer MCEs than the stats target would permit us to store, the cutoff frequency provides valuable additional information, to wit that there are no non-MCEs with frequency greater than that. What the selectivity estimation functions actually use the "minfreq" entry for is as a ceiling on the possible frequency of non-MCEs, so using the cutoff rather than the lowest stored MCE frequency provides a tighter bound and more accurate estimates. Therefore, instead of redundantly storing the minimum observed MCE frequency, store the cutoff frequency when there are fewer tracked values than we want. (When there are more, then of course we cannot assert that no non-stored elements are above the cutoff frequency, since we're throwing away some that are; so we still use the minimum stored frequency in that case.) Notably, this works even when none of the values are common enough to be called MCEs. In such cases we previously stored nothing in the STATISTIC_KIND_MCELEM pg_statistic slot, which resulted in the selectivity functions falling back to default estimates. So in that case we want to construct a STATISTIC_KIND_MCELEM entry that contains no "values" but does have "numbers", to wit the three extra numbers that the MCELEM entry type defines. A small obstacle is that update_attstats() has traditionally stored a null, not an empty array, when passed zero "values" for a slot. That gives rise to an MCELEM entry that get_attstatsslot() will spit up on. The least risky solution seems to be to adjust update_attstats() so that it will emit a non-null (but possibly empty) array when the passed stavalues array pointer isn't NULL, rather than conditioning that on numvalues > 0. In other existing cases I don't believe that that changes anything. For consistency, handle the stanumbers array the same way. In passing, improve the comments in routines that use STATISTIC_KIND_MCELEM data. Particularly, explain why we use minfreq / 2 not minfreq as the estimate for non-MCE values. Thanks to Matt Long for the suggestion that we could apply this idea even when there are more than zero MCEs. Reported-by: Mark Frost <FROSTMAR@uk.ibm.com> Reported-by: Matt Long <matt@mattlong.org> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/PH3PPF1C905D6E6F24A5C1A1A1D8345B593E16FA@PH3PPF1C905D6E6.namprd15.prod.outlook.com |
||
|---|---|---|
| .. | ||
| amcheck | ||
| auth_delay | ||
| auto_explain | ||
| basebackup_to_shell | ||
| basic_archive | ||
| bloom | ||
| bool_plperl | ||
| btree_gin | ||
| btree_gist | ||
| citext | ||
| cube | ||
| dblink | ||
| dict_int | ||
| dict_xsyn | ||
| earthdistance | ||
| file_fdw | ||
| fuzzystrmatch | ||
| hstore | ||
| hstore_plperl | ||
| hstore_plpython | ||
| intagg | ||
| intarray | ||
| isn | ||
| jsonb_plperl | ||
| jsonb_plpython | ||
| lo | ||
| ltree | ||
| ltree_plpython | ||
| oid2name | ||
| pageinspect | ||
| passwordcheck | ||
| pg_buffercache | ||
| pg_freespacemap | ||
| pg_logicalinspect | ||
| pg_overexplain | ||
| pg_prewarm | ||
| pg_stat_statements | ||
| pg_surgery | ||
| pg_trgm | ||
| pg_visibility | ||
| pg_walinspect | ||
| pgcrypto | ||
| pgrowlocks | ||
| pgstattuple | ||
| postgres_fdw | ||
| seg | ||
| sepgsql | ||
| spi | ||
| sslinfo | ||
| start-scripts | ||
| tablefunc | ||
| tcn | ||
| test_decoding | ||
| tsm_system_rows | ||
| tsm_system_time | ||
| unaccent | ||
| uuid-ossp | ||
| vacuumlo | ||
| xml2 | ||
| contrib-global.mk | ||
| Makefile | ||
| meson.build | ||
| README | ||
The PostgreSQL contrib tree
---------------------------
This subtree contains porting tools, analysis utilities, and plug-in
features that are not part of the core PostgreSQL system, mainly
because they address a limited audience or are too experimental to be
part of the main source tree. This does not preclude their
usefulness.
User documentation for each module appears in the main SGML
documentation.
When building from the source distribution, these modules are not
built automatically, unless you build the "world" target. You can
also build and install them all by running "make all" and "make
install" in this directory; or to build and install just one selected
module, do the same in that module's subdirectory.
Some directories supply new user-defined functions, operators, or
types. To make use of one of these modules, after you have installed
the code you need to register the new SQL objects in the database
system by executing a CREATE EXTENSION command. In a fresh database,
you can simply do
CREATE EXTENSION module_name;
See the PostgreSQL documentation for more information about this
procedure.