On Thu, Apr 14, 2022 at 1:46 PM David Rowley <dgrowle...@gmail.com> wrote: > > On Wed, 13 Apr 2022 at 23:19, John Naylor <john.nay...@enterprisedb.com> > wrote: > > More broadly than the regression, Thomas' is very often the fastest of > > all, at the cost of more binary size. David's is occasionally slower > > than v15 or v15 with revert, but much of that is a slight difference > > and some is probably noise.
To add to my summary of results - the v15 code, with and without extra patches, seems slightly worse on B-tree index creation for very low cardinality keys, but that's not an index that's going to be useful (and therefore common) so that's a good tradeoff in my view. The regression David found is more concerning. > Just to get an opinion from some other hardware, I've run your test > script on my AMD 3990x machine. Thanks for that. I only see 4 non-Btree measurements in your results that are larger than v15-revert, versus 8 in mine (Comet Lake). And overall, most of those seem within the noise level. > My opinion here is that the best thing we can learn from both of our > results is, do the patches fix the regression? I'd say the answer is yes for both. > I don't believe it should be about if adding the additional > specializations performs better than skipping the tie break function > call. I think it's pretty obvious that the specializations will be > faster. I think if it was decided that v16 would be the version where > more work should be done to decide on what should be specialized and > what shouldn't be, then we shouldn't let this regression force our > hand to make that choice now. It'll be pretty hard to remove any > specializations once they've been in a released version of Postgres. I agree that a narrow fix is preferable. I'll take a closer look at your patch soon. -- John Naylor EDB: http://www.enterprisedb.com
