Re: ARC patent

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: ARC patent
Дата
Msg-id 1105958412.14384.100.camel@localhost.localdomain
обсуждение исходный текст
Ответ на ARC patent  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ARC patent
Следующее
От: Nicolai Tufar
Дата:
Сообщение: Re: [PATCHES] Latest Turkish translation updates