mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-18 07:23:23 +02:00
The strategy of GIN index scan is driven by opclass-specific extract_query method. This method that needed search mode is GIN_SEARCH_MODE_ALL. This mode means that matching tuple may contain none of extracted entries. Simple example is '!term' tsquery, which doesn't need any term to exist in matching tsvector. In order to handle such scan key GIN calculates virtual entry, which contains all TIDs of all entries of attribute. In fact this is full scan of index attribute. And typically this is very slow, but allows to handle some queries correctly in GIN. However, current algorithm calculate such virtual entry for each GIN_SEARCH_MODE_ALL scan key even if they are multiple for the same attribute. This is clearly not optimal. This commit improves the situation by introduction of "exclude only" scan keys. Such scan keys are not capable to return set of matching TIDs. Instead, they are capable only to filter TIDs produced by normal scan keys. Therefore, each attribute should contain at least one normal scan key, while rest of them may be "exclude only" if search mode is GIN_SEARCH_MODE_ALL. The same optimization might be applied to the whole scan, not per-attribute. But that leads to NULL values elimination problem. There is trade-off between multiple possible ways to do this. We probably want to do this later using some cost-based decision algorithm. Discussion: https://postgr.es/m/CAOBaU_YGP5-BEt5Cc0%3DzMve92vocPzD%2BXiZgiZs1kjY0cj%3DXBg%40mail.gmail.com Author: Nikita Glukhov, Alexander Korotkov, Tom Lane, Julien Rouhaud Reviewed-by: Julien Rouhaud, Tomas Vondra, Tom Lane |
||
---|---|---|
.. | ||
adminpack | ||
amcheck | ||
auth_delay | ||
auto_explain | ||
bloom | ||
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_prewarm | ||
pg_standby | ||
pg_stat_statements | ||
pg_trgm | ||
pg_visibility | ||
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 | ||
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.