int/bigint instead of timestamps

[NikolayS]

As we discussed at the recent Moscow meetup, for many cases it'd be very good to be able to use RUM to keep int/bigint information and speed up queries like

SELECT ... WHERE tsvector @@ ... ORDER BY price

Similar request from the -general: http://www.postgresql-archive.org/RUM-index-and-support-for-storing-BIGINT-as-part-of-a-tsvector-timestamp-tt5938725.html#a5942457

[obartunov]

On Mon, Apr 3, 2017 at 12:36 PM, Nikolay ***@***.***> wrote: As we discussed at the recent Moscow meetup, for many cases it'd be very good to be able to use RUM to keep int/bigint information and speed up queries like SELECT ... WHERE tsvector @@ ... ORDER BY price Similar request from the -general: http://www.postgresql-archive. org/RUM-index-and-support-for-storing-BIGINT-as-part-of-a- tsvector-timestamp-tt5938725.html#a5942457

yes, it's possible. We probably will implement something like we did for btree_gin - generate a bunch of opclasses for all built-in data types.

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#15>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGFI4suxoz0xPaHOo1CZnLN4zarOwGyCks5rsSAJgaJpZM4MxyhH> .

[darthunix]

And if rum keeps int/bigint information would queries like
select id from table where tsvector @@ .. (where id - int value in rum index)
still need recheck in heap (except needs of visibility map)?

[andreak]

I'm so glad to see that this will be addressed!

Note that what I asked about in the referred email was not BIGINT instead of TIMESTAMP, but in addition to. Will storing TSVECTOR and both BIGINT and TIMESTAMP (for ordering) in the same RUM-index be possible, so we can have this:

WHERE
    fts_all @@ to_tsquery('simple', 'andre:*&jose:*') 
    AND folder_id = ANY(ARRAY[2,3]::BIGINT[]) 
ORDER BY received_timestamp DESC LIMIT 10

and have it use one index only?
If so this will be ultimately coolio!

Thanks.

[NikolayS]

@andreak really good example, I also see lots of similar cases

[andreak]

I'm not quite sure where to post questions about RUM so I've posted another question to -general:
http://www.postgresql-archive.org/How-to-include-BIGINT-column-in-RUM-index-sorted-by-timestamp-td5961689.html
Is posting to -general the "correct" way to ask questions about RUM? (creating new issues here on github seems strange)

[za-arthur]

I think both ways are appropriate. Oleg Bartunov and me are monitoring -general. Also you can create new issues here.

[andreak]

Ah, good to know, thanks.

[feodor]

Hi! I checked your example and what I want to say: ANY clause is only supported by bitmap scan. Obviously, bitmap scan cannot return data in order desired by ORDER BY clause - sort should be performed. If you don't use ANY clause postgres will be able execute all conditions in index: EXPLAIN (analyze on, COSTS OFF) SELECT del.received_timestamp, del.received_timestamp <=> '3000-01-01' :: TIMESTAMP, del.folder_id FROM email_delivery del WHERE del.fts_all @@ to_tsquery('simple', 'andre:*&jose:*') AND del.folder_id = 44965::bigint ORDER BY del.received_timestamp <=> '3000-01-01' :: TIMESTAMP ; PLAN ---------------------------------------------------------------------------------------------------- Index Scan using rum_idx on email_delivery del (actual time=0.919..0.921 rows=1 loops=1) Index Cond: ((fts_all @@ '''andre'':* & ''jose'':*'::tsquery) AND (folder_id = '44965'::bigint)) Order By: (received_timestamp <=> '3000-01-01 00:00:00'::timestamp without time zone) But notice, use explicite cast of numeric constant to type of folder_id. In future it could be fixed by adding set of comparison operations with different types on left and right side to RUM's opclasses. Next example: EXPLAIN (analyze on, COSTS OFF) SELECT del.received_timestamp, del.received_timestamp <=> '3000-01-01' :: TIMESTAMP, del.folder_id FROM email_delivery del WHERE del.folder_id in ( 44965::bigint, 2470520) ; QUERY PLAN ---------------------------------------------------------------------------------- Bitmap Heap Scan on email_delivery del (actual time=0.208..0.210 rows=1 loops=1) Recheck Cond: (folder_id = ANY ('{44965,2470520}'::bigint[])) Heap Blocks: exact=1 -> Bitmap Index Scan on rum_idx (actual time=0.186..0.186 rows=1 loops=1) Index Cond: (folder_id = ANY ('{44965,2470520}'::bigint[])) Work as expected, but it's easy to prove that actually it does two index scans in one bitmap. So, it works, but: set enable_indexscan=off; EXPLAIN (analyze on, COSTS OFF) SELECT del.received_timestamp, del.received_timestamp <=> '3000-01-01' :: TIMESTAMP, del.folder_id FROM email_delivery del WHERE del.fts_all @@ to_tsquery('simple', 'andre:*&jose:*') AND del.folder_id in ( 44965::bigint, 2470520) ; WARNING: rumbeginscan 1:0 WARNING: rumrescan 1 QUERY PLAN ---------------------------------------------------------------------------------- Bitmap Heap Scan on email_delivery del (actual time=0.108..0.110 rows=1 loops=1) Recheck Cond: (fts_all @@ '''andre'':* & ''jose'':*'::tsquery) Filter: (folder_id = ANY ('{44965,2470520}'::bigint[])) Heap Blocks: exact=1 -> Bitmap Index Scan on rum_idx (actual time=0.080..0.080 rows=1 loops=1) Index Cond: (fts_all @@ '''andre'':* & ''jose'':*'::tsquery) Here I'm not sure why postgres does not push ANY clause to index scan but I suppose it thinks that it's too expensive to do two index scans with fts clause. Andreas Joseph Krogh wrote:

…

I'm not quite sure where to post questions about RUM so I've posted another question to -general: http://www.postgresql-archive.org/How-to-include-BIGINT-column-in-RUM-index-sorted-by-timestamp-td5961689.html Is posting to -general the "correct" way to ask questions about RUM? (creating new issues here on github seems strange) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAz9vN0sMZQvmyOiSYzTOx_FMjblegE3ks5r6HGQgaJpZM4MxyhH>.

-- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/

[andreak]

Hi Feodor.

Thanks for the hint about the extra casting, now it works at least with equals on folder_id, as you said:

EXPLAIN ANALYZE
SELECT
    del.entity_id,
    del.received_timestamp,
    del.received_timestamp <=> '3000-01-01' :: TIMESTAMP,
    del.folder_id
FROM origo_email_delivery del
WHERE del.fts_all @@ to_tsquery('simple', 'andre:*&jose:*')
      AND del.folder_id = 2470520::BIGINT
ORDER BY del.received_timestamp <=> '3000-01-01' :: TIMESTAMP
LIMIT 10

┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                    QUERY PLAN                                                                    │
├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Limit  (cost=84.00..124.97 rows=10 width=32) (actual time=482.219..482.235 rows=10 loops=1)                                                      │
│   ->  Index Scan using rum_idx on origo_email_delivery del  (cost=84.00..313.40 rows=56 width=32) (actual time=482.218..482.232 rows=10 loops=1) │
│         Index Cond: ((fts_all @@ '''andre'':* & ''jose'':*'::tsquery) AND (folder_id = '2470520'::bigint))                                       │
│         Order By: (received_timestamp <=> '3000-01-01 00:00:00'::timestamp without time zone)                                                    │
│ Planning time: 0.213 ms                                                                                                                          │
│ Execution time: 485.934 ms                                                                                                                       │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Sadly, it doesn't seem to be faster than GIN with Sort-step.

create index origo_email_delivery_fts_all_folder_idx ON origo_email_delivery using gin (fts_all, folder_id)

EXPLAIN ANALYZE
SELECT
    del.entity_id,
    del.received_timestamp,
    del.received_timestamp <=> '3000-01-01' :: TIMESTAMP,
    del.folder_id
FROM origo_email_delivery del
WHERE del.fts_all @@ to_tsquery('simple', 'andre:*&jose:*')
      AND del.folder_id = 2470520::BIGINT
ORDER BY del.received_timestamp DESC

┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                         QUERY PLAN                                                                          │
├─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Sort  (cost=307.89..308.03 rows=56 width=32) (actual time=90.567..90.672 rows=2958 loops=1)                                                                 │
│   Sort Key: received_timestamp DESC                                                                                                                         │
│   Sort Method: quicksort  Memory: 328kB                                                                                                                     │
│   ->  Bitmap Heap Scan on origo_email_delivery del  (cost=84.58..306.27 rows=56 width=32) (actual time=86.467..90.067 rows=2958 loops=1)                    │
│         Recheck Cond: ((fts_all @@ '''andre'':* & ''jose'':*'::tsquery) AND (folder_id = '2470520'::bigint))                                                │
│         Heap Blocks: exact=2750                                                                                                                             │
│         ->  Bitmap Index Scan on origo_email_delivery_fts_all_folder_idx  (cost=0.00..84.56 rows=56 width=0) (actual time=86.193..86.193 rows=2958 loops=1) │
│               Index Cond: ((fts_all @@ '''andre'':* & ''jose'':*'::tsquery) AND (folder_id = '2470520'::bigint))                                            │
│ Planning time: 0.409 ms                                                                                                                                     │
│ Execution time: 90.791 ms                                                                                                                                   │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Any comments on why GIN is faster?

[feodor]

EXPLAIN ANALYZE SELECT del.entity_id, del.received_timestamp, del.received_timestamp <=> '3000-01-01' :: TIMESTAMP, del.folder_id FROM origo_email_delivery del WHERE del.fts_all @@ to_tsquery('simple', 'andre:*&jose:*') AND del.folder_id = 2470520::BIGINT ORDER BY del.received_timestamp <=> '3000-01-01' :: TIMESTAMP LIMIT 10 Sadly, it doesn't seem to be faster than GIN with Sort-step.

I haven't time to deep check today, but, seems, it's because of prefix search in tsquery. Pls, compare without it. When you use prefix search in tsquery, RUM should combine results from several lists (andre, andres, andreas etc) and it could not merge results in correct order. Prefix search also should remove duplicates from result: document could contain more than one matching word. So, RUM actually does sort internally and then removes duplicates. GIN could be faster in this case because bitmap is for effective way for removing than sort and unique. Will look closer ASAP.

…

-- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/

[andreak]

Hm, this query (without prefix search) runs forever (using pg-10-master as of 2df537e43fdc432cccbe64de166ac97363cbca3c and RUM as of 9ac931a):

EXPLAIN ANALYZE
SELECT
    del.entity_id,
    del.received_timestamp,
    del.received_timestamp <=> '3000-01-01' :: TIMESTAMP,
    del.folder_id
FROM origo_email_delivery del
WHERE del.fts_all @@ to_tsquery('simple', 'andreas&joseph')
      AND del.folder_id = 2470520::BIGINT
ORDER BY del.received_timestamp <=> '3000-01-01' :: TIMESTAMP
LIMIT 10

Taking 100% CPU.
Trying to cancel with CTRL+C fails.

How shuold I go about debugging this?

[feodor]

Andreas Joseph Krogh wrote:

Hm, this query (without prefix search) runs forever (using pg-10-master as of

Huh, surprise...

How shuold I go about debugging this?

pls, provide several backtraces with gdb

…

-- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/

[andreak]

Does this help?

Attaching to process 30544
Reading symbols from /home/andreak/programs/postgresql-master/bin/postgres...done.
...
0x0000556d1bfce292 in check_stack_depth () at postgres.c:3103
3103    {
(gdb) bt
#0  0x0000556d1bfce292 in check_stack_depth () at postgres.c:3103
#1  0x0000556d1c0a8a59 in TS_execute (curitem=<optimized out>, arg=0x7ffec5d0f180, flags=2, chkcond=0x7f5595641e30 <pre_checkcondition_rum>) at tsvector_op.c:1819
#2  0x00007f559564374d in rum_tsquery_pre_consistent (fcinfo=<optimized out>) at src/rum_ts_utils.c:190
#3  0x0000556d1c0d85c3 in FunctionCall8Coll (flinfo=<optimized out>, collation=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=93927121658784, arg6=140732217226768, arg7=93927121658728, arg8=93927121658912)
    at fmgr.c:1242
#4  0x00007f559564f4bc in preConsistentCheck (so=<optimized out>) at src/rumget.c:1755
#5  scanGetItemFast (scan=<optimized out>, advancePast=0x7ffec5d0f6b6, recheck=0x7ffec5d0f6b6 "", item=0x556d1cb8a298) at src/rumget.c:1858
#6  scanGetItem (advancePast=advancePast@entry=0x556d1cb8a298, item=item@entry=0x556d1cb8a298, recheck=recheck@entry=0x7ffec5d0f6b6 "", scan=<optimized out>) at src/rumget.c:2017
#7  0x00007f559564fb1b in rumgettuple (scan=0x556d1cb83198, direction=ForwardScanDirection) at src/rumget.c:2260
#8  0x0000556d1bd6ff8e in index_getnext_tid (scan=0x556d1cb83198, direction=<optimized out>) at indexam.c:541
#9  0x0000556d1bd70183 in index_getnext (scan=scan@entry=0x556d1cb83198, direction=direction@entry=ForwardScanDirection) at indexam.c:679
#10 0x0000556d1bebc693 in IndexNextWithReorder (node=node@entry=0x556d1cb803f8) at nodeIndexscan.c:269
#11 0x0000556d1beac9e2 in ExecScanFetch (recheckMtd=0x556d1bebc1d0 <IndexRecheck>, accessMtd=0x556d1bebc5e0 <IndexNextWithReorder>, node=0x556d1cb803f8) at execScan.c:95
#12 ExecScan (node=0x556d1cb803f8, accessMtd=0x556d1bebc5e0 <IndexNextWithReorder>, recheckMtd=0x556d1bebc1d0 <IndexRecheck>) at execScan.c:162
#13 0x0000556d1beab858 in ExecProcNode (node=node@entry=0x556d1cb803f8) at execProcnode.c:455
#14 0x0000556d1bebf000 in ExecLimit (node=node@entry=0x556d1cb7fc88) at nodeLimit.c:91
#15 0x0000556d1beab678 in ExecProcNode (node=node@entry=0x556d1cb7fc88) at execProcnode.c:571
#16 0x0000556d1bea6ea6 in ExecutePlan (execute_once=<optimized out>, dest=0x556d1cb6dd90, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x556d1cb7fc88, estate=0x556d1cb7fa78)
    at execMain.c:1706
#17 standard_ExecutorRun (queryDesc=0x556d1cb7b3e8, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:360
#18 0x0000556d1bfd245c in PortalRunSelect (portal=portal@entry=0x556d1ca854f8, forward=forward@entry=1 '\001', count=0, count@entry=9223372036854775807, dest=dest@entry=0x556d1cb6dd90) at pquery.c:933
#19 0x0000556d1bfd3896 in PortalRun (portal=portal@entry=0x556d1ca854f8, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=1 '\001', run_once=run_once@entry=1 '\001', dest=dest@entry=0x556d1cb6dd90, altdest=altdest@entry=0x556d1cb6dd90, 
    completionTag=0x7ffec5d0faf0 "") at pquery.c:774
#20 0x0000556d1bfcf83a in exec_simple_query (
    query_string=0x556d1caebef8 "SELECT\n    del.entity_id,\n    del.received_timestamp,\n    del.received_timestamp <=> '3000-01-01' :: TIMESTAMP,\n    del.folder_id\nFROM origo_email_delivery del\nWHERE del.fts_all @@ to_tsquery('simple'"...) at postgres.c:1105
#21 0x0000556d1bfd1577 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x556d1ca936c0, dbname=<optimized out>, username=<optimized out>) at postgres.c:4075
#22 0x0000556d1bd27e2f in BackendRun (port=0x556d1ca896b0) at postmaster.c:4334
#23 BackendStartup (port=0x556d1ca896b0) at postmaster.c:4006
#24 ServerLoop () at postmaster.c:1743
#25 0x0000556d1bf65362 in PostmasterMain (argc=3, argv=0x556d1ca65b10) at postmaster.c:1351
#26 0x0000556d1bd28e27 in main (argc=3, argv=0x556d1ca65b10) at main.c:228
(gdb) quit

...wait a bit...

Attaching to process 30544
Reading symbols from /home/andreak/programs/postgresql-master/bin/postgres...done.
...
pre_checkcondition_rum (checkval=0x7ffec5d0f180, val=<optimized out>, data=<optimized out>) at src/rum_ts_utils.c:163
163     }
(gdb) bt
#0  pre_checkcondition_rum (checkval=0x7ffec5d0f180, val=<optimized out>, data=<optimized out>) at src/rum_ts_utils.c:163
#1  0x0000556d1c0a8af8 in TS_execute (curitem=<optimized out>, arg=0x7ffec5d0f180, flags=2, chkcond=0x7f5595641e30 <pre_checkcondition_rum>) at tsvector_op.c:1834
#2  0x00007f559564374d in rum_tsquery_pre_consistent (fcinfo=<optimized out>) at src/rum_ts_utils.c:190
#3  0x0000556d1c0d85c3 in FunctionCall8Coll (flinfo=<optimized out>, collation=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=93927121658784, arg6=140732217226768, arg7=93927121658728, arg8=93927121658912)
    at fmgr.c:1242
#4  0x00007f559564f4bc in preConsistentCheck (so=<optimized out>) at src/rumget.c:1755
#5  scanGetItemFast (scan=<optimized out>, advancePast=0x7ffec5d0f6b6, recheck=0x7ffec5d0f6b6 "", item=0x556d1cb8a298) at src/rumget.c:1858
#6  scanGetItem (advancePast=advancePast@entry=0x556d1cb8a298, item=item@entry=0x556d1cb8a298, recheck=recheck@entry=0x7ffec5d0f6b6 "", scan=<optimized out>) at src/rumget.c:2017
#7  0x00007f559564fb1b in rumgettuple (scan=0x556d1cb83198, direction=ForwardScanDirection) at src/rumget.c:2260
#8  0x0000556d1bd6ff8e in index_getnext_tid (scan=0x556d1cb83198, direction=<optimized out>) at indexam.c:541
#9  0x0000556d1bd70183 in index_getnext (scan=scan@entry=0x556d1cb83198, direction=direction@entry=ForwardScanDirection) at indexam.c:679
#10 0x0000556d1bebc693 in IndexNextWithReorder (node=node@entry=0x556d1cb803f8) at nodeIndexscan.c:269
#11 0x0000556d1beac9e2 in ExecScanFetch (recheckMtd=0x556d1bebc1d0 <IndexRecheck>, accessMtd=0x556d1bebc5e0 <IndexNextWithReorder>, node=0x556d1cb803f8) at execScan.c:95
#12 ExecScan (node=0x556d1cb803f8, accessMtd=0x556d1bebc5e0 <IndexNextWithReorder>, recheckMtd=0x556d1bebc1d0 <IndexRecheck>) at execScan.c:162
#13 0x0000556d1beab858 in ExecProcNode (node=node@entry=0x556d1cb803f8) at execProcnode.c:455
#14 0x0000556d1bebf000 in ExecLimit (node=node@entry=0x556d1cb7fc88) at nodeLimit.c:91
#15 0x0000556d1beab678 in ExecProcNode (node=node@entry=0x556d1cb7fc88) at execProcnode.c:571
#16 0x0000556d1bea6ea6 in ExecutePlan (execute_once=<optimized out>, dest=0x556d1cb6dd90, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x556d1cb7fc88, estate=0x556d1cb7fa78)
    at execMain.c:1706
#17 standard_ExecutorRun (queryDesc=0x556d1cb7b3e8, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:360
#18 0x0000556d1bfd245c in PortalRunSelect (portal=portal@entry=0x556d1ca854f8, forward=forward@entry=1 '\001', count=0, count@entry=9223372036854775807, dest=dest@entry=0x556d1cb6dd90) at pquery.c:933
#19 0x0000556d1bfd3896 in PortalRun (portal=portal@entry=0x556d1ca854f8, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=1 '\001', run_once=run_once@entry=1 '\001', dest=dest@entry=0x556d1cb6dd90, altdest=altdest@entry=0x556d1cb6dd90,
    completionTag=0x7ffec5d0faf0 "") at pquery.c:774
#20 0x0000556d1bfcf83a in exec_simple_query (
    query_string=0x556d1caebef8 "SELECT\n    del.entity_id,\n    del.received_timestamp,\n    del.received_timestamp <=> '3000-01-01' :: TIMESTAMP,\n    del.folder_id\nFROM origo_email_delivery del\nWHERE del.fts_all @@ to_tsquery('simple'"...) at postgres.c:1105
#21 0x0000556d1bfd1577 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x556d1ca936c0, dbname=<optimized out>, username=<optimized out>) at postgres.c:4075
#22 0x0000556d1bd27e2f in BackendRun (port=0x556d1ca896b0) at postmaster.c:4334
#23 BackendStartup (port=0x556d1ca896b0) at postmaster.c:4006
#24 ServerLoop () at postmaster.c:1743
#25 0x0000556d1bf65362 in PostmasterMain (argc=3, argv=0x556d1ca65b10) at postmaster.c:1351
#26 0x0000556d1bd28e27 in main (argc=3, argv=0x556d1ca65b10) at main.c:228
(gdb)

...wait a bit more...

Attaching to process 30544
Reading symbols from /home/andreak/programs/postgresql-master/bin/postgres...done.
...
preConsistentCheck (so=<optimized out>) at src/rumget.c:1743
1743                    for (i = 0; i < key->nentries; i++)
(gdb) bt
#0  preConsistentCheck (so=<optimized out>) at src/rumget.c:1743
#1  scanGetItemFast (scan=<optimized out>, advancePast=0x7ffec5d0f6b6, recheck=0x7ffec5d0f6b6 "", item=0x556d1cb8a298) at src/rumget.c:1858
#2  scanGetItem (advancePast=advancePast@entry=0x556d1cb8a298, item=item@entry=0x556d1cb8a298, recheck=recheck@entry=0x7ffec5d0f6b6 "", scan=<optimized out>) at src/rumget.c:2017
#3  0x00007f559564fb1b in rumgettuple (scan=0x556d1cb83198, direction=ForwardScanDirection) at src/rumget.c:2260
#4  0x0000556d1bd6ff8e in index_getnext_tid (scan=0x556d1cb83198, direction=<optimized out>) at indexam.c:541
#5  0x0000556d1bd70183 in index_getnext (scan=scan@entry=0x556d1cb83198, direction=direction@entry=ForwardScanDirection) at indexam.c:679
#6  0x0000556d1bebc693 in IndexNextWithReorder (node=node@entry=0x556d1cb803f8) at nodeIndexscan.c:269
#7  0x0000556d1beac9e2 in ExecScanFetch (recheckMtd=0x556d1bebc1d0 <IndexRecheck>, accessMtd=0x556d1bebc5e0 <IndexNextWithReorder>, node=0x556d1cb803f8) at execScan.c:95
#8  ExecScan (node=0x556d1cb803f8, accessMtd=0x556d1bebc5e0 <IndexNextWithReorder>, recheckMtd=0x556d1bebc1d0 <IndexRecheck>) at execScan.c:162
#9  0x0000556d1beab858 in ExecProcNode (node=node@entry=0x556d1cb803f8) at execProcnode.c:455
#10 0x0000556d1bebf000 in ExecLimit (node=node@entry=0x556d1cb7fc88) at nodeLimit.c:91
#11 0x0000556d1beab678 in ExecProcNode (node=node@entry=0x556d1cb7fc88) at execProcnode.c:571
#12 0x0000556d1bea6ea6 in ExecutePlan (execute_once=<optimized out>, dest=0x556d1cb6dd90, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x556d1cb7fc88, estate=0x556d1cb7fa78)
    at execMain.c:1706
#13 standard_ExecutorRun (queryDesc=0x556d1cb7b3e8, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:360
#14 0x0000556d1bfd245c in PortalRunSelect (portal=portal@entry=0x556d1ca854f8, forward=forward@entry=1 '\001', count=0, count@entry=9223372036854775807, dest=dest@entry=0x556d1cb6dd90) at pquery.c:933
#15 0x0000556d1bfd3896 in PortalRun (portal=portal@entry=0x556d1ca854f8, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=1 '\001', run_once=run_once@entry=1 '\001', dest=dest@entry=0x556d1cb6dd90, altdest=altdest@entry=0x556d1cb6dd90,
    completionTag=0x7ffec5d0faf0 "") at pquery.c:774
#16 0x0000556d1bfcf83a in exec_simple_query (
    query_string=0x556d1caebef8 "SELECT\n    del.entity_id,\n    del.received_timestamp,\n    del.received_timestamp <=> '3000-01-01' :: TIMESTAMP,\n    del.folder_id\nFROM origo_email_delivery del\nWHERE del.fts_all @@ to_tsquery('simple'"...) at postgres.c:1105
#17 0x0000556d1bfd1577 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x556d1ca936c0, dbname=<optimized out>, username=<optimized out>) at postgres.c:4075
#18 0x0000556d1bd27e2f in BackendRun (port=0x556d1ca896b0) at postmaster.c:4334
#19 BackendStartup (port=0x556d1ca896b0) at postmaster.c:4006
#20 ServerLoop () at postmaster.c:1743
#21 0x0000556d1bf65362 in PostmasterMain (argc=3, argv=0x556d1ca65b10) at postmaster.c:1351
#22 0x0000556d1bd28e27 in main (argc=3, argv=0x556d1ca65b10) at main.c:228

...wait a bit more...

Attaching to process 30544
Reading symbols from /home/andreak/programs/postgresql-master/bin/postgres...done.
...
scanGetItemFast (scan=<optimized out>, advancePast=0x7ffec5d0f6b6, recheck=0x7ffec5d0f6b6 "", item=0x556d1cb8a298) at src/rumget.c:1855
1855                                    for (; j < i; j++)
(gdb) bt
#0  scanGetItemFast (scan=<optimized out>, advancePast=0x7ffec5d0f6b6, recheck=0x7ffec5d0f6b6 "", item=0x556d1cb8a298) at src/rumget.c:1855
#1  scanGetItem (advancePast=advancePast@entry=0x556d1cb8a298, item=item@entry=0x556d1cb8a298, recheck=recheck@entry=0x7ffec5d0f6b6 "", scan=<optimized out>) at src/rumget.c:2017
#2  0x00007f559564fb1b in rumgettuple (scan=0x556d1cb83198, direction=ForwardScanDirection) at src/rumget.c:2260
#3  0x0000556d1bd6ff8e in index_getnext_tid (scan=0x556d1cb83198, direction=<optimized out>) at indexam.c:541
#4  0x0000556d1bd70183 in index_getnext (scan=scan@entry=0x556d1cb83198, direction=direction@entry=ForwardScanDirection) at indexam.c:679
#5  0x0000556d1bebc693 in IndexNextWithReorder (node=node@entry=0x556d1cb803f8) at nodeIndexscan.c:269
#6  0x0000556d1beac9e2 in ExecScanFetch (recheckMtd=0x556d1bebc1d0 <IndexRecheck>, accessMtd=0x556d1bebc5e0 <IndexNextWithReorder>, node=0x556d1cb803f8) at execScan.c:95
#7  ExecScan (node=0x556d1cb803f8, accessMtd=0x556d1bebc5e0 <IndexNextWithReorder>, recheckMtd=0x556d1bebc1d0 <IndexRecheck>) at execScan.c:162
#8  0x0000556d1beab858 in ExecProcNode (node=node@entry=0x556d1cb803f8) at execProcnode.c:455
#9  0x0000556d1bebf000 in ExecLimit (node=node@entry=0x556d1cb7fc88) at nodeLimit.c:91
#10 0x0000556d1beab678 in ExecProcNode (node=node@entry=0x556d1cb7fc88) at execProcnode.c:571
#11 0x0000556d1bea6ea6 in ExecutePlan (execute_once=<optimized out>, dest=0x556d1cb6dd90, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x556d1cb7fc88, estate=0x556d1cb7fa78)
    at execMain.c:1706
#12 standard_ExecutorRun (queryDesc=0x556d1cb7b3e8, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:360
#13 0x0000556d1bfd245c in PortalRunSelect (portal=portal@entry=0x556d1ca854f8, forward=forward@entry=1 '\001', count=0, count@entry=9223372036854775807, dest=dest@entry=0x556d1cb6dd90) at pquery.c:933
#14 0x0000556d1bfd3896 in PortalRun (portal=portal@entry=0x556d1ca854f8, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=1 '\001', run_once=run_once@entry=1 '\001', dest=dest@entry=0x556d1cb6dd90, altdest=altdest@entry=0x556d1cb6dd90,
    completionTag=0x7ffec5d0faf0 "") at pquery.c:774
#15 0x0000556d1bfcf83a in exec_simple_query (
    query_string=0x556d1caebef8 "SELECT\n    del.entity_id,\n    del.received_timestamp,\n    del.received_timestamp <=> '3000-01-01' :: TIMESTAMP,\n    del.folder_id\nFROM origo_email_delivery del\nWHERE del.fts_all @@ to_tsquery('simple'"...) at postgres.c:1105
#16 0x0000556d1bfd1577 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x556d1ca936c0, dbname=<optimized out>, username=<optimized out>) at postgres.c:4075
#17 0x0000556d1bd27e2f in BackendRun (port=0x556d1ca896b0) at postmaster.c:4334
#18 BackendStartup (port=0x556d1ca896b0) at postmaster.c:4006
#19 ServerLoop () at postmaster.c:1743
#20 0x0000556d1bf65362 in PostmasterMain (argc=3, argv=0x556d1ca65b10) at postmaster.c:1351
#21 0x0000556d1bd28e27 in main (argc=3, argv=0x556d1ca65b10) at main.c:228
(gdb)

...wait a bit more...

Attaching to process 30544
Reading symbols from /home/andreak/programs/postgresql-master/bin/postgres...done.
...
0x0000556d1bfce33e in check_stack_depth () at postgres.c:3113
3113    }
(gdb) bt
#0  0x0000556d1bfce33e in check_stack_depth () at postgres.c:3113
#1  0x0000556d1c0a8a59 in TS_execute (curitem=<optimized out>, arg=0x7ffec5d0f180, flags=2, chkcond=0x7f5595641e30 <pre_checkcondition_rum>) at tsvector_op.c:1819
#2  0x00007f559564374d in rum_tsquery_pre_consistent (fcinfo=<optimized out>) at src/rum_ts_utils.c:190
#3  0x0000556d1c0d85c3 in FunctionCall8Coll (flinfo=<optimized out>, collation=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=93927121658784, arg6=140732217226768, arg7=93927121658728, arg8=93927121658912)
    at fmgr.c:1242
#4  0x00007f559564f4bc in preConsistentCheck (so=<optimized out>) at src/rumget.c:1755
#5  scanGetItemFast (scan=<optimized out>, advancePast=0x7ffec5d0f6b6, recheck=0x7ffec5d0f6b6 "", item=0x556d1cb8a298) at src/rumget.c:1858
#6  scanGetItem (advancePast=advancePast@entry=0x556d1cb8a298, item=item@entry=0x556d1cb8a298, recheck=recheck@entry=0x7ffec5d0f6b6 "", scan=<optimized out>) at src/rumget.c:2017
#7  0x00007f559564fb1b in rumgettuple (scan=0x556d1cb83198, direction=ForwardScanDirection) at src/rumget.c:2260
#8  0x0000556d1bd6ff8e in index_getnext_tid (scan=0x556d1cb83198, direction=<optimized out>) at indexam.c:541
#9  0x0000556d1bd70183 in index_getnext (scan=scan@entry=0x556d1cb83198, direction=direction@entry=ForwardScanDirection) at indexam.c:679
#10 0x0000556d1bebc693 in IndexNextWithReorder (node=node@entry=0x556d1cb803f8) at nodeIndexscan.c:269
#11 0x0000556d1beac9e2 in ExecScanFetch (recheckMtd=0x556d1bebc1d0 <IndexRecheck>, accessMtd=0x556d1bebc5e0 <IndexNextWithReorder>, node=0x556d1cb803f8) at execScan.c:95
#12 ExecScan (node=0x556d1cb803f8, accessMtd=0x556d1bebc5e0 <IndexNextWithReorder>, recheckMtd=0x556d1bebc1d0 <IndexRecheck>) at execScan.c:162
#13 0x0000556d1beab858 in ExecProcNode (node=node@entry=0x556d1cb803f8) at execProcnode.c:455
#14 0x0000556d1bebf000 in ExecLimit (node=node@entry=0x556d1cb7fc88) at nodeLimit.c:91
#15 0x0000556d1beab678 in ExecProcNode (node=node@entry=0x556d1cb7fc88) at execProcnode.c:571
#16 0x0000556d1bea6ea6 in ExecutePlan (execute_once=<optimized out>, dest=0x556d1cb6dd90, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x556d1cb7fc88, estate=0x556d1cb7fa78)
    at execMain.c:1706
#17 standard_ExecutorRun (queryDesc=0x556d1cb7b3e8, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:360
#18 0x0000556d1bfd245c in PortalRunSelect (portal=portal@entry=0x556d1ca854f8, forward=forward@entry=1 '\001', count=0, count@entry=9223372036854775807, dest=dest@entry=0x556d1cb6dd90) at pquery.c:933
#19 0x0000556d1bfd3896 in PortalRun (portal=portal@entry=0x556d1ca854f8, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=1 '\001', run_once=run_once@entry=1 '\001', dest=dest@entry=0x556d1cb6dd90, altdest=altdest@entry=0x556d1cb6dd90,
    completionTag=0x7ffec5d0faf0 "") at pquery.c:774
#20 0x0000556d1bfcf83a in exec_simple_query (
    query_string=0x556d1caebef8 "SELECT\n    del.entity_id,\n    del.received_timestamp,\n    del.received_timestamp <=> '3000-01-01' :: TIMESTAMP,\n    del.folder_id\nFROM origo_email_delivery del\nWHERE del.fts_all @@ to_tsquery('simple'"...) at postgres.c:1105
#21 0x0000556d1bfd1577 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x556d1ca936c0, dbname=<optimized out>, username=<optimized out>) at postgres.c:4075
#22 0x0000556d1bd27e2f in BackendRun (port=0x556d1ca896b0) at postmaster.c:4334
#23 BackendStartup (port=0x556d1ca896b0) at postmaster.c:4006
#24 ServerLoop () at postmaster.c:1743
#25 0x0000556d1bf65362 in PostmasterMain (argc=3, argv=0x556d1ca65b10) at postmaster.c:1351
#26 0x0000556d1bd28e27 in main (argc=3, argv=0x556d1ca65b10) at main.c:228
(gdb)

Hope this helps