mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-30 23:17:20 +02:00
contrib/intarray considers "arraycol <@ constant-array" to be indexable,
but its GiST opclass code fails to reliably find index entries for empty
array values (which of course should trivially match such queries).
This is because the test condition to see whether we should descend
through a non-leaf node is wrong.
Unfortunately, empty array entries could be anywhere in the index,
as these index opclasses are currently designed. So there's no way
to fix this except by lobotomizing <@ indexscans to scan the whole
index ... which is what this patch does. That's pretty unfortunate:
the performance is now actually worse than a seqscan, in most cases.
We'd be better off to remove <@ from the GiST opclasses entirely,
and perhaps a future non-back-patchable patch will do so.
In the meantime, applications whose performance is adversely impacted
have a couple of options. They could switch to a GIN index, which
doesn't have this bug, or they could replace "arraycol <@ constant-array"
with "arraycol <@ constant-array AND arraycol && constant-array".
That will provide about the same performance as before, and it will find
all non-empty subsets of the given constant-array, which is all that
could reliably be expected of the query before.
While at it, add some more regression test cases to improve code
coverage of contrib/intarray.
In passing, adjust resize_intArrayType so that when it's returning an
empty array, it uses construct_empty_array for that rather than
cowboy hacking on the input array. While the hack produces an array
that looks valid for most purposes, it isn't bitwise equal to empty
arrays produced by other code paths, which could have subtle odd
effects. I don't think this code path is performance-critical
enough to justify such shortcuts. (Back-patch this part only as far
as v11; before commit
|
||
---|---|---|
.. | ||
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.