Re: Updated RUM-index and support for bigint as part of index - Mailing list pgsql-general

From Andreas Joseph Krogh
Subject Re: Updated RUM-index and support for bigint as part of index
Date
Msg-id VisenaEmail.71.dab4e187c9a7574d.15663b7dec4@tc7-visena
Whole thread Raw
In response to Re: Updated RUM-index and support for bigint as part of index  (Artur Zakirov <a.zakirov@postgrespro.ru>)
List pgsql-general
På lørdag 06. august 2016 kl. 20:54:32, skrev Artur Zakirov <a.zakirov@postgrespro.ru>:
Hello,
 
2016-08-02 21:08 GMT+03:00 Andreas Joseph Krogh <andreas@visena.com>
The ORDER BY part seems strange; It seems one has to find a value "lower than any other value" to use as a kind of base, why is this necessary? It also seems that in order to be able to sort DESC one has to provide a timestamp value "higher than any other value", is this correct?
 
It would be great if the docs explained this.
 
We will write more detailed documentation for RUM.
 
Great!
 
 
I really miss the opportunity to include a BIGINT as part of the index, so that the WHERE-clause could be like this:
 
WHERE del.fts_all @@ to_tsquery('simple''andreas&kr'AND del.folder_id IN (1,2,3)
 
Having this would be perfect for my use-case searching in email in folders, sorted by received_date, and having it use ONE index.
 
Will this be supported?

We have a plan to use generic types to able to include bigint, timestamp and other types as part of index.
 
Does this eliminate the need for a btree_rum equivalent of btree_gin, being that the RUM-index will handle all "btree-able" datatypes?
 
 
But I cant tell date of it.
 
I understand.
Do you think it will be done by the time 9.6 is released?
 
Thanks.
 
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
 
Attachment

pgsql-general by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: Updated RUM-index and support for bigint as part of index
Next
From: Philippe Girolami
Date:
Subject: Re: Should a DB vacuum use up a lot of space ?