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 it.
>
> The only other claim that isn't dependent on claim 1 or a restatement of
> it is
>
> 45. A method for adaptively managing pages in a memory, comprising:
> defining a cache memory; defining a cache directory; organizing the
> cache directory into fours disjoint lists of pages: list T1, list T2,
> list B1, and list B2; and wherein the cache memory contains pages that
> are members of any of the list T1 or the list T2.
>
> So if we use non-variable sizes of T1/T2 and don't use the four-way
> list structure to manage remembrance of pages-formerly-in-cache,
> we escape the patent. But we still have scan resistance, which is the
> main thing that ARC was going to buy us. Pages that are scanned only
> once don't get out of A1 and so aren't able to swamp out pages
> referenced multiple times.

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?

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 be set per backend,
and the client could use a SET variable to adjust the standard amount for
it's own backend. When the client dies/disconnects, the queueing parameter
(whatever it is) would be reduced appropriately.


>

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp.mit.edu:11371 |/


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

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 violate claim 45) and
> the other lists become fixed length, yes.
>
> We could also contemplate making them variable length according to some
> other set of rules than ARC's, but then you get into having to parse the
> other sixty-odd claims of the patent and decide what is a "different
> enough" rule.
>
> At the moment I'm not seeing evidence that a variable policy beats a
> fixed policy anyway. Unless someone comes up with a benchmark showing a
> substantial advantage for ARC over 2Q, I think we should just declare
> victory over this problem. We have plenty of other tasks on our plates.

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 when they're running. It
would also facilitate performing the testing you mention.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

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 could also contemplate making them variable length according to some
other set of rules than ARC's, but then you get into having to parse the
other sixty-odd claims of the patent and decide what is a "different
enough" rule.

At the moment I'm not seeing evidence that a variable policy beats a
fixed policy anyway. Unless someone comes up with a benchmark showing a
substantial advantage for ARC over 2Q, I think we should just declare
victory over this problem. We have plenty of other tasks on our plates.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"Jim C. Nasby" <decibel@decibel.org> 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 when they're running.

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?

In any case, the only mechanism we have available for such things is
modifying postgresql.conf and then SIGHUPping the postmaster; there is
no other way to adjust a parameter that all backends must see as having
the same value. So even if we invent a GUC parameter for this, it's not
going to be something your batch process can lightly fool around with.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org