Re: Hash Indexes

<p dir="ltr">On 30-Sep-2016 10:26 PM, "Peter Geoghegan" <<a href="mailto:pg@heroku.com">pg@heroku.com</a>>
wrote:<br/> ><br /> > On Fri, Sep 30, 2016 at 4:46 PM, Robert Haas <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br /> > > I would just be very
disappointedif, after the amount of work that<br /> > > Amit and others have put into this project, the code gets
rejected<br/> > > because somebody thinks a different project would have been more worth<br /> > >
doing.<br/> ><br /> > I wouldn't presume to tell anyone else how to spend their time, and am<br /> > not
concernedabout this patch making the hash index code any less<br /> > useful from the user's perspective. If this is
howwe remove the wart<br /> > of hash indexes not being WAL-logged, that's fine by me. I'm trying to<br /> > be
helpful.<br/> ><p dir="ltr">If that is fine, then I think we should do that.  I want to bring it to your notice that
wehave already seen and reported that with proposed set of patches, hash indexes are good bit faster than btree, so
thatadds additional value in making them WAL-logged.<p dir="ltr">> > As Tom said upthread: $But to kick the hash
AMas such to the<br /> > > curb is to say<br /> > > "sorry, there will never be O(1) index lookups in
Postgres".$ I<br /> > > think that's correct and a sufficiently-good reason to pursue this<br /> > > work,
regardlessof the merits (or lack of merits) of hash-over-btree.<br /> ><br /> > I don't think that "O(1) index
lookups"is a useful guarantee with a<br /> > very expensive constant factor.<p dir="ltr">The constant factor doesn't
playmuch role when data doesn't have duplicates or have lesser duplicates.<p dir="ltr"> Amit seemed to agree with this,
since<br/> > he spoke of the importance of both theoretical performance benefits<br /> > and practically
realizableperformance benefits.<br /> ><p dir="ltr">No, I don't agree with that rather I think hash indexes are
theoreticallyfaster than btree and we have seen that practically as well for quite a few cases (for read workloads -
whenused with unique data and also in nest loops).<p dir="ltr">With Regards,<br /> Amit Kapila <br />