Tom,
On 4/9/06 9:27 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> 2. There are some low-level assumptions that no one reads in pages of
> a relation without having some kind of lock on the relation (consider
> eg the case where the relation is being dropped). A bgwriter-like
> process wouldn't be able to hold lmgr locks, and we wouldn't really want
> it to be thrashing the lmgr shared data structures for each read anyway.
> So you'd have to design some interlock to guarantee that no backend
> abandons a query (and releases its own lmgr locks) while an async read
> request it made is still pending. Ugh.
Does this lead us right back to planning for the appropriate amount of
readahead at plan time? We could consider a "page range" lock at that point
instead of locking each individual page.
It seems that the planner might have enough information to identify the
times when this approach would be beneficial (low selectivity aggregate,
etc), and to allocate sufficient resources to accommodate the overlap. The
planner specific knowledge would be the main reason this would work better
than the OS built-in dynamic readahead algorithms.
- Luke
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
