2011-02-14 02:06:41 +01:00
|
|
|
CREATE EXTENSION intarray;
|
2001-01-12 01:16:26 +01:00
|
|
|
|
2016-11-29 21:05:22 +01:00
|
|
|
-- 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);
|
|
|
|
|
|
2002-10-18 20:41:22 +02:00
|
|
|
SELECT intset(1234);
|
|
|
|
|
SELECT icount('{1234234,234234}');
|
|
|
|
|
SELECT sort('{1234234,-30,234234}');
|
|
|
|
|
SELECT sort('{1234234,-30,234234}','asc');
|
|
|
|
|
SELECT sort('{1234234,-30,234234}','desc');
|
|
|
|
|
SELECT sort_asc('{1234234,-30,234234}');
|
|
|
|
|
SELECT sort_desc('{1234234,-30,234234}');
|
|
|
|
|
SELECT uniq('{1234234,-30,-30,234234,-30}');
|
|
|
|
|
SELECT uniq(sort_asc('{1234234,-30,-30,234234,-30}'));
|
|
|
|
|
SELECT idx('{1234234,-30,-30,234234,-30}',-30);
|
|
|
|
|
SELECT subarray('{1234234,-30,-30,234234,-30}',2,3);
|
|
|
|
|
SELECT subarray('{1234234,-30,-30,234234,-30}',-1,1);
|
|
|
|
|
SELECT subarray('{1234234,-30,-30,234234,-30}',0,-1);
|
August 6, 2002
1. Reworked patch from Andrey Oktyabrski (ano@spider.ru) with
functions: icount, sort, sort_asc, uniq, idx, subarray
operations: #, +, -, |, &
FUNCTIONS:
int icount(int[]) - the number of elements in intarray
int[] sort(int[], 'asc' | 'desc') - sort intarray
int[] sort(int[]) - sort in ascending order
int[] sort_asc(int[]),sort_desc(int[]) - shortcuts for sort
int[] uniq(int[]) - returns unique elements
int idx(int[], int item) - returns index of first intarray matching element
to item, or '0' if matching failed.
int[] subarray(int[],int START [, int LEN]) - returns part of intarray
starting from element number START (from 1)
and length LEN.
OPERATIONS:
int[] && int[] - overlap - returns TRUE if arrays has at least one common elements.
int[] @ int[] - contains - returns TRUE if left array contains right array
int[] ~ int[] - contained - returns TRUE if left array is contained in right array
# int[] - return the number of elements in array
int[] + int - push element to array ( add to end of array)
int[] + int[] - merge of arrays (right array added to the end of left one)
int[] - int - remove entries matched by right argument from array
int[] - int[] - remove left array from right
int[] | int - returns intarray - union of arguments
int[] | int[] - returns intarray as a union of two arrays
int[] & int[] - returns intersection of arrays
Oleg Bartunov
2002-08-10 22:38:29 +02:00
|
|
|
|
2002-10-18 20:41:22 +02:00
|
|
|
SELECT #'{1234234,234234}'::int[];
|
|
|
|
|
SELECT '{123,623,445}'::int[] + 1245;
|
|
|
|
|
SELECT '{123,623,445}'::int[] + 445;
|
|
|
|
|
SELECT '{123,623,445}'::int[] + '{1245,87,445}';
|
|
|
|
|
SELECT '{123,623,445}'::int[] - 623;
|
|
|
|
|
SELECT '{123,623,445}'::int[] - '{1623,623}';
|
|
|
|
|
SELECT '{123,623,445}'::int[] | 623;
|
|
|
|
|
SELECT '{123,623,445}'::int[] | 1623;
|
|
|
|
|
SELECT '{123,623,445}'::int[] | '{1623,623}';
|
|
|
|
|
SELECT '{123,623,445}'::int[] & '{1623,623}';
|
2012-02-17 02:00:11 +01:00
|
|
|
SELECT '{-1,3,1}'::int[] & '{1,2}';
|
2018-07-09 20:28:04 +02:00
|
|
|
SELECT '{1}'::int[] & '{2}'::int[];
|
|
|
|
|
SELECT array_dims('{1}'::int[] & '{2}'::int[]);
|
|
|
|
|
SELECT ('{1}'::int[] & '{2}'::int[]) = '{}'::int[];
|
|
|
|
|
SELECT ('{}'::int[] & '{}'::int[]) = '{}'::int[];
|
August 6, 2002
1. Reworked patch from Andrey Oktyabrski (ano@spider.ru) with
functions: icount, sort, sort_asc, uniq, idx, subarray
operations: #, +, -, |, &
FUNCTIONS:
int icount(int[]) - the number of elements in intarray
int[] sort(int[], 'asc' | 'desc') - sort intarray
int[] sort(int[]) - sort in ascending order
int[] sort_asc(int[]),sort_desc(int[]) - shortcuts for sort
int[] uniq(int[]) - returns unique elements
int idx(int[], int item) - returns index of first intarray matching element
to item, or '0' if matching failed.
int[] subarray(int[],int START [, int LEN]) - returns part of intarray
starting from element number START (from 1)
and length LEN.
OPERATIONS:
int[] && int[] - overlap - returns TRUE if arrays has at least one common elements.
int[] @ int[] - contains - returns TRUE if left array contains right array
int[] ~ int[] - contained - returns TRUE if left array is contained in right array
# int[] - return the number of elements in array
int[] + int - push element to array ( add to end of array)
int[] + int[] - merge of arrays (right array added to the end of left one)
int[] - int - remove entries matched by right argument from array
int[] - int[] - remove left array from right
int[] | int - returns intarray - union of arguments
int[] | int[] - returns intarray as a union of two arrays
int[] & int[] - returns intersection of arrays
Oleg Bartunov
2002-08-10 22:38:29 +02:00
|
|
|
|
|
|
|
|
|
2001-09-23 06:16:16 +02:00
|
|
|
--test query_int
|
2002-10-18 20:41:22 +02:00
|
|
|
SELECT '1'::query_int;
|
|
|
|
|
SELECT ' 1'::query_int;
|
|
|
|
|
SELECT '1 '::query_int;
|
|
|
|
|
SELECT ' 1 '::query_int;
|
|
|
|
|
SELECT ' ! 1 '::query_int;
|
|
|
|
|
SELECT '!1'::query_int;
|
|
|
|
|
SELECT '1|2'::query_int;
|
|
|
|
|
SELECT '1|!2'::query_int;
|
|
|
|
|
SELECT '!1|2'::query_int;
|
|
|
|
|
SELECT '!1|!2'::query_int;
|
|
|
|
|
SELECT '!(!1|!2)'::query_int;
|
|
|
|
|
SELECT '!(!1|2)'::query_int;
|
|
|
|
|
SELECT '!(1|!2)'::query_int;
|
|
|
|
|
SELECT '!(1|2)'::query_int;
|
|
|
|
|
SELECT '1&2'::query_int;
|
|
|
|
|
SELECT '!1&2'::query_int;
|
|
|
|
|
SELECT '1&!2'::query_int;
|
|
|
|
|
SELECT '!1&!2'::query_int;
|
|
|
|
|
SELECT '(1&2)'::query_int;
|
|
|
|
|
SELECT '1&(2)'::query_int;
|
|
|
|
|
SELECT '!(1)&2'::query_int;
|
|
|
|
|
SELECT '!(1&2)'::query_int;
|
|
|
|
|
SELECT '1|2&3'::query_int;
|
|
|
|
|
SELECT '1|(2&3)'::query_int;
|
|
|
|
|
SELECT '(1|2)&3'::query_int;
|
|
|
|
|
SELECT '1|2&!3'::query_int;
|
|
|
|
|
SELECT '1|!2&3'::query_int;
|
|
|
|
|
SELECT '!1|2&3'::query_int;
|
|
|
|
|
SELECT '!1|(2&3)'::query_int;
|
|
|
|
|
SELECT '!(1|2)&3'::query_int;
|
|
|
|
|
SELECT '(!1|2)&3'::query_int;
|
|
|
|
|
SELECT '1|(2|(4|(5|6)))'::query_int;
|
|
|
|
|
SELECT '1|2|4|5|6'::query_int;
|
|
|
|
|
SELECT '1&(2&(4&(5&6)))'::query_int;
|
|
|
|
|
SELECT '1&2&4&5&6'::query_int;
|
|
|
|
|
SELECT '1&(2&(4&(5|6)))'::query_int;
|
|
|
|
|
SELECT '1&(2&(4&(5|!6)))'::query_int;
|
2001-09-23 06:16:16 +02:00
|
|
|
|
|
|
|
|
|
2001-01-12 01:16:26 +01:00
|
|
|
CREATE TABLE test__int( a int[] );
|
|
|
|
|
\copy test__int from 'data/test__int.data'
|
2015-07-21 19:54:18 +02:00
|
|
|
ANALYZE test__int;
|
2001-01-12 01:16:26 +01:00
|
|
|
|
|
|
|
|
SELECT count(*) from test__int WHERE a && '{23,50}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '23|50';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{23,50}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '23&50';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{20,23}';
|
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}';
|
|
|
|
|
SELECT count(*) from test__int WHERE a = '{73,23,20}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '50&68';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{20,23}' or a @> '{50,68}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '(20&23)|(50&68)';
|
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';
|
|
|
|
|
SELECT count(*) from test__int WHERE a @@ '!20 & !21';
|
|
|
|
|
|
|
|
|
|
SET enable_seqscan = off; -- not all of these would use index by default
|
2001-01-12 01:16:26 +01:00
|
|
|
|
2001-08-21 18:36:06 +02:00
|
|
|
CREATE INDEX text_idx on test__int using gist ( a gist__int_ops );
|
2001-03-17 22:59:42 +01:00
|
|
|
|
|
|
|
|
SELECT count(*) from test__int WHERE a && '{23,50}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '23|50';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{23,50}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '23&50';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{20,23}';
|
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}';
|
|
|
|
|
SELECT count(*) from test__int WHERE a = '{73,23,20}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '50&68';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{20,23}' or a @> '{50,68}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '(20&23)|(50&68)';
|
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';
|
|
|
|
|
SELECT count(*) from test__int WHERE a @@ '!20 & !21';
|
2001-03-17 22:59:42 +01:00
|
|
|
|
2002-10-18 20:41:22 +02:00
|
|
|
DROP INDEX text_idx;
|
2001-08-21 18:36:06 +02:00
|
|
|
CREATE INDEX text_idx on test__int using gist ( a gist__intbig_ops );
|
2001-03-17 22:59:42 +01:00
|
|
|
|
|
|
|
|
SELECT count(*) from test__int WHERE a && '{23,50}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '23|50';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{23,50}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '23&50';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{20,23}';
|
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}';
|
|
|
|
|
SELECT count(*) from test__int WHERE a = '{73,23,20}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '50&68';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{20,23}' or a @> '{50,68}';
|
2001-09-23 06:16:16 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '(20&23)|(50&68)';
|
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';
|
|
|
|
|
SELECT count(*) from test__int WHERE a @@ '!20 & !21';
|
2006-05-03 18:31:07 +02:00
|
|
|
|
|
|
|
|
DROP INDEX text_idx;
|
2007-09-14 05:25:31 +02:00
|
|
|
CREATE INDEX text_idx on test__int using gin ( a gin__int_ops );
|
2006-05-03 18:31:07 +02:00
|
|
|
|
|
|
|
|
SELECT count(*) from test__int WHERE a && '{23,50}';
|
|
|
|
|
SELECT count(*) from test__int WHERE a @@ '23|50';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{23,50}';
|
2006-05-03 18:31:07 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '23&50';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{20,23}';
|
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}';
|
|
|
|
|
SELECT count(*) from test__int WHERE a = '{73,23,20}';
|
2006-05-03 18:31:07 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '50&68';
|
2006-09-10 19:36:52 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @> '{20,23}' or a @> '{50,68}';
|
2006-05-03 18:31:07 +02:00
|
|
|
SELECT count(*) from test__int WHERE a @@ '(20&23)|(50&68)';
|
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';
|
|
|
|
|
SELECT count(*) from test__int WHERE a @@ '!20 & !21';
|
|
|
|
|
|
|
|
|
|
RESET enable_seqscan;
|
