> Date: Thu, 03 Feb 2005 21:41:52 -0500 > From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> > Subject: Proof-of-concept ARC removal patches Re: subject -- shouldn't it be "replacement" and _not_ "removal" of ARC? > Attached are two different variants of a patch to remove the ARC > cache algorithm in favor of variants of the "2Q" algorithm. > ... > In some desultory testing with pgbench, there was no significant > performance difference among the three algorithms, which leads me to > think that simplified 2Q might be the best bet (it certainly has the > smallest memory footprint). But it would be a good idea to do some > more measurements before believing that. I hope that Mark Wong can give > these a try on his setup soon. > ... > > Comments? Wouldn't it been much more usable and fair to be able to "load" any of those modules as I am, the user see fit? So, I could swap the algos on the fly whichever better suits me? That will also lay down ground suitable for easier performance testing between the modules should people write their own, new ones. I'd keep the ARC around and not remove as a proof-of-concept module as well. Whatever the status of the IBM's ARC patent may become, the US customers will simply not use the module. Researchers, however, will always be able to tell that their modules are better or worse by comparing them to ARC (or 2Q or whatever). > regards, tom lane -- Serguei A. Mokhov | /~\ The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | X Against HTML Montreal, Quebec, Canada | / \ Email!
Serguei Mokhov <mokhov(at)cs(dot)concordia(dot)ca> writes: > Re: subject -- shouldn't it be "replacement" and _not_ "removal" of ARC? Sure. > Wouldn't it been much more usable and fair to be able to "load" any of those > modules as I am, the user see fit? So, I could swap the algos on the fly > whichever better suits me? That will also lay down ground suitable for easier > performance testing between the modules should people write their own, new > ones. Fairness doesn't enter into it --- we have to get out from under the upcoming patent, whether you think that's fair or not. As for the other point, I already did the work needed to isolate this code into one file. Anyone who wants to experiment can do so by inserting different versions of freelist.c, which surely should be well within the ability of anyone competent to do such experiments. I have no interest in setting up some kind of hot-pluggable interface for this code: it doesn't look to me like the development, testing, or maintenance burden would be repaid. (As for on-the-fly changes, that's a complete non-starter because of the differing demands for shared memory. So at best you'd be able to change algorithms during postmaster restart, anyway.) If someone is able to show, using these patches, that there is a really significant difference between these algorithms, then I might reconsider that position. But for now my answer is that it's not worth the trouble. regards, tom lane