On Mon, Sep 19, 2016 at 11:20 AM, Mark Kirkwood <mark.kirkwood@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.