Re: Fast insertion indexes: why no developments

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Leonardo Francalanci <m_lists(at)yahoo(dot)it>
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:16:45
Message-ID: 1676.1383059805@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Leonardo Francalanci <m_lists(at)yahoo(dot)it> writes:
>> Before getting too excited about some new academic index type, it's worth
>> noting the sad state in which hash indexes have languished for years.

> Aren't hash indexes in a poor state because they are not faster than btree in every condition?

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.

None of this is meant to discourage you from trying to write an index
type if you have the time and motivation to pursue it. Just trying to
answer your question as to why nobody's done it already.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2013-10-29 15:21:39 Re: How should row-security affects ON UPDATE RESTRICT / CASCADE ?
Previous Message ktm@rice.edu 2013-10-29 15:13:56 Re: Fast insertion indexes: why no developments