| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Stefan Keller <sfkeller(at)gmail(dot)com> |
| Cc: | Oleg Ivanov <o(dot)ivanov(at)postgrespro(dot)ru>, obartunov(at)gmail(dot)com, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ML-based indexing ("The Case for Learned Index Structures", a paper from Google) |
| Date: | 2021-04-20 18:18:12 |
| Message-ID: | DEDD8D37-B39B-4624-BF47-4F8C62A2C22E@yandex-team.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 20 апр. 2021 г., в 22:56, Stefan Keller <sfkeller(at)gmail(dot)com> написал(а):
>
> Are there any advances in a learned index for PostgreSQL?
BTW take a look into PGM [0]. I'm slowly working on implementing it.
I think it is kind of straightforward to implement it as extension.
I've started from forking B-tree[1]. I've removed support of anything that is not int4.
Then I plan to remove opclass\comparator abstraction layer.
And then add interpolation search over the page before binsearch.
And, maybe, add delta compression. Or, perhaps, fix WAL, which is completely broken. Or add some vectorisation.
The concurrency is from a regular B-tree, of cause.
This is my pet project. So, unsurprisingly, I've done only parts of big plan :) I would appreciate any help.
Thanks!
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-04-20 18:23:08 | Re: when the startup process doesn't |
| Previous Message | Ondřej Žižka | 2021-04-20 18:05:31 | Re: Synchronous commit behavior during network outage |