Re: ARC patent - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: ARC patent
Date
Msg-id 1105958412.14384.100.camel@localhost.localdomain
Whole thread Raw
In response to ARC patent  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2005-01-17 at 01:15 -0500, Tom Lane wrote:
> Neil Conway <neilc@samurai.com> writes:
> > FYI, IBM has applied for a patent on ARC (AFAICS the patent application
> > is still pending, although the USPTO site is a little hard to grok):
> 
> >
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040098541%22.PGNR.&OS=DN/20040098541&RS=DN/20040098541

On Mon, 2005-01-17 at 01:15 -0500, Tom Lane wrote:
> I fear we'll have to change or remove
> that code.

At very least, ARC should not be further mentioned in any press release
or beta history files until we resolve where we are. There'll be less
need for a retraction if the buffer strategy is not publicised.

The code separation of bufmgr.c and freelist.c means that changes can be
done later without too much of a problem. Any required changes can be
made under the covers without external recall-notices or such.

Well, considering the BufMgrLock problems, it was likely that some
changes would need to be be made to that algorithm anyway. 

ARC may be optimal in lab tests, but I'm beginning to think that it's
not optimal in multi-processing environments. It also takes no direct
account of the workload it is being asked to support, so ISTM that we
should be able to use workload hints, along the lines of
StrategyHintVacuum, to get a more responsive algorithm suited
specifically to PostgreSQL - which would be harder to claim rights on.

-- 
Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ARC patent
Next
From: Nicolai Tufar
Date:
Subject: Re: [PATCHES] Latest Turkish translation updates