Re: Add free-behind capability for large sequential scans - Mailing list pgsql-hackers

From Neil Padgett
Subject Re: Add free-behind capability for large sequential scans
Date
Msg-id 1013622284.1571.64.camel@shoebox
Whole thread Raw
In response to Re: Add free-behind capability for large sequential scans  (Amit Kumar Khare <skamit2000@yahoo.com>)
Responses Re: Add free-behind capability for large sequential scans
List 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@redhat.com
2323 Yonge Street, Suite #300, 
Toronto, ON  M4P 2C9



pgsql-hackers by date:

Previous
From: Kovacs Zoltan
Date:
Subject: Re: alter table drop column status
Next
From: Tom Lane
Date:
Subject: Re: Odd statistics behaviour in 7.2