On Sun, Sep 18, 2016 at 11:44 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Sep 19, 2016 at 11:20 AM, Mark Kirkwood > <mark.kirkw...@catalyst.net.nz> wrote: > > On 17/09/16 06:38, Andres Freund wrote: > > > > While I see the point of what you are saying here, I recall all previous > > discussions about has indexes tended to go a bit like this: > > > > - until WAL logging of hash indexes is written it is not worthwhile > trying > > to make improvements to them > > - WAL logging will be a lot of work, patches 1st please > > > > Now someone has done that work, and we seem to be objecting that because > > they are not improved then the patches are (maybe) not worthwhile. > > > +1 > > I think saying hash indexes are not improved after proposed set of > patches is an understatement. The read performance has improved by > more than 80% as compare to HEAD [1] (refer data in Mithun's mail). > Also, tests by Mithun and Jesper has indicated that in multiple > workloads, they are better than BTREE by 30~60% (in fact Jesper > mentioned that he is seeing 40~60% benefit on production database, > Jesper correct me if I am wrong.). I agree that when index column is > updated they are much worse than btree as of now, Has anyone tested that with the relcache patch applied? I would expect that to improve things by a lot (compared to hash-HEAD, not necessarily compared to btree-HEAD), but if I am following the emails correctly, that has not been done. > but no work has been > done improve it and I am sure that it can be improved for those cases > as well. > > In general, I thought the tests done till now are sufficient to prove > the importance of work, but if still Andres and others have doubt and > they want to test some specific cases, then sure we can do more > performance benchmarking. > I think that a precursor to WAL is enough to justify it even if the verified performance improvements were not impressive. But they are pretty impressive, at least for some situations. Cheers, Jeff
