2007-08-21 03:11:32 +02:00
|
|
|
--Base tsvector test
|
|
|
|
SELECT '1'::tsvector;
|
|
|
|
tsvector
|
|
|
|
----------
|
|
|
|
'1'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1 '::tsvector;
|
|
|
|
tsvector
|
|
|
|
----------
|
|
|
|
'1'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ' 1'::tsvector;
|
|
|
|
tsvector
|
|
|
|
----------
|
|
|
|
'1'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ' 1 '::tsvector;
|
|
|
|
tsvector
|
|
|
|
----------
|
|
|
|
'1'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1 2'::tsvector;
|
|
|
|
tsvector
|
|
|
|
----------
|
|
|
|
'1' '2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '''1 2'''::tsvector;
|
|
|
|
tsvector
|
|
|
|
----------
|
|
|
|
'1 2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT E'''1 \\''2'''::tsvector;
|
|
|
|
tsvector
|
|
|
|
----------
|
|
|
|
'1 ''2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT E'''1 \\''2''3'::tsvector;
|
|
|
|
tsvector
|
|
|
|
-------------
|
2008-05-16 18:31:02 +02:00
|
|
|
'1 ''2' '3'
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT E'''1 \\''2'' 3'::tsvector;
|
|
|
|
tsvector
|
|
|
|
-------------
|
2008-05-16 18:31:02 +02:00
|
|
|
'1 ''2' '3'
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT E'''1 \\''2'' '' 3'' 4 '::tsvector;
|
|
|
|
tsvector
|
|
|
|
------------------
|
2008-05-16 18:31:02 +02:00
|
|
|
' 3' '1 ''2' '4'
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
2007-11-16 16:05:59 +01:00
|
|
|
SELECT $$'\\as' ab\c ab\\c AB\\\c ab\\\\c$$::tsvector;
|
|
|
|
tsvector
|
|
|
|
----------------------------------------
|
2008-05-16 18:31:02 +02:00
|
|
|
'AB\\c' '\\as' 'ab\\\\c' 'ab\\c' 'abc'
|
2007-11-16 16:05:59 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT tsvectorin(tsvectorout($$'\\as' ab\c ab\\c AB\\\c ab\\\\c$$::tsvector));
|
|
|
|
tsvectorin
|
|
|
|
----------------------------------------
|
2008-05-16 18:31:02 +02:00
|
|
|
'AB\\c' '\\as' 'ab\\\\c' 'ab\\c' 'abc'
|
2007-11-16 16:05:59 +01:00
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT '''w'':4A,3B,2C,1D,5 a:8';
|
2007-08-21 03:11:32 +02:00
|
|
|
?column?
|
|
|
|
-----------------------
|
|
|
|
'w':4A,3B,2C,1D,5 a:8
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'a:3A b:2a'::tsvector || 'ba:1234 a:1B';
|
2007-08-21 03:11:32 +02:00
|
|
|
?column?
|
|
|
|
----------------------------
|
|
|
|
'a':3A,4B 'b':2A 'ba':1237
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--Base tsquery test
|
|
|
|
SELECT '1'::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
'1'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1 '::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
'1'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ' 1'::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
'1'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ' 1 '::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
'1'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '''1 2'''::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
'1 2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT E'''1 \\''2'''::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
'1 ''2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!1'::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
!'1'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1|2'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-----------
|
|
|
|
'1' | '2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1|!2'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------
|
|
|
|
'1' | !'2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!1|2'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------
|
|
|
|
!'1' | '2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!1|!2'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-------------
|
|
|
|
!'1' | !'2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!(!1|!2)'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------------
|
|
|
|
!( !'1' | !'2' )
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!(!1|2)'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-----------------
|
|
|
|
!( !'1' | '2' )
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!(1|!2)'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-----------------
|
|
|
|
!( '1' | !'2' )
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!(1|2)'::tsquery;
|
|
|
|
tsquery
|
|
|
|
----------------
|
|
|
|
!( '1' | '2' )
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1&2'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-----------
|
|
|
|
'1' & '2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!1&2'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------
|
|
|
|
!'1' & '2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1&!2'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------
|
|
|
|
'1' & !'2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!1&!2'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-------------
|
|
|
|
!'1' & !'2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(1&2)'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-----------
|
|
|
|
'1' & '2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1&(2)'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-----------
|
|
|
|
'1' & '2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!(1)&2'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------
|
|
|
|
!'1' & '2'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!(1&2)'::tsquery;
|
|
|
|
tsquery
|
|
|
|
----------------
|
|
|
|
!( '1' & '2' )
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1|2&3'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-----------------
|
|
|
|
'1' | '2' & '3'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1|(2&3)'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-----------------
|
|
|
|
'1' | '2' & '3'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(1|2)&3'::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------------------
|
|
|
|
( '1' | '2' ) & '3'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1|2&!3'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------------
|
|
|
|
'1' | '2' & !'3'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1|!2&3'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------------
|
|
|
|
'1' | !'2' & '3'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!1|2&3'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------------
|
|
|
|
!'1' | '2' & '3'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!1|(2&3)'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------------
|
|
|
|
!'1' | '2' & '3'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!(1|2)&3'::tsquery;
|
|
|
|
tsquery
|
|
|
|
----------------------
|
|
|
|
!( '1' | '2' ) & '3'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '(!1|2)&3'::tsquery;
|
|
|
|
tsquery
|
|
|
|
----------------------
|
|
|
|
( !'1' | '2' ) & '3'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1|(2|(4|(5|6)))'::tsquery;
|
2016-04-07 17:44:18 +02:00
|
|
|
tsquery
|
|
|
|
-----------------------------
|
|
|
|
'1' | '2' | '4' | '5' | '6'
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1|2|4|5|6'::tsquery;
|
2016-04-07 17:44:18 +02:00
|
|
|
tsquery
|
|
|
|
-----------------------------
|
|
|
|
'1' | '2' | '4' | '5' | '6'
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1&(2&(4&(5&6)))'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-----------------------------
|
|
|
|
'1' & '2' & '4' & '5' & '6'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1&2&4&5&6'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-----------------------------
|
|
|
|
'1' & '2' & '4' & '5' & '6'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1&(2&(4&(5|6)))'::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------------------------------
|
|
|
|
'1' & '2' & '4' & ( '5' | '6' )
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '1&(2&(4&(5|!6)))'::tsquery;
|
|
|
|
tsquery
|
|
|
|
----------------------------------
|
|
|
|
'1' & '2' & '4' & ( '5' | !'6' )
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT E'1&(''2''&('' 4''&(\\|5 | ''6 \\'' !|&'')))'::tsquery;
|
|
|
|
tsquery
|
|
|
|
------------------------------------------
|
|
|
|
'1' & '2' & ' 4' & ( '|5' | '6 '' !|&' )
|
|
|
|
(1 row)
|
|
|
|
|
2007-11-16 16:05:59 +01:00
|
|
|
SELECT $$'\\as'$$::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
'\\as'
|
|
|
|
(1 row)
|
|
|
|
|
2008-05-16 18:31:02 +02:00
|
|
|
SELECT 'a:* & nbb:*ac | doo:a* | goo'::tsquery;
|
2016-04-07 17:44:18 +02:00
|
|
|
tsquery
|
|
|
|
--------------------------------------
|
|
|
|
'a':* & 'nbb':*AC | 'doo':*A | 'goo'
|
|
|
|
(1 row)
|
|
|
|
|
2016-07-15 19:01:41 +02:00
|
|
|
SELECT '!!b'::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
!!'b'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!!!b'::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
!!!'b'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!(!b)'::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------
|
|
|
|
!!'b'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a & !!b'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-------------
|
|
|
|
'a' & !!'b'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!!a & b'::tsquery;
|
|
|
|
tsquery
|
|
|
|
-------------
|
|
|
|
!!'a' & 'b'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT '!!a & !!b'::tsquery;
|
|
|
|
tsquery
|
|
|
|
---------------
|
|
|
|
!!'a' & !!'b'
|
|
|
|
(1 row)
|
|
|
|
|
2016-04-07 17:44:18 +02:00
|
|
|
--comparisons
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'a' < 'b & c'::tsquery as "true";
|
2007-08-21 03:11:32 +02:00
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'a' > 'b & c'::tsquery as "false";
|
2007-08-21 03:11:32 +02:00
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2016-04-07 17:44:18 +02:00
|
|
|
SELECT 'a | f' < 'b & c'::tsquery as "false";
|
|
|
|
false
|
|
|
|
-------
|
2016-04-08 19:11:30 +02:00
|
|
|
t
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'a | ff' < 'b & c'::tsquery as "false";
|
2007-08-21 03:11:32 +02:00
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'a | f | g' < 'b & c'::tsquery as "false";
|
2007-08-21 03:11:32 +02:00
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2016-04-07 17:44:18 +02:00
|
|
|
--concatenation
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT numnode( 'new'::tsquery );
|
2007-08-21 03:11:32 +02:00
|
|
|
numnode
|
|
|
|
---------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT numnode( 'new & york'::tsquery );
|
2007-08-21 03:11:32 +02:00
|
|
|
numnode
|
|
|
|
---------
|
|
|
|
3
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT numnode( 'new & york | qwery'::tsquery );
|
2007-08-21 03:11:32 +02:00
|
|
|
numnode
|
|
|
|
---------
|
|
|
|
5
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'foo & bar'::tsquery && 'asd';
|
2007-08-21 03:11:32 +02:00
|
|
|
?column?
|
|
|
|
-----------------------
|
|
|
|
'foo' & 'bar' & 'asd'
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'foo & bar'::tsquery || 'asd & fg';
|
2007-08-21 03:11:32 +02:00
|
|
|
?column?
|
|
|
|
------------------------------
|
|
|
|
'foo' & 'bar' | 'asd' & 'fg'
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'foo & bar'::tsquery || !!'asd & fg'::tsquery;
|
2007-08-21 03:11:32 +02:00
|
|
|
?column?
|
|
|
|
-----------------------------------
|
|
|
|
'foo' & 'bar' | !( 'asd' & 'fg' )
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'foo & bar'::tsquery && 'asd | fg';
|
2007-08-21 03:11:32 +02:00
|
|
|
?column?
|
|
|
|
----------------------------------
|
|
|
|
'foo' & 'bar' & ( 'asd' | 'fg' )
|
|
|
|
(1 row)
|
|
|
|
|
2016-04-07 17:44:18 +02:00
|
|
|
SELECT 'a' <-> 'b & d'::tsquery;
|
Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
2016-12-21 21:18:25 +01:00
|
|
|
?column?
|
|
|
|
-----------------------
|
|
|
|
'a' <-> ( 'b' & 'd' )
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a & g' <-> 'b & d'::tsquery;
|
Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
2016-12-21 21:18:25 +01:00
|
|
|
?column?
|
|
|
|
---------------------------------
|
|
|
|
( 'a' & 'g' ) <-> ( 'b' & 'd' )
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a & g' <-> 'b | d'::tsquery;
|
Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
2016-12-21 21:18:25 +01:00
|
|
|
?column?
|
|
|
|
---------------------------------
|
|
|
|
( 'a' & 'g' ) <-> ( 'b' | 'd' )
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a & g' <-> 'b <-> d'::tsquery;
|
Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
2016-12-21 21:18:25 +01:00
|
|
|
?column?
|
|
|
|
-----------------------------------
|
|
|
|
( 'a' & 'g' ) <-> ( 'b' <-> 'd' )
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT tsquery_phrase('a <3> g', 'b & d', 10);
|
Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
2016-12-21 21:18:25 +01:00
|
|
|
tsquery_phrase
|
|
|
|
--------------------------------
|
|
|
|
'a' <3> 'g' <10> ( 'b' & 'd' )
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
-- tsvector-tsquery operations
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'a b:89 ca:23A,64b d:34c'::tsvector @@ 'd:AC & ca' as "true";
|
2007-08-21 03:11:32 +02:00
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'a b:89 ca:23A,64b d:34c'::tsvector @@ 'd:AC & ca:B' as "true";
|
2007-08-21 03:11:32 +02:00
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'a b:89 ca:23A,64b d:34c'::tsvector @@ 'd:AC & ca:A' as "true";
|
2007-08-21 03:11:32 +02:00
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'a b:89 ca:23A,64b d:34c'::tsvector @@ 'd:AC & ca:C' as "false";
|
2007-08-21 03:11:32 +02:00
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT 'a b:89 ca:23A,64b d:34c'::tsvector @@ 'd:AC & ca:CB' as "true";
|
2007-08-21 03:11:32 +02:00
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2008-05-16 18:31:02 +02:00
|
|
|
SELECT 'a b:89 ca:23A,64b d:34c'::tsvector @@ 'd:AC & c:*C' as "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a b:89 ca:23A,64b d:34c'::tsvector @@ 'd:AC & c:*CB' as "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a b:89 ca:23A,64b cb:80c d:34c'::tsvector @@ 'd:AC & c:*C' as "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a b:89 ca:23A,64c cb:80b d:34c'::tsvector @@ 'd:AC & c:*C' as "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a b:89 ca:23A,64c cb:80b d:34c'::tsvector @@ 'd:AC & c:*B' as "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'supernova'::tsvector @@ 'super'::tsquery AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'supeanova supernova'::tsvector @@ 'super'::tsquery AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'supeznova supernova'::tsvector @@ 'super'::tsquery AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'supernova'::tsvector @@ 'super:*'::tsquery AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'supeanova supernova'::tsvector @@ 'super:*'::tsquery AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'supeznova supernova'::tsvector @@ 'super:*'::tsquery AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2016-04-07 17:44:18 +02:00
|
|
|
--phrase search
|
|
|
|
SELECT to_tsvector('simple', '1 2 3 1') @@ '1 <-> 2' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2016-06-27 19:41:00 +02:00
|
|
|
SELECT to_tsvector('simple', '1 2 3 1') @@ '1 <2> 2' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT to_tsvector('simple', '1 2 3 1') @@ '1 <-> 3' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT to_tsvector('simple', '1 2 3 1') @@ '1 <2> 3' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2016-06-27 19:41:00 +02:00
|
|
|
SELECT to_tsvector('simple', '1 2 1 2') @@ '1 <3> 2' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2016-04-07 17:44:18 +02:00
|
|
|
SELECT to_tsvector('simple', '1 2 11 3') @@ '1 <-> 3' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT to_tsvector('simple', '1 2 11 3') @@ '1:* <-> 3' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT to_tsvector('simple', '1 2 3 4') @@ '1 <-> 2 <-> 3' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT to_tsvector('simple', '1 2 3 4') @@ '(1 <-> 2) <-> 3' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
2016-12-21 21:18:25 +01:00
|
|
|
SELECT to_tsvector('simple', '1 2 3 4') @@ '1 <-> (2 <-> 3)' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT to_tsvector('simple', '1 2 3 4') @@ '1 <2> (2 <-> 3)' AS "false";
|
2016-04-07 17:44:18 +02:00
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
2016-12-21 21:18:25 +01:00
|
|
|
SELECT to_tsvector('simple', '1 2 1 2 3 4') @@ '(1 <-> 2) <-> 3' AS "true";
|
2016-04-07 17:44:18 +02:00
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
2016-12-21 21:18:25 +01:00
|
|
|
SELECT to_tsvector('simple', '1 2 1 2 3 4') @@ '1 <-> 2 <-> 3' AS "true";
|
2016-04-07 17:44:18 +02:00
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
2016-12-21 21:18:25 +01:00
|
|
|
-- without position data, phrase search does not match
|
|
|
|
SELECT strip(to_tsvector('simple', '1 2 3 4')) @@ '1 <-> 2 <-> 3' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'q x q y') @@ 'q <-> (x & y)' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'q x') @@ 'q <-> (x | y <-> z)' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'q y') @@ 'q <-> (x | y <-> z)' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'q y z') @@ 'q <-> (x | y <-> z)' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'q y x') @@ 'q <-> (x | y <-> z)' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'q x y') @@ 'q <-> (x | y <-> z)' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'q x') @@ '(x | y <-> z) <-> q' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'x q') @@ '(x | y <-> z) <-> q' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'x y q') @@ '(x | y <-> z) <-> q' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'x y z') @@ '(x | y <-> z) <-> q' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'x y z q') @@ '(x | y <-> z) <-> q' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'y z q') @@ '(x | y <-> z) <-> q' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'y y q') @@ '(x | y <-> z) <-> q' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'y y q') @@ '(!x | y <-> z) <-> q' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'x y q') @@ '(!x | y <-> z) <-> q' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'y y q') @@ '(x | y <-> !z) <-> q' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'x q') @@ '(x | y <-> !z) <-> q' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'x q') @@ '(!x | y <-> z) <-> q' AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'z q') @@ '(!x | y <-> z) <-> q' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', 'x y q y') @@ '!x <-> y' AS "true";
|
2016-04-07 17:44:18 +02:00
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2017-01-26 18:17:47 +01:00
|
|
|
select to_tsvector('simple', 'x y q y') @@ '!foo' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select to_tsvector('simple', '') @@ '!foo' AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2016-04-07 17:44:18 +02:00
|
|
|
--ranking
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank(' a:1 s:2C d g'::tsvector, 'a | s');
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
ts_rank
|
|
|
|
-------------
|
|
|
|
0.091189064
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
2008-05-16 18:31:02 +02:00
|
|
|
SELECT ts_rank(' a:1 sa:2C d g'::tsvector, 'a | s');
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
ts_rank
|
|
|
|
-------------
|
|
|
|
0.030396355
|
2008-05-16 18:31:02 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank(' a:1 sa:2C d g'::tsvector, 'a | s:*');
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
ts_rank
|
|
|
|
-------------
|
|
|
|
0.091189064
|
2008-05-16 18:31:02 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank(' a:1 sa:2C d g'::tsvector, 'a | sa:*');
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
ts_rank
|
|
|
|
-------------
|
|
|
|
0.091189064
|
2008-05-16 18:31:02 +02:00
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank(' a:1 s:2B d g'::tsvector, 'a | s');
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
ts_rank
|
|
|
|
------------
|
|
|
|
0.15198177
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank(' a:1 s:2 d g'::tsvector, 'a | s');
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
ts_rank
|
|
|
|
------------
|
|
|
|
0.06079271
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank(' a:1 s:2C d g'::tsvector, 'a & s');
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
ts_rank
|
|
|
|
------------
|
|
|
|
0.14015312
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank(' a:1 s:2B d g'::tsvector, 'a & s');
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
ts_rank
|
|
|
|
------------
|
|
|
|
0.19820644
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank(' a:1 s:2 d g'::tsvector, 'a & s');
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
ts_rank
|
|
|
|
------------
|
|
|
|
0.09910322
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank_cd(' a:1 s:2C d g'::tsvector, 'a | s');
|
2007-08-21 03:11:32 +02:00
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.3
|
|
|
|
(1 row)
|
|
|
|
|
2008-05-16 18:31:02 +02:00
|
|
|
SELECT ts_rank_cd(' a:1 sa:2C d g'::tsvector, 'a | s');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 sa:2C d g'::tsvector, 'a | s:*');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.3
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 sa:2C d g'::tsvector, 'a | sa:*');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.3
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 sa:3C sab:2c d g'::tsvector, 'a | sa:*');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.5
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank_cd(' a:1 s:2B d g'::tsvector, 'a | s');
|
2007-08-21 03:11:32 +02:00
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.5
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank_cd(' a:1 s:2 d g'::tsvector, 'a | s');
|
2007-08-21 03:11:32 +02:00
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.2
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank_cd(' a:1 s:2C d g'::tsvector, 'a & s');
|
2007-08-21 03:11:32 +02:00
|
|
|
ts_rank_cd
|
|
|
|
------------
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
0.13333334
|
2007-08-21 03:11:32 +02:00
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank_cd(' a:1 s:2B d g'::tsvector, 'a & s');
|
2007-08-21 03:11:32 +02:00
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.16
|
|
|
|
(1 row)
|
|
|
|
|
2007-08-21 17:41:13 +02:00
|
|
|
SELECT ts_rank_cd(' a:1 s:2 d g'::tsvector, 'a & s');
|
2007-08-21 03:11:32 +02:00
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.1
|
|
|
|
(1 row)
|
|
|
|
|
2016-04-07 17:44:18 +02:00
|
|
|
SELECT ts_rank_cd(' a:1 s:2A d g'::tsvector, 'a <-> s');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
0.18181819
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 s:2C d g'::tsvector, 'a <-> s');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
0.13333334
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 s:2 d g'::tsvector, 'a <-> s');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 s:2 d:2A g'::tsvector, 'a <-> s');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 s:2,3A d:2A g'::tsvector, 'a <2> s:A');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
0.09090909
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 b:2 s:3A d:2A g'::tsvector, 'a <2> s:A');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
0.09090909
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 sa:2D sb:2A g'::tsvector, 'a <-> s:*');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 sa:2A sb:2D g'::tsvector, 'a <-> s:*');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0.1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 sa:2A sb:2D g'::tsvector, 'a <-> s:* <-> sa:A');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
2016-06-27 19:41:00 +02:00
|
|
|
0
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ts_rank_cd(' a:1 sa:2A sb:2D g'::tsvector, 'a <-> s:* <-> sa:B');
|
|
|
|
ts_rank_cd
|
|
|
|
------------
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a:1 b:2'::tsvector @@ 'a <-> b'::tsquery AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a:1 b:2'::tsvector @@ 'a <0> b'::tsquery AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a:1 b:2'::tsvector @@ 'a <1> b'::tsquery AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2016-06-27 19:41:00 +02:00
|
|
|
SELECT 'a:1 b:2'::tsvector @@ 'a <2> b'::tsquery AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a:1 b:3'::tsvector @@ 'a <-> b'::tsquery AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a:1 b:3'::tsvector @@ 'a <0> b'::tsquery AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a:1 b:3'::tsvector @@ 'a <1> b'::tsquery AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 'a:1 b:3'::tsvector @@ 'a <2> b'::tsquery AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2016-06-27 19:41:00 +02:00
|
|
|
SELECT 'a:1 b:3'::tsvector @@ 'a <3> b'::tsquery AS "false";
|
|
|
|
false
|
|
|
|
-------
|
|
|
|
f
|
2016-04-07 17:44:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
Fix strange behavior (and possible crashes) in full text phrase search.
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
2016-12-21 21:18:25 +01:00
|
|
|
SELECT 'a:1 b:3'::tsvector @@ 'a <0> a:*'::tsquery AS "true";
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2016-03-11 17:22:36 +01:00
|
|
|
-- tsvector editing operations
|
|
|
|
SELECT strip('w:12B w:13* w:12,5,6 a:1,3* a:3 w asd:1dc asd'::tsvector);
|
|
|
|
strip
|
|
|
|
---------------
|
|
|
|
'a' 'asd' 'w'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT strip('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector);
|
|
|
|
strip
|
|
|
|
----------------------------------------------
|
|
|
|
'base' 'hidden' 'rebel' 'spaceship' 'strike'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT strip('base hidden rebel spaceship strike'::tsvector);
|
|
|
|
strip
|
|
|
|
----------------------------------------------
|
|
|
|
'base' 'hidden' 'rebel' 'spaceship' 'strike'
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete(to_tsvector('english', 'Rebel spaceships, striking from a hidden base'), 'spaceship');
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
------------------------------------------
|
|
|
|
'base':7 'hidden':6 'rebel':1 'strike':3
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector, 'base');
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
--------------------------------------------------------------
|
|
|
|
'hidden':6 'rebel':1 'spaceship':2,33A,34B,35C,36 'strike':3
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector, 'bas');
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
-----------------------------------------------------------------------
|
|
|
|
'base':7 'hidden':6 'rebel':1 'spaceship':2,33A,34B,35C,36 'strike':3
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector, 'bases');
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
-----------------------------------------------------------------------
|
|
|
|
'base':7 'hidden':6 'rebel':1 'spaceship':2,33A,34B,35C,36 'strike':3
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector, 'spaceship');
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
------------------------------------------
|
|
|
|
'base':7 'hidden':6 'rebel':1 'strike':3
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base hidden rebel spaceship strike'::tsvector, 'spaceship');
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
----------------------------------
|
|
|
|
'base' 'hidden' 'rebel' 'strike'
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector, ARRAY['spaceship','rebel']);
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
--------------------------------
|
|
|
|
'base':7 'hidden':6 'strike':3
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector, ARRAY['spaceships','rebel']);
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
-------------------------------------------------------------
|
|
|
|
'base':7 'hidden':6 'spaceship':2,33A,34B,35C,36 'strike':3
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector, ARRAY['spaceshi','rebel']);
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
-------------------------------------------------------------
|
|
|
|
'base':7 'hidden':6 'spaceship':2,33A,34B,35C,36 'strike':3
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector, ARRAY['spaceship','leya','rebel']);
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
--------------------------------
|
|
|
|
'base':7 'hidden':6 'strike':3
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base hidden rebel spaceship strike'::tsvector, ARRAY['spaceship','leya','rebel']);
|
|
|
|
ts_delete
|
2016-03-11 17:22:36 +01:00
|
|
|
--------------------------
|
|
|
|
'base' 'hidden' 'strike'
|
|
|
|
(1 row)
|
|
|
|
|
2016-08-05 21:14:08 +02:00
|
|
|
SELECT ts_delete('base hidden rebel spaceship strike'::tsvector, ARRAY['spaceship','leya','rebel','rebel']);
|
|
|
|
ts_delete
|
|
|
|
--------------------------
|
|
|
|
'base' 'hidden' 'strike'
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_delete('base hidden rebel spaceship strike'::tsvector, ARRAY['spaceship','leya','rebel', NULL]);
|
2016-03-11 17:22:36 +01:00
|
|
|
ERROR: lexeme array may not contain nulls
|
|
|
|
SELECT unnest('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector);
|
|
|
|
unnest
|
|
|
|
---------------------------------------------
|
|
|
|
(base,{7},{D})
|
|
|
|
(hidden,{6},{D})
|
|
|
|
(rebel,{1},{D})
|
|
|
|
(spaceship,"{2,33,34,35,36}","{D,A,B,C,D}")
|
|
|
|
(strike,{3},{D})
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
SELECT unnest('base hidden rebel spaceship strike'::tsvector);
|
|
|
|
unnest
|
|
|
|
---------------
|
|
|
|
(base,,)
|
|
|
|
(hidden,,)
|
|
|
|
(rebel,,)
|
|
|
|
(spaceship,,)
|
|
|
|
(strike,,)
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
SELECT * FROM unnest('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector);
|
|
|
|
lexeme | positions | weights
|
|
|
|
-----------+-----------------+-------------
|
|
|
|
base | {7} | {D}
|
|
|
|
hidden | {6} | {D}
|
|
|
|
rebel | {1} | {D}
|
|
|
|
spaceship | {2,33,34,35,36} | {D,A,B,C,D}
|
|
|
|
strike | {3} | {D}
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
SELECT * FROM unnest('base hidden rebel spaceship strike'::tsvector);
|
|
|
|
lexeme | positions | weights
|
|
|
|
-----------+-----------+---------
|
|
|
|
base | |
|
|
|
|
hidden | |
|
|
|
|
rebel | |
|
|
|
|
spaceship | |
|
|
|
|
strike | |
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
SELECT lexeme, positions[1] from unnest('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector);
|
|
|
|
lexeme | positions
|
|
|
|
-----------+-----------
|
|
|
|
base | 7
|
|
|
|
hidden | 6
|
|
|
|
rebel | 1
|
|
|
|
spaceship | 2
|
|
|
|
strike | 3
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
SELECT tsvector_to_array('base:7 hidden:6 rebel:1 spaceship:2,33A,34B,35C,36D strike:3'::tsvector);
|
|
|
|
tsvector_to_array
|
|
|
|
--------------------------------------
|
|
|
|
{base,hidden,rebel,spaceship,strike}
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT tsvector_to_array('base hidden rebel spaceship strike'::tsvector);
|
|
|
|
tsvector_to_array
|
|
|
|
--------------------------------------
|
|
|
|
{base,hidden,rebel,spaceship,strike}
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT array_to_tsvector(ARRAY['base','hidden','rebel','spaceship','strike']);
|
|
|
|
array_to_tsvector
|
|
|
|
----------------------------------------------
|
|
|
|
'base' 'hidden' 'rebel' 'spaceship' 'strike'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT array_to_tsvector(ARRAY['base','hidden','rebel','spaceship', NULL]);
|
|
|
|
ERROR: lexeme array may not contain nulls
|
2016-08-05 22:09:06 +02:00
|
|
|
-- array_to_tsvector must sort and de-dup
|
|
|
|
SELECT array_to_tsvector(ARRAY['foo','bar','baz','bar']);
|
|
|
|
array_to_tsvector
|
|
|
|
-------------------
|
|
|
|
'bar' 'baz' 'foo'
|
|
|
|
(1 row)
|
|
|
|
|
2016-03-11 17:22:36 +01:00
|
|
|
SELECT setweight('w:12B w:13* w:12,5,6 a:1,3* a:3 w asd:1dc asd zxc:81,567,222A'::tsvector, 'c');
|
|
|
|
setweight
|
|
|
|
----------------------------------------------------------
|
|
|
|
'a':1C,3C 'asd':1C 'w':5C,6C,12C,13C 'zxc':81C,222C,567C
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT setweight('a:1,3A asd:1C w:5,6,12B,13A zxc:81,222A,567'::tsvector, 'c');
|
|
|
|
setweight
|
|
|
|
----------------------------------------------------------
|
|
|
|
'a':1C,3C 'asd':1C 'w':5C,6C,12C,13C 'zxc':81C,222C,567C
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT setweight('a:1,3A asd:1C w:5,6,12B,13A zxc:81,222A,567'::tsvector, 'c', '{a}');
|
|
|
|
setweight
|
|
|
|
------------------------------------------------------
|
|
|
|
'a':1C,3C 'asd':1C 'w':5,6,12B,13A 'zxc':81,222A,567
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT setweight('a:1,3A asd:1C w:5,6,12B,13A zxc:81,222A,567'::tsvector, 'c', '{a}');
|
|
|
|
setweight
|
|
|
|
------------------------------------------------------
|
|
|
|
'a':1C,3C 'asd':1C 'w':5,6,12B,13A 'zxc':81,222A,567
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT setweight('a:1,3A asd:1C w:5,6,12B,13A zxc:81,222A,567'::tsvector, 'c', '{a,zxc}');
|
|
|
|
setweight
|
|
|
|
--------------------------------------------------------
|
|
|
|
'a':1C,3C 'asd':1C 'w':5,6,12B,13A 'zxc':81C,222C,567C
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT setweight('a asd w:5,6,12B,13A zxc'::tsvector, 'c', '{a,zxc}');
|
|
|
|
setweight
|
|
|
|
---------------------------------
|
|
|
|
'a' 'asd' 'w':5,6,12B,13A 'zxc'
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT setweight('a asd w:5,6,12B,13A zxc'::tsvector, 'c', ARRAY['a', 'zxc', NULL]);
|
|
|
|
ERROR: lexeme array may not contain nulls
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_filter('base:7A empir:17 evil:15 first:11 galact:16 hidden:6A rebel:1A spaceship:2A strike:3A victori:12 won:9'::tsvector, '{a}');
|
|
|
|
ts_filter
|
2016-03-11 17:22:36 +01:00
|
|
|
-------------------------------------------------------------
|
|
|
|
'base':7A 'hidden':6A 'rebel':1A 'spaceship':2A 'strike':3A
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_filter('base hidden rebel spaceship strike'::tsvector, '{a}');
|
|
|
|
ts_filter
|
|
|
|
-----------
|
2016-03-11 17:22:36 +01:00
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
2016-05-06 01:43:32 +02:00
|
|
|
SELECT ts_filter('base hidden rebel spaceship strike'::tsvector, '{a,b,NULL}');
|
2016-03-11 17:22:36 +01:00
|
|
|
ERROR: weight array may not contain nulls
|