From: | Neil Padgett <npadgett(at)redhat(dot)com> |
---|---|
To: | Amit Kumar Khare <skamit2000(at)yahoo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add free-behind capability for large sequential scans |
Date: | 2002-02-13 17:44:43 |
Message-ID: | 1013622284.1571.64.camel@shoebox |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2002-02-13 at 03:11, Amit Kumar Khare wrote:
[clip]
> The problem is same here(Please correct me if I am
> wrong) what they talk of. They have recognized like
> Professor Stonebraker certain Access patterns (like
> clustered sequential, looping sequential etc.)in
> Database Systems and recomend a "Composite page
> replacement policy". But how the buffer manager will
> know what policy has to be applied? They say "When a
> file is opened, its associated locality set size and
> REPLACEMENT POLICY are given to the buffer manager".
This is indeed one possibility. However, the problem, as pointed out in
[1] is that in multi-user situations, getting sane results from query
execution analysis is hard. The real problem is -- how do you handle the
interaction of multiple simultaneous queries with the buffer pool?
This problem led for a search for a new approach, which in turn led to
simpler algorithms, like LRU-K [1] and 2Q [2]. I'd much rather we pursue
algorithms of this type.
Neil
[1] E.H. O'Neil, P.E. O'Neil, and G. Weikum. The LRU-K page replacement
algorithm for database disk buffering. _In Proceeedings of the 1993 ACM
Sigmod International Conference on Management of Data_, pages 297-306,
1993.
[2] Theodore Johnson and Dennis Shasha. 2Q: A Low Overhead High
Performace Buffer Amanagement Replacement algorithm. In _Proceedings of
the 20th VLDB Conference_, pages 439-450, 1994.
--
Neil Padgett
Red Hat Canada Ltd. E-Mail: npadgett(at)redhat(dot)com
2323 Yonge Street, Suite #300,
Toronto, ON M4P 2C9
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-02-13 18:02:36 | Re: Odd statistics behaviour in 7.2 |
Previous Message | Kovacs Zoltan | 2002-02-13 17:23:10 | Re: alter table drop column status |