Re: ARC patent - Mailing list pgsql-hackers

From Dann Corbit
Subject Re: ARC patent
Date
Msg-id D425483C2C5C9F49B5B7A41F89441547055835@postal.corporate.connx.com
Whole thread Raw
In response to ARC patent  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
How about LRU + "learning" --> something like the optimizer?

It might be nice also to be able to pin things in memory.

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Mark Kirkwood
Sent: Thursday, January 20, 2005 6:55 PM
To: Simon Riggs
Cc: Neil Conway; Tom Lane; Joshua D. Drake; Jeff Davis; pgsql-hackers
Subject: Re: [HACKERS] ARC patent

Simon Riggs wrote:
> On Thu, 2005-01-20 at 23:17 +1100, Neil Conway wrote:
> (snippage)
>>For 8.0.x, I wonder
>>if it would be better to just replace ARC with LRU.
>>
>> Sequential scans will still flood
>>the cache, but I don't view that as an enormous problem.
>
> Agree with everything apart from the idea that seq scan flooding isn't
> an issue. I definitely think it is.
>
Is it feasible to consider LRU + a free-behind or seqscan hint type of
replacement policy?

regards

Mark


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if
your     joining column's datatypes do not match


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: ARC patent
Next
From: Euler Taveira de Oliveira
Date:
Subject: Re: Translations at pgfoundry (was Re: [PATCHES] Latest Turkish translation updates)