postgresql/contrib/intarray/expected/_int.out

859 lines
13 KiB
Plaintext
Raw Normal View History

CREATE EXTENSION intarray;
-- Check whether any of our opclasses fail amvalidate
SELECT amname, opcname
FROM pg_opclass opc LEFT JOIN pg_am am ON am.oid = opcmethod
WHERE opc.oid >= 16384 AND NOT amvalidate(opc.oid);
amname | opcname
--------+---------
(0 rows)
SELECT intset(1234);
intset
--------
{1234}
(1 row)
SELECT icount('{1234234,234234}');
icount
--------
2
(1 row)
SELECT sort('{1234234,-30,234234}');
sort
----------------------
{-30,234234,1234234}
(1 row)
SELECT sort('{1234234,-30,234234}','asc');
sort
----------------------
{-30,234234,1234234}
(1 row)
SELECT sort('{1234234,-30,234234}','desc');
sort
----------------------
{1234234,234234,-30}
(1 row)
SELECT sort_asc('{1234234,-30,234234}');
sort_asc
----------------------
{-30,234234,1234234}
(1 row)
SELECT sort_desc('{1234234,-30,234234}');
sort_desc
----------------------
{1234234,234234,-30}
(1 row)
SELECT uniq('{1234234,-30,-30,234234,-30}');
uniq
--------------------------
{1234234,-30,234234,-30}
(1 row)
SELECT uniq(sort_asc('{1234234,-30,-30,234234,-30}'));
uniq
----------------------
{-30,234234,1234234}
(1 row)
SELECT idx('{1234234,-30,-30,234234,-30}',-30);
idx
-----
2
(1 row)
SELECT subarray('{1234234,-30,-30,234234,-30}',2,3);
subarray
------------------
{-30,-30,234234}
(1 row)
SELECT subarray('{1234234,-30,-30,234234,-30}',-1,1);
subarray
----------
{-30}
(1 row)
SELECT subarray('{1234234,-30,-30,234234,-30}',0,-1);
subarray
--------------------------
{1234234,-30,-30,234234}
(1 row)
SELECT #'{1234234,234234}'::int[];
?column?
----------
2
(1 row)
SELECT '{123,623,445}'::int[] + 1245;
?column?
--------------------
{123,623,445,1245}
(1 row)
SELECT '{123,623,445}'::int[] + 445;
?column?
-------------------
{123,623,445,445}
(1 row)
SELECT '{123,623,445}'::int[] + '{1245,87,445}';
?column?
---------------------------
{123,623,445,1245,87,445}
(1 row)
SELECT '{123,623,445}'::int[] - 623;
?column?
-----------
{123,445}
(1 row)
SELECT '{123,623,445}'::int[] - '{1623,623}';
?column?
-----------
{123,445}
(1 row)
SELECT '{123,623,445}'::int[] | 623;
?column?
---------------
{123,445,623}
(1 row)
SELECT '{123,623,445}'::int[] | 1623;
?column?
--------------------
{123,445,623,1623}
(1 row)
SELECT '{123,623,445}'::int[] | '{1623,623}';
?column?
--------------------
{123,445,623,1623}
(1 row)
SELECT '{123,623,445}'::int[] & '{1623,623}';
?column?
----------
{623}
(1 row)
SELECT '{-1,3,1}'::int[] & '{1,2}';
?column?
----------
{1}
(1 row)
SELECT '{1}'::int[] & '{2}'::int[];
?column?
----------
{}
(1 row)
SELECT array_dims('{1}'::int[] & '{2}'::int[]);
array_dims
------------
(1 row)
SELECT ('{1}'::int[] & '{2}'::int[]) = '{}'::int[];
?column?
----------
t
(1 row)
SELECT ('{}'::int[] & '{}'::int[]) = '{}'::int[];
?column?
----------
t
(1 row)
--test query_int
SELECT '1'::query_int;
query_int
-----------
1
(1 row)
SELECT ' 1'::query_int;
query_int
-----------
1
(1 row)
SELECT '1 '::query_int;
query_int
-----------
1
(1 row)
SELECT ' 1 '::query_int;
query_int
-----------
1
(1 row)
SELECT ' ! 1 '::query_int;
query_int
-----------
!1
(1 row)
SELECT '!1'::query_int;
query_int
-----------
!1
(1 row)
SELECT '1|2'::query_int;
query_int
-----------
1 | 2
(1 row)
SELECT '1|!2'::query_int;
query_int
-----------
1 | !2
(1 row)
SELECT '!1|2'::query_int;
query_int
-----------
!1 | 2
(1 row)
SELECT '!1|!2'::query_int;
query_int
-----------
!1 | !2
(1 row)
SELECT '!(!1|!2)'::query_int;
query_int
--------------
!( !1 | !2 )
(1 row)
SELECT '!(!1|2)'::query_int;
query_int
-------------
!( !1 | 2 )
(1 row)
SELECT '!(1|!2)'::query_int;
query_int
-------------
!( 1 | !2 )
(1 row)
SELECT '!(1|2)'::query_int;
query_int
------------
!( 1 | 2 )
(1 row)
SELECT '1&2'::query_int;
query_int
-----------
1 & 2
(1 row)
SELECT '!1&2'::query_int;
query_int
-----------
!1 & 2
(1 row)
SELECT '1&!2'::query_int;
query_int
-----------
1 & !2
(1 row)
SELECT '!1&!2'::query_int;
query_int
-----------
!1 & !2
(1 row)
SELECT '(1&2)'::query_int;
query_int
-----------
1 & 2
(1 row)
SELECT '1&(2)'::query_int;
query_int
-----------
1 & 2
(1 row)
SELECT '!(1)&2'::query_int;
query_int
-----------
!1 & 2
(1 row)
SELECT '!(1&2)'::query_int;
query_int
------------
!( 1 & 2 )
(1 row)
SELECT '1|2&3'::query_int;
query_int
-----------
1 | 2 & 3
(1 row)
SELECT '1|(2&3)'::query_int;
query_int
-----------
1 | 2 & 3
(1 row)
SELECT '(1|2)&3'::query_int;
query_int
---------------
( 1 | 2 ) & 3
(1 row)
SELECT '1|2&!3'::query_int;
query_int
------------
1 | 2 & !3
(1 row)
SELECT '1|!2&3'::query_int;
query_int
------------
1 | !2 & 3
(1 row)
SELECT '!1|2&3'::query_int;
query_int
------------
!1 | 2 & 3
(1 row)
SELECT '!1|(2&3)'::query_int;
query_int
------------
!1 | 2 & 3
(1 row)
SELECT '!(1|2)&3'::query_int;
query_int
----------------
!( 1 | 2 ) & 3
(1 row)
SELECT '(!1|2)&3'::query_int;
query_int
----------------
( !1 | 2 ) & 3
(1 row)
SELECT '1|(2|(4|(5|6)))'::query_int;
query_int
-------------------------------
1 | ( 2 | ( 4 | ( 5 | 6 ) ) )
(1 row)
SELECT '1|2|4|5|6'::query_int;
query_int
-------------------------------
( ( ( 1 | 2 ) | 4 ) | 5 ) | 6
(1 row)
SELECT '1&(2&(4&(5&6)))'::query_int;
query_int
-------------------
1 & 2 & 4 & 5 & 6
(1 row)
SELECT '1&2&4&5&6'::query_int;
query_int
-------------------
1 & 2 & 4 & 5 & 6
(1 row)
SELECT '1&(2&(4&(5|6)))'::query_int;
query_int
-----------------------
1 & 2 & 4 & ( 5 | 6 )
(1 row)
SELECT '1&(2&(4&(5|!6)))'::query_int;
query_int
------------------------
1 & 2 & 4 & ( 5 | !6 )
(1 row)
CREATE TABLE test__int( a int[] );
\copy test__int from 'data/test__int.data'
ANALYZE test__int;
SELECT count(*) from test__int WHERE a && '{23,50}';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @@ '23|50';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @> '{23,50}';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @@ '23&50';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}';
count
-------
12
(1 row)
Fix intarray's GiST opclasses to not fail for empty arrays with <@. 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
2019-08-07 00:04:51 +02:00
SELECT count(*) from test__int WHERE a <@ '{73,23,20}';
count
-------
10
(1 row)
SELECT count(*) from test__int WHERE a = '{73,23,20}';
count
-------
1
(1 row)
SELECT count(*) from test__int WHERE a @@ '50&68';
count
-------
9
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}' or a @> '{50,68}';
count
-------
21
(1 row)
SELECT count(*) from test__int WHERE a @@ '(20&23)|(50&68)';
count
-------
21
(1 row)
Fix intarray's GiST opclasses to not fail for empty arrays with <@. 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
2019-08-07 00:04:51 +02:00
SELECT count(*) from test__int WHERE a @@ '20 | !21';
count
-------
6566
(1 row)
SELECT count(*) from test__int WHERE a @@ '!20 & !21';
count
-------
6343
(1 row)
SET enable_seqscan = off; -- not all of these would use index by default
CREATE INDEX text_idx on test__int using gist ( a gist__int_ops );
SELECT count(*) from test__int WHERE a && '{23,50}';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @@ '23|50';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @> '{23,50}';
count
-------
12
(1 row)
Implement operator class parameters PostgreSQL provides set of template index access methods, where opclasses have much freedom in the semantics of indexing. These index AMs are GiST, GIN, SP-GiST and BRIN. There opclasses define representation of keys, operations on them and supported search strategies. So, it's natural that opclasses may be faced some tradeoffs, which require user-side decision. This commit implements opclass parameters allowing users to set some values, which tell opclass how to index the particular dataset. This commit doesn't introduce new storage in system catalog. Instead it uses pg_attribute.attoptions, which is used for table column storage options but unused for index attributes. In order to evade changing signature of each opclass support function, we implement unified way to pass options to opclass support functions. Options are set to fn_expr as the constant bytea expression. It's possible due to the fact that opclass support functions are executed outside of expressions, so fn_expr is unused for them. This commit comes with some examples of opclass options usage. We parametrize signature length in GiST. That applies to multiple opclasses: tsvector_ops, gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and gist_hstore_ops. Also we parametrize maximum number of integer ranges for gist__int_ops. However, the main future usage of this feature is expected to be json, where users would be able to specify which way to index particular json parts. Catversion is bumped. Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru Author: Nikita Glukhov, revised by me Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera
2020-03-30 18:17:11 +02:00
SELECT count(*) from test__int WHERE a @@ '23&50';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a <@ '{73,23,20}';
count
-------
10
(1 row)
SELECT count(*) from test__int WHERE a = '{73,23,20}';
count
-------
1
(1 row)
SELECT count(*) from test__int WHERE a @@ '50&68';
count
-------
9
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}' or a @> '{50,68}';
count
-------
21
(1 row)
SELECT count(*) from test__int WHERE a @@ '(20&23)|(50&68)';
count
-------
21
(1 row)
SELECT count(*) from test__int WHERE a @@ '20 | !21';
count
-------
6566
(1 row)
SELECT count(*) from test__int WHERE a @@ '!20 & !21';
count
-------
6343
(1 row)
DROP INDEX text_idx;
CREATE INDEX text_idx on test__int using gist (a gist__int_ops(numranges = 0));
ERROR: value 0 out of bounds for option "numranges"
DETAIL: Valid values are between "1" and "252".
CREATE INDEX text_idx on test__int using gist (a gist__int_ops(numranges = 253));
ERROR: value 253 out of bounds for option "numranges"
DETAIL: Valid values are between "1" and "252".
CREATE INDEX text_idx on test__int using gist (a gist__int_ops(numranges = 252));
SELECT count(*) from test__int WHERE a && '{23,50}';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @@ '23|50';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @> '{23,50}';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @@ '23&50';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a <@ '{73,23,20}';
count
-------
10
(1 row)
SELECT count(*) from test__int WHERE a = '{73,23,20}';
count
-------
1
(1 row)
SELECT count(*) from test__int WHERE a @@ '50&68';
count
-------
9
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}' or a @> '{50,68}';
count
-------
21
(1 row)
SELECT count(*) from test__int WHERE a @@ '(20&23)|(50&68)';
count
-------
21
(1 row)
SELECT count(*) from test__int WHERE a @@ '20 | !21';
count
-------
6566
(1 row)
SELECT count(*) from test__int WHERE a @@ '!20 & !21';
count
-------
6343
(1 row)
DROP INDEX text_idx;
CREATE INDEX text_idx on test__int using gist (a gist__intbig_ops(siglen = 0));
ERROR: value 0 out of bounds for option "siglen"
DETAIL: Valid values are between "1" and "2024".
CREATE INDEX text_idx on test__int using gist (a gist__intbig_ops(siglen = 2025));
ERROR: value 2025 out of bounds for option "siglen"
DETAIL: Valid values are between "1" and "2024".
CREATE INDEX text_idx on test__int using gist (a gist__intbig_ops(siglen = 2024));
SELECT count(*) from test__int WHERE a && '{23,50}';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @@ '23|50';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @> '{23,50}';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @@ '23&50';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}';
count
-------
12
(1 row)
Fix intarray's GiST opclasses to not fail for empty arrays with <@. 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
2019-08-07 00:04:51 +02:00
SELECT count(*) from test__int WHERE a <@ '{73,23,20}';
count
-------
10
(1 row)
SELECT count(*) from test__int WHERE a = '{73,23,20}';
count
-------
1
(1 row)
SELECT count(*) from test__int WHERE a @@ '50&68';
count
-------
9
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}' or a @> '{50,68}';
count
-------
21
(1 row)
SELECT count(*) from test__int WHERE a @@ '(20&23)|(50&68)';
count
-------
21
(1 row)
Fix intarray's GiST opclasses to not fail for empty arrays with <@. 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
2019-08-07 00:04:51 +02:00
SELECT count(*) from test__int WHERE a @@ '20 | !21';
count
-------
6566
(1 row)
SELECT count(*) from test__int WHERE a @@ '!20 & !21';
count
-------
6343
(1 row)
DROP INDEX text_idx;
CREATE INDEX text_idx on test__int using gist ( a gist__intbig_ops );
SELECT count(*) from test__int WHERE a && '{23,50}';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @@ '23|50';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @> '{23,50}';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @@ '23&50';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}';
count
-------
12
(1 row)
Fix intarray's GiST opclasses to not fail for empty arrays with <@. 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
2019-08-07 00:04:51 +02:00
SELECT count(*) from test__int WHERE a <@ '{73,23,20}';
count
-------
10
(1 row)
SELECT count(*) from test__int WHERE a = '{73,23,20}';
count
-------
1
(1 row)
SELECT count(*) from test__int WHERE a @@ '50&68';
count
-------
9
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}' or a @> '{50,68}';
count
-------
21
(1 row)
SELECT count(*) from test__int WHERE a @@ '(20&23)|(50&68)';
count
-------
21
(1 row)
Fix intarray's GiST opclasses to not fail for empty arrays with <@. 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
2019-08-07 00:04:51 +02:00
SELECT count(*) from test__int WHERE a @@ '20 | !21';
count
-------
6566
(1 row)
SELECT count(*) from test__int WHERE a @@ '!20 & !21';
count
-------
6343
(1 row)
DROP INDEX text_idx;
CREATE INDEX text_idx on test__int using gin ( a gin__int_ops );
SELECT count(*) from test__int WHERE a && '{23,50}';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @@ '23|50';
count
-------
403
(1 row)
SELECT count(*) from test__int WHERE a @> '{23,50}';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @@ '23&50';
count
-------
12
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}';
count
-------
12
(1 row)
Fix intarray's GiST opclasses to not fail for empty arrays with <@. 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
2019-08-07 00:04:51 +02:00
SELECT count(*) from test__int WHERE a <@ '{73,23,20}';
count
-------
10
(1 row)
SELECT count(*) from test__int WHERE a = '{73,23,20}';
count
-------
1
(1 row)
SELECT count(*) from test__int WHERE a @@ '50&68';
count
-------
9
(1 row)
SELECT count(*) from test__int WHERE a @> '{20,23}' or a @> '{50,68}';
count
-------
21
(1 row)
SELECT count(*) from test__int WHERE a @@ '(20&23)|(50&68)';
count
-------
21
(1 row)
Fix intarray's GiST opclasses to not fail for empty arrays with <@. 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
2019-08-07 00:04:51 +02:00
SELECT count(*) from test__int WHERE a @@ '20 | !21';
count
-------
6566
(1 row)
SELECT count(*) from test__int WHERE a @@ '!20 & !21';
count
-------
6343
(1 row)
RESET enable_seqscan;