Dmitry Dolgov wrote
>> On Tue, Aug 04, 2020 at 11:22:13AM +0300, Konstantin Knizhnik wrote:
>>
>> Then I think about implementing ideas of LSM using standard Postgres
>> nbtree.
>>
>> We need two indexes: one small for fast inserts and another - big
>> (main) index. This top index is small enough t
On 09.08.2020 04:53, Alexander Korotkov wrote:
I realize that it is not true LSM.
But still I wan to notice that it is able to provide ~10 times increase
of insert speed when size of index is comparable with RAM size.
And "true LSM" from RocksDB shows similar results.
It's very far from bein
On Sat, Aug 8, 2020 at 11:49 PM Konstantin Knizhnik
wrote:
> On 08.08.2020 21:18, Alexander Korotkov wrote:
> > On Sat, Aug 8, 2020 at 5:07 PM Konstantin Knizhnik
> > wrote:
> >> I agree with your that loosing sequential order of B-Tree pages may have
> >> negative impact on performance.
> >> But
On 08.08.2020 21:18, Alexander Korotkov wrote:
On Sat, Aug 8, 2020 at 5:07 PM Konstantin Knizhnik
wrote:
I agree with your that loosing sequential order of B-Tree pages may have
negative impact on performance.
But it first of all critical for order-by and range queries, when we
should traver
On Sat, Aug 8, 2020 at 5:07 PM Konstantin Knizhnik
wrote:
> I agree with your that loosing sequential order of B-Tree pages may have
> negative impact on performance.
> But it first of all critical for order-by and range queries, when we
> should traverse several subsequent leave pages.
> It is le
On 07.08.2020 15:31, Alexander Korotkov wrote:
ср, 5 авг. 2020 г., 09:13 Konstantin Knizhnik :
Concerning degrade of basic index - B-Tree itself is balanced tree. Yes,
insertion of random keys can cause split of B-Tree page.
In the worst case half of B-Tree page will be empty. So B-Tree size
ср, 5 авг. 2020 г., 09:13 Konstantin Knizhnik :
> Concerning degrade of basic index - B-Tree itself is balanced tree. Yes,
> insertion of random keys can cause split of B-Tree page.
> In the worst case half of B-Tree page will be empty. So B-Tree size will
> be two times larger than ideal tree.
> I
> On Tue, Aug 04, 2020 at 11:22:13AM +0300, Konstantin Knizhnik wrote:
>
> Then I think about implementing ideas of LSM using standard Postgres
> nbtree.
>
> We need two indexes: one small for fast inserts and another - big
> (main) index. This top index is small enough to fit in memory so
> insert
On 04.08.2020 20:44, Tomas Vondra wrote:
IMO the 6x difference is rather misleading, as it very much depends on
the duration of the benchmark and how much data it ends up with. I think
it's better to test 'stable states' i.e. with small data set that does
not exceed RAM during the whole test,
On 05.08.2020 02:59, Alexander Korotkov wrote:
The things you're writing makes me uneasy. I initially understood
lsm3 as a quick and dirty prototype, while you're probably keeping
some design in your mind (for instance, original design of LSM).
However, your message makes me think you're try
On Tue, Aug 4, 2020 at 8:24 AM Alexander Korotkov wrote:
> So, in my point of view LSM as an index AM is far not a full power LSM
> for PostgreSQL, but it's still useful. Large insert-only tables can
> benefit from LSM. Large tables with many indexes could also benefit,
> because non-HOT updates
On Tue, Aug 4, 2020 at 7:56 PM Konstantin Knizhnik
wrote:
> I do not understand why do we need multiple indexes.
> We need one "hot" index which fits in memory to perform fast inserts.
> But it should not be too small to be able to accumulate substantial
> amount of records to provide efficient bu
On 04.08.2020 20:44, Tomas Vondra wrote:
Unique indexes are not supported now.
And I do not see some acceptable solution here.
If we will have to check presence of duplicate at the time of insert
then it will eliminate all advantages of LSM approach.
And if we postpone to the moment of merge
On Tue, Aug 04, 2020 at 08:18:01PM +0300, Konstantin Knizhnik wrote:
On 04.08.2020 18:11, Tomas Vondra wrote:
On Tue, Aug 04, 2020 at 11:22:13AM +0300, Konstantin Knizhnik wrote:
Hi hackers,
I want to share results of my last research of implementing LSM
index in Postgres.
Most of modern da
On 04.08.2020 18:18, Stephen Frost wrote:
Independently while considering this, I don't think the issues around
how to deal with unique btrees properly has really been considered- you
certainly can't stop your search on the first tuple you find even if the
index is unique, since the "unique"
On 04.08.2020 18:11, Tomas Vondra wrote:
On Tue, Aug 04, 2020 at 11:22:13AM +0300, Konstantin Knizhnik wrote:
Hi hackers,
I want to share results of my last research of implementing LSM index
in Postgres.
Most of modern databases (RocksDB, MongoDB, Tarantool,...) are using
LSM tree instead
On 04.08.2020 18:04, Alexander Korotkov wrote:
Hi!
On Tue, Aug 4, 2020 at 11:22 AM Konstantin Knizhnik
wrote:
I want to share results of my last research of implementing LSM index in
Postgres.
Most of modern databases (RocksDB, MongoDB, Tarantool,...) are using LSM tree
instead of classic
On Tue, Aug 4, 2020 at 6:11 PM Tomas Vondra
wrote:
> On Tue, Aug 04, 2020 at 11:22:13AM +0300, Konstantin Knizhnik wrote:
> >Hi hackers,
> >
> >I want to share results of my last research of implementing LSM index
> >in Postgres.
> >Most of modern databases (RocksDB, MongoDB, Tarantool,...) are us
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Tue, Aug 04, 2020 at 11:22:13AM +0300, Konstantin Knizhnik wrote:
> >two top indexes used in cyclic way and one main index. When top index
> >reaches some threshold value
> >we initiate merge with main index, done by bgworker and
On Tue, Aug 04, 2020 at 11:22:13AM +0300, Konstantin Knizhnik wrote:
Hi hackers,
I want to share results of my last research of implementing LSM index
in Postgres.
Most of modern databases (RocksDB, MongoDB, Tarantool,...) are using
LSM tree instead of classical B-Tree.
I was under the imp
Hi!
On Tue, Aug 4, 2020 at 11:22 AM Konstantin Knizhnik
wrote:
> I want to share results of my last research of implementing LSM index in
> Postgres.
> Most of modern databases (RocksDB, MongoDB, Tarantool,...) are using LSM tree
> instead of classical B-Tree.
I wouldn't say it that way. I wo
Hi hackers,
I want to share results of my last research of implementing LSM index in
Postgres.
Most of modern databases (RocksDB, MongoDB, Tarantool,...) are using LSM
tree instead of classical B-Tree.
From one side, capacity of RAM at modern servers allows to keep the
whole database in memo
22 matches
Mail list logo
