| From: | Leonardo Francalanci <m_lists(at)yahoo(dot)it> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fast insertion indexes: why no developments |
| Date: | 2013-10-29 15:53:40 |
| Message-ID: | 1383062020.34721.YahooMailNeo@web172603.mail.ir2.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> They should, in theory, be faster than btrees -- O(1) not O(log N) page
> fetches per lookup. In practice they don't seem to be faster, and
> nobody's bothered to find out exactly why. Again, this isn't a terribly
> encouraging precedent for implementing some other index type that's
> supposed to (sometimes) be faster than btrees.
Yes, I understand. Which is also why I was curious to know if the "claims" those papers (and the databases using them) make were real...
Thank you everybody for your replies.
Leonardo
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Johnston | 2013-10-29 15:59:52 | Re: How should row-security affects ON UPDATE RESTRICT / CASCADE ? |
| Previous Message | Leonardo Francalanci | 2013-10-29 15:49:43 | Re: Fast insertion indexes: why no developments |