Hello everyone!
Unfortunately, I faced the use case with RUM index, in which my patch
produced
enormously large time overhead (queries execution time is about 2 or 3 times
slower). Only now I finally managed to limit this overhead by 20% or
even make
it statistically insignificant on my HDD. N
between performance overheads
and compression rate on RUM. On my HDD PostgreSQL works even 10%
faster for some RUM workloads because of reducing size of generic
WAL to be written.
Oleg Ivanov
Postgres Professional
The Russian PostgreSQL Company
diff --git a/src/backend/access/transam/generic_xlog.c b
On 12/12/2017 04:33 PM, Oleg Bartunov wrote:
On Mon, Dec 11, 2017 at 11:11 PM, Nikolay Samokhvalov
wrote:
Very interesting read: https://arxiv.org/abs/1712.01208
HN discussion: https://news.ycombinator.com/item?id=15894896
Some of the comments (from Twitter
https://twitter.com/schrockn/status
s.
No guarantees are provided (I don't think it is even possible), besides
the guarantee that if the error of the neural network prediction is more
than the error of B-tree prediction, B-tree will be used: "Note, that
hybrid indexes allow us to bound the worst case performance of le
