Comments (46)
from rum.
Yes, you can use rum_tsvector_addon_ops now. Thank you for noticing.
from rum.
Unfortunately, ordering within index can be performed only using some value to compare. Please try out the query:
$ select * from rum where tsvector @@ plainto_tsquery('simple', 'cow') order by id <=> 1000000 limit 10;
$ select * from rum where tsvector @@ plainto_tsquery('simple', 'cow') order by id <=> 0 limit 10;
Depending on the compared value results a different.
from rum.
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)?
from rum.
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.
from rum.
@andreak really good example, I also see lots of similar cases
from rum.
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)
from rum.
I think both ways are appropriate. Oleg Bartunov and me are monitoring -general. Also you can create new issues here.
from rum.
Ah, good to know, thanks.
from rum.
from rum.
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?
from rum.
from rum.
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?
from rum.
from rum.
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
from rum.
Thank you for the information!
Can you check your endless query again with new commit.
from rum.
Works perfectly, thanks!
from rum.
To answer Teodor's question;
The query without prefix-search is 10 times faster:
with prefix:
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.98 rows=10 width=32) (actual time=433.761..433.776 rows=10 loops=1) │
│ -> Index Scan using rum_idx on origo_email_delivery del (cost=84.00..309.38 rows=55 width=32) (actual time=433.759..433.773 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.671 ms │
│ Execution time: 436.307 ms │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
without prefix:
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
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ QUERY PLAN │
├────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Limit (cost=72.00..114.16 rows=10 width=32) (actual time=43.099..43.113 rows=10 loops=1) │
│ -> Index Scan using rum_idx on origo_email_delivery del (cost=72.00..160.53 rows=21 width=32) (actual time=43.097..43.110 rows=10 loops=1) │
│ Index Cond: ((fts_all @@ '''andreas'' & ''joseph'''::tsquery) AND (folder_id = '2470520'::bigint)) │
│ Order By: (received_timestamp <=> '3000-01-01 00:00:00'::timestamp without time zone) │
│ Planning time: 0.684 ms │
│ Execution time: 43.159 ms │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
The question now of course is will it ever be possible, theoretically, for the prefix-variant to be faster, or is there some fundamental limit or logic-barrier preventing it from ever will be?
from rum.
Great!
About your question. It is because of algorithm of scanning by prefix query. Maybe it could be improved. We need to investigate it.
from rum.
Thanks.
I think this issue can be closed now, and any other issues/questions I might have can be asked in new issues?
from rum.
You are right. It is better to create new issues.
Close.
from rum.
Actually, the initial issue from NikolayS doesn't fixed. Reopen.
from rum.
So is it possible now to filter with @@ operator and ORDER BY some integer/int8 column and have only single index scan for that?
from rum.
Thanks:)
from rum.
Yes, it will be possible in soon :)
from rum.
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
@NikolayS , actually you can use the following query.
If you created index in the following way:
create index on tab1 using rum (tsv rum_tsvector_addon_ops, price)
with (attach=price, to=tsv);
you can execute the following query:
select ... from tab1 where tsv @@ ...
order by price <=> 10000::money limit 10;
It will use index scan. Some distance operator (for example, <=>) should be used to use index scan. Otherwise, bitmap scan will be used.
from rum.
Hi.
While I very much appreciate that using a distance-operator in ORDER BY works, doing so, instead of ordenary ORDER BY <column|epr> [ASC|DESC], seems awkward as it requires a magic-value higher or lower than any other value.
In my case I must use ORDER BY del.received_timestamp <=> '3000-01-01' :: TIMESTAMP
, which uses 3000 as I know I don't have any timestamps in the year 3000 in my dataset.
Will this be re-worked in future releases so one can write ORDER BY del.timestamp DESC
and having it use the index in the same manner as using a distance operator?
from rum.
Isn't this issue actually fixed now, using rum_tsvector_addon_ops?
from rum.
ok, thank you, but could you please elaborate how it's supposed to work?
[local]:5432 nikolay@test=# select version();
version
------------------------------------------------------------------------------------------
PostgreSQL 9.6.6 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit
(1 row)
[local]:5432 nikolay@test=# select * from pg_available_extensions where name = 'rum';
name | default_version | installed_version | comment
------+-----------------+-------------------+-------------------------
rum | 1.2 | 1.2 | RUM index access method
(1 row)
[local]:5432 nikolay@test=# create table rum(id int primary key, tsvector tsvector);
CREATE TABLE
Time: 140.727 ms
[local]:5432 nikolay@test=# insert into rum(id, tsvector) select i, to_tsvector('simple', 'test vector ' || i::text) from generate_series(1, 100000) _(i);
INSERT 0 100000
Time: 735.009 ms
[local]:5432 nikolay@test=# insert into rum(id, tsvector) select i, to_tsvector('simple', 'test cow ' || i::text) from generate_series(100001, 150000) _(i);
INSERT 0 50000
Time: 499.296 ms
[local]:5432 nikolay@test=# create index on rum using rum (tsvector rum_tsvector_addon_ops, id) with (attach=id, to=tsvector);
CREATE INDEX
Time: 1150.367 ms (00:01.150)
[local]:5432 nikolay@test=# explain analyze select * from rum where tsvector @@ plainto_tsquery('simple', 'cow') order by id desc nulls last limit 10;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=633.33..633.36 rows=10 width=48) (actual time=41.625..41.627 rows=10 loops=1)
-> Sort (cost=633.33..635.21 rows=750 width=48) (actual time=41.623..41.624 rows=10 loops=1)
Sort Key: id DESC NULLS LAST
Sort Method: top-N heapsort Memory: 25kB
-> Index Scan using rum_tsvector_id_idx on rum (cost=3.00..617.12 rows=750 width=48) (actual time=14.443..28.066 rows=50000 loops=1)
Index Cond: (tsvector @@ '''cow'''::tsquery)
Planning time: 0.253 ms
Execution time: 41.702 ms
(8 rows)
– I asked only for top 10 records, but rum idx scan takes all 50k records with word "cow" (rows=50000
) and then sorting happens.
Without nulls last
, it's the same (needed to drop PK since it preferred using it instead of RUM idx):
[local]:5432 nikolay@test=# alter table rum drop constraint rum_pkey;
ALTER TABLE
Time: 49.426 ms
[local]:5432 nikolay@test=# explain analyze select * from rum where tsvector @@ plainto_tsquery('simple', 'cow') order by id desc limit 10;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=3464.92..3464.94 rows=10 width=48) (actual time=40.989..40.993 rows=10 loops=1)
-> Sort (cost=3464.92..3589.82 rows=49960 width=48) (actual time=40.987..40.988 rows=10 loops=1)
Sort Key: id DESC
Sort Method: top-N heapsort Memory: 25kB
-> Index Scan using rum_tsvector_id_idx on rum (cost=3.00..2385.30 rows=49960 width=48) (actual time=14.310..27.581 rows=50000 loops=1)
Index Cond: (tsvector @@ '''cow'''::tsquery)
Planning time: 0.165 ms
Execution time: 41.044 ms
(8 rows)
Should it be so? Is it really different from what it was before?
from rum.
Oh. Understood :-)
[local]:5432 nikolay@test=# explain analyze select * from rum where tsvector @@ plainto_tsquery('simple', 'cow') order by id <=> 0 limit 10;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=3.00..3.53 rows=10 width=56) (actual time=18.212..18.221 rows=10 loops=1)
-> Index Scan using rum_tsvector_id_idx on rum (cost=3.00..2635.10 rows=49960 width=56) (actual time=18.210..18.218 rows=10 loops=1)
Index Cond: (tsvector @@ '''cow'''::tsquery)
Order By: (id <=> 0)
Planning time: 0.179 ms
Execution time: 18.315 ms
-- desc:
[local]:5432 nikolay@test=# explain analyze select * from rum where tsvector @@ plainto_tsquery('simple', 'cow') order by id <=> 10^30 limit 10;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=3714.72..3714.74 rows=10 width=56) (actual time=53.081..53.084 rows=10 loops=1)
-> Sort (cost=3714.72..3839.62 rows=49960 width=56) (actual time=53.080..53.082 rows=10 loops=1)
Sort Key: (((id)::double precision <=> '1e+30'::double precision))
Sort Method: top-N heapsort Memory: 26kB
-> Index Scan using rum_tsvector_id_idx on rum (cost=3.00..2635.10 rows=49960 width=56) (actual time=14.353..39.079 rows=50000 loops=1)
Index Cond: (tsvector @@ '''cow'''::tsquery)
Planning time: 0.155 ms
Execution time: 53.150 ms
(8 rows)
-- looks good!
from rum.
Oh. Understood :-)
Yep :)
from rum.
One more question. In my tests, 'asc' ordering (id <=> 0
) works significantly faster than 'desc' (id <=> 1000000
or id <=> 10^10
or id <=> 10^30
between which I didn't notice any difference). It's ~15-20ms vs 40-50ms.
Any ways to improve it somehow? (using different index definition or something)
from rum.
In your second query 10^30
is not int
but double
:
Sort Key: (((id)::double precision <=> '1e+30'::double precision))
Use maximum integer value instead.
from rum.
I suppose maximum value is 2147483647
from rum.
Okay, used 10^5, but it didn't help to eliminate the difference between "asc" and "desc":
[local]:5432 nikolay@test=# explain analyze select * from rum where tsvector @@ plainto_tsquery('simple', 'cow') order by id <=> 10^5 limit 10;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=3714.72..3714.74 rows=10 width=56) (actual time=53.174..53.178 rows=10 loops=1)
-> Sort (cost=3714.72..3839.62 rows=49960 width=56) (actual time=53.173..53.175 rows=10 loops=1)
Sort Key: (((id)::double precision <=> '100000'::double precision))
Sort Method: top-N heapsort Memory: 26kB
-> Index Scan using rum_tsvector_id_idx on rum (cost=3.00..2635.10 rows=49960 width=56) (actual time=14.427..39.331 rows=50000 loops=1)
Index Cond: (tsvector @@ '''cow'''::tsquery)
Planning time: 0.153 ms
Execution time: 53.231 ms
(8 rows)
Time: 53.958 ms
[local]:5432 nikolay@test=# explain analyze select * from rum where tsvector @@ plainto_tsquery('simple', 'cow') order by id <=> 0 limit 10;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=3.00..3.53 rows=10 width=56) (actual time=18.474..18.482 rows=10 loops=1)
-> Index Scan using rum_tsvector_id_idx on rum (cost=3.00..2635.10 rows=49960 width=56) (actual time=18.473..18.479 rows=10 loops=1)
Index Cond: (tsvector @@ '''cow'''::tsquery)
Order By: (id <=> 0)
Planning time: 0.139 ms
Execution time: 18.536 ms
(6 rows)
How can I get "asc" speed for "desc" (say, if I need desc in most cases)?
from rum.
oh, when I do order by id <=> 10^5
it takes 50000 records again. So basically, "inline sorting" doesn't work by some reason.
from rum.
Oh. This is my usual mistake – I shouldn't use 10^5
instead of constant 100000
.
But:
[local]:5432 nikolay@test=# explain analyze select * from rum where tsvector @@ plainto_tsquery('simple', 'cow') order by id <=> 1000000 limit 10;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=3.00..3.53 rows=10 width=56) (actual time=31.367..31.375 rows=10 loops=1)
-> Index Scan using rum_tsvector_id_idx on rum (cost=3.00..2635.10 rows=49960 width=56) (actual time=31.365..31.371 rows=10 loops=1)
Index Cond: (tsvector @@ '''cow'''::tsquery)
Order By: (id <=> 1000000)
Planning time: 0.133 ms
Execution time: 31.427 ms
(6 rows)
Time: 32.084 ms
[local]:5432 nikolay@test=# explain analyze select * from rum where tsvector @@ plainto_tsquery('simple', 'cow') order by id <=> 0 limit 10;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=3.00..3.53 rows=10 width=56) (actual time=18.329..18.338 rows=10 loops=1)
-> Index Scan using rum_tsvector_id_idx on rum (cost=3.00..2635.10 rows=49960 width=56) (actual time=18.328..18.335 rows=10 loops=1)
Index Cond: (tsvector @@ '''cow'''::tsquery)
Order By: (id <=> 0)
Planning time: 0.139 ms
Execution time: 18.393 ms
(6 rows)
-- "asc" is almost 2x faster than "desc" (18ms vs 31ms). Is it possible to have the faster "desc"?
from rum.
I understood what's happening. The exponentiation operator returns result in double or numeric type:
$ \do ^
List of operators
Schema | Name | Left arg type | Right arg type | Result type | Description
------------+------+------------------+------------------+------------------+----------------
pg_catalog | ^ | double precision | double precision | double precision | exponentiation
pg_catalog | ^ | numeric | numeric | numeric | exponentiation
So you need to cast the result (10^5)::int
:
$ explain (analyze) select * from rum where tsvector @@ 'cow'::tsquery order by id <=> (10^6)::int limit 10;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=12.00..13.43 rows=10 width=56) (actual time=21.027..21.031 rows=10 loops=1)
-> Index Scan using rum_tsvector_id_idx on rum (cost=12.00..7171.81 rows=50125 width=56) (actual time=21.024..21.028 rows=10 loops=1)
Index Cond: (tsvector @@ '''cow'''::tsquery)
Order By: (id <=> 1000000)
Planning time: 0.181 ms
Execution time: 21.274 ms
About desc
speed I can't tell anything useful for now. It seems that RUM
works on same size of data, but the query needs more operations to perform.
from rum.
Yes;
select pg_typeof(10^5);
┌──────────────────┐
│ pg_typeof │
├──────────────────┤
│ double precision │
└──────────────────┘
(1 row)
from rum.
Yeah, yeah, I always do that mistake. For years. Никогда такого не было и вот опять.
But what is more interesting/relevant here:
- how to speedup DESC-queries (I want them much more often than ASC – like
order by id desc
ororder by price desc
) - any plans to support statistics for RUM/rum_tsvector_addon_ops? Now estimations suck (
...rows=50125...) (actual ... rows=10...)
)
from rum.
Good questions, but don't hijack this issue. Start new separate issues for those.
from rum.
No-no, this is my issue and those questions are both belong to it for sure :))
Repo owners can move them to other places if they think it's better.
from rum.
I think nobody likes never-ending issues due to new stuff creaping in.
In the issue-list summary it seems like this issue is still an issue while in fact it is indeed closed/implemented. Being good citizens we should help keeping the issue-list clean:-)
Let's give the repo owners more time to code by helping them out?
from rum.
@andreak it's all offtopic and provocative.
Having all information in one single place regarding on particular topic can be very helpful and might save time. It's up to the repo owner how to manage issues – it depends on concrete process inside the particular dev team. Don't pretend that your practices are the only possible and right choice, it's not a good citizen's behavior.
Consider this matter as closed, leave these questions to repo owners and let's focus on tech stuff.
from rum.
My point was; let's keep this issue closed. Glad we agree on that:-)
from rum.
I created two issues: #35 and #36. Though I'm not sure that the first is an issue. You can continue the conversation there :).
from rum.
Related Issues (20)
- Querying 1.6 million records using RUM index takes 2 seconds HOT 1
- rum compile warnings on pg14.0 HOT 2
- New release with PG14 support HOT 2
- Ошибка: could not load library "/usr/pgsql-14/lib/rum.so" при выполнении create extension HOT 5
- rum_anyarray_addon_ops index not working HOT 1
- Is there a way to weight the rum_ts_score function?
- why the rum index not working HOT 9
- Build failure with PG15: src/rumsort.c:1316:38: error: too many arguments to function ‘LogicalTapeBackspace’ HOT 14
- ERROR: could not load library rum.so: undefined symbol: postgresql_sort__done_semaphore HOT 5
- Hello, may I ask why rum deleted the fast update function, what is the consideration?
- Can we compute two tsvectors like array op?
- New release with PG15 support? HOT 2
- warning on var totalCount compile on mac venture clang
- create rum index without "WITH" cause an error when select use “ORDER BY”
- In a query, `||` does not work when nested in `<->` HOT 3
- Why keyword order doesn't affect rankings? HOT 5
- Can I install it on windows ? HOT 4
- Feasibility of adding range operator for tsquery HOT 5
- Extension ready for Postgres 14? HOT 2
- [Bug] addInfo is (Datum) 0, which is expected to be not, coredump in func DatumGetByteaP HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rum.