mirror of
https://github.com/postgres/postgres.git
synced 2025-07-23 03:21:12 +03:00
config
contrib
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
bench
data
expected
sql
.gitignore
Makefile
_int.h
_int_bool.c
_int_gin.c
_int_gist.c
_int_op.c
_int_selfuncs.c
_int_tool.c
_intbig_gist.c
intarray--1.0--1.1.sql
intarray--1.1--1.2.sql
intarray--1.2.sql
intarray--unpackaged--1.0.sql
intarray.control
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
Makefile
README
contrib-global.mk
doc
src
.dir-locals.el
.gitattributes
.gitignore
COPYRIGHT
GNUmakefile.in
HISTORY
Makefile
README
README.git
aclocal.m4
configure
configure.in
113b3d903b
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 01783ac36 we were not careful about this in
other intarray code paths either.)
Back-patch the <@ fixes to all supported versions, since this was
broken from day one.
Patch by me; thanks to Alexander Korotkov for review.
Discussion: https://postgr.es/m/458.1565114141@sss.pgh.pa.us