From: | Leonardo Francalanci <m_lists(at)yahoo(dot)it> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Fast insertion indexes: why no developments |
Date: | 2013-10-29 07:53:42 |
Message-ID: | 1383033222.73186.YahooMailNeo@web172602.mail.ir2.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I don't see much interest in insert-efficient indexes. These are the ones I've found:
- LSM-tree (used by Cassandra and SQLite4?)
- Y-Tree (http://www.bossconsulting.com/oracle_dba/white_papers/DW%20in%20oracle/P23%20(ytree%20index%20structure%20for%20DWs).pdf )
- Fractal indexes (TokuDB, patented)
While I understand that b*trees are still the best compromise in insertion/search speed, disk size, concurrency, and more in general in OLTP workloads, they are useless when it comes to insertion in big data tables (>50M rows) of random values (not ordered values).
I would like to know if the lack of development in this area (not only in Postgresql, but in databases in general) is due to:
1) complex implementation
2) poor search performance
3) poor concurrency performance
4) not interesting for most users
5) something else???
I thought this was going to change due to the fast-insertion speeds needs of "Social Applications", but only TokuDB seems to be the only "successful" player in the area (I don't know how much of it is due to good marketing). Most other DB technology claims faster insertion speed (MongoDB and the like...) but in the end they rely on the old b*tree + sharding instead of using different indexing mechanisms (with the exception of Cassandra).
Thank you in advance
Leonardo
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2013-10-29 08:09:24 | How should row-security affects ON UPDATE RESTRICT / CASCADE ? |
Previous Message | Naoya Anzai | 2013-10-29 07:16:58 | Re: PostgreSQL Service on Windows does not start. ~ "is not a valid Win32 application" |