Re: Fast insertion indexes: why no developments - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fast insertion indexes: why no developments
Date
Msg-id 1676.1383059805@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fast insertion indexes: why no developments  (Leonardo Francalanci <m_lists@yahoo.it>)
Responses Re: Fast insertion indexes: why no developments  (Leonardo Francalanci <m_lists@yahoo.it>)
Re: Fast insertion indexes: why no developments  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
Leonardo Francalanci <m_lists@yahoo.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



pgsql-hackers by date:

Previous
From: "ktm@rice.edu"
Date:
Subject: Re: Fast insertion indexes: why no developments
Next
From: Kohei KaiGai
Date:
Subject: Re: How should row-security affects ON UPDATE RESTRICT / CASCADE ?