akorotkov

7 ms·

31.
by akorotkov 3y ago
Right now OrioleDB is an extension, which comes with PostgreSQL core patch. The mid-term goal for OrioleDB is to become a pure extension. The long-term goal is to make OrioleDB part of PostgreSQL core.
32.
PostgreSQL: No More Vacuum, No More Bloat(orioledb.com)
63 points by akorotkov 3y ago|4 comments
33.
by akorotkov 3y ago
Ok. I have to also mentions that none of the issues I've mentioned are consequences of in-memory nature of index. Both are issues of implementation.
34.
by akorotkov 3y ago
This blog post makes me uneasy. The pg_embedding code on github gives impression of PoC, while blog post creates impression that pg_embedding is ready for use. If we consider pg_embedding ready for use, why don't you compare with pgvec
35.
When Hell Freezes Over?(orioledb.com)
1 points by akorotkov 3y ago|1 comments
36.
by akorotkov 3y ago
How to stop the exhausting data freezing in PostgreSQL?
37.
by akorotkov 5y ago
Feel free to contact me at alexander@orioledb.com
38.
by akorotkov 5y ago
Please, see this thread of comments. https://news.ycombinator.com/item?id=30466322
39.
by akorotkov 5y ago
From my point of view, PostgreSQL development is quite conservative. Every small change may become a subject of heated debates, nothing to say about big changes. This approach to the development have advantages and disadvantages. But if we
40.
by akorotkov 5y ago
PostgreSQL 32-bit transaction identifiers are cycled in a ring. This is why PostgreSQL needs to "freeze" old transaction identifiers before they could start being identified as future. This routine is "vacuum freeze" and
41.
by akorotkov 5y ago
Additionally OrioleDB fundamentally changes design of buffer management and improves the vertical scalability a lot. https://www.slideshare.net/AlexanderKorotkov/solving-postgre... Also, I have to mention that zheap de
42.
by akorotkov 5y ago
> That has its own set of tradeoffs - if you're running a long transaction with higher level of serialization, the database has to look for old data in the undo segment which is not only likely vastly slower than normal table, but m
43.
by akorotkov 5y ago
There is not exactly a documentation. But there you can see that commits after "Stamp 14.2." are extendability patches. Commit messages briefly describe the changes. https://github.com/orioledb/postgres/c
44.
by akorotkov 5y ago
Hi! My name is Alexander Korotkov, I'm founder of OrioleDB. Thank you for your feedback and support. Please, write me at alexander@orioledb.com Thank you!
45.
by akorotkov 5y ago
I mean major releases. So, targeting 17.0.
46.
by akorotkov 5y ago
Right. The idea of active-active OrioleDB multimaster is to apply changes locally and in parallel send it to the leader. Then sync on commit and ensure there is no conflicts. The design document will be published later.
47.
by akorotkov 5y ago
Right, no more vacuums. And within typical workloads there should be no bloat.
48.
by akorotkov 5y ago
Yes, that's it. 1. The first goal is to become a pure extension. That should be done in 2-3 PostgreSQL release cycles. 2. The long term goal is to become a part of PostgreSQL.
49.
PostgreSQL 14: Substantion Change to Fulltext Query Parsing(akorotkov.github.io)
1 points by akorotkov 5y ago|0 comments
50.
Rainbow your psql output in honor of IDAHOT day(akorotkov.github.io)
1 points by akorotkov 5y ago|0 comments
51.
Jsonpath: ** Operator and Lax Mode Are't Meant to Be Together(akorotkov.github.io)
1 points by akorotkov 5y ago|0 comments