From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Myron Scott" <lister(at)sacadia(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Support Parallel Query Execution in Executor |
Date: | 2006-04-09 20:59:40 |
Message-ID: | C05EC3CC.2132C%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom,
On 4/9/06 9:27 AM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Maxwell | 2006-04-09 21:04:06 | Re: Support Parallel Query Execution in Executor |
Previous Message | Luke Lonergan | 2006-04-09 20:51:50 | Re: Support Parallel Query Execution in Executor |
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Maxwell | 2006-04-09 21:04:06 | Re: Support Parallel Query Execution in Executor |
Previous Message | Luke Lonergan | 2006-04-09 20:51:50 | Re: Support Parallel Query Execution in Executor |