Re: Add free-behind capability for large sequential scans

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

In response to

Responses

Browse pgsql-hackers by date

  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