Title: RE: [HACKERS] Escaping the ARC patent
Just an idle thought, but each connection to the DB could add a fixed
amount to some queueing parameter. The amount added to be set
per backend,
and the client could use a SET variable to adjust the
standard amount for
it's own backend
Bruce Momjian pgman@candle.pha.pa.us writes:
So are you saying you are making T1, T2, B1, and B2 a fixed percentage
of the buffer cache rather than making them adjust over time?
B2 goes away entirely (if we keep four lists we violate claim 45) and
the other lists become fixed length, yes.
We
On Fri, Feb 04, 2005 at 11:27:40AM -0500, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
So are you saying you are making T1, T2, B1, and B2 a fixed percentage
of the buffer cache rather than making them adjust over time?
B2 goes away entirely (if we keep four lists we
Jim C. Nasby [EMAIL PROTECTED] writes:
I think it would be useful to have a means to adjust the queue sizes
dynamically from a database connection. If the optimum queue sizes
depend on the workload this would allow things like batch processes to
tweak the queue sizes for better performance
At 09:02 AM 5/02/2005, Tom Lane wrote:
That strikes me as a bad idea --- what will cause the queue size to
revert to normal, if the batch process fails before resetting it?
Just an idle thought, but each connection to the DB could add a fixed
amount to some queueing parameter. The amount added to
I've been doing a bit of research on $subj, and coming to the conclusion
that the ARC patent is a lot narrower than it might appear. In fact
most of the parts of the algorithm that we actually want have prior art.
I looked in particular at Johnson and Shasha's well-known 2Q paper,
published in
I'm familiar with the 2Q algorithm. I also remember seeing, I believe,
a public domain 2Q implementation floating around somewhere.
Tom Lane wrote:
I've been doing a bit of research on $subj, and coming to the conclusion
that the ARC patent is a lot narrower than it might appear. In fact
most
Jonah H. Harris [EMAIL PROTECTED] writes:
I'm familiar with the 2Q algorithm. I also remember seeing, I believe,
a public domain 2Q implementation floating around somewhere.
No doubt, but I think the more conservative way to get there is to
proceed by trimming down the working code we already
I'll dive into my bookmarks and see if I can find it.
Tom Lane wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
I'm familiar with the 2Q algorithm. I also remember seeing, I believe,
a public domain 2Q implementation floating around somewhere.
No doubt, but I think the more conservative
Tom Lane wrote
I've been doing a bit of research on $subj, and coming to the
conclusion
that the ARC patent is a lot narrower than it might appear. In fact
most of the parts of the algorithm that we actually want have
prior art.
Yes, it appears that way to me also.
The 2Q paper proposes
I found the reference I had seen. The engine was the Multicache
Simulation Environment written in C++. I can't find the code to it
anymore but I've contacted the author for a copy.
Jonah H. Harris wrote:
I'll dive into my bookmarks and see if I can find it.
Tom Lane wrote:
Jonah H. Harris
Tom Lane wrote:
Given the prior art, the critical word in this sentence is adaptively;
take that out and you have nothing that wasn't published long before.
If we remove the adaptivity --- ie, just use a fixed division of list
sizes --- we escape claim 1 and all the other claims that depend on
12 matches
Mail list logo
