Thread: Re: [pgsql-patches] Proof-of-concept ARC removal patches

> Date: Thu, 03 Feb 2005 21:41:52 -0500
> From: Tom Lane <tgl@sss.pgh.pa.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@cs.concordia.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