From: | "Luke Lonergan" <LLonergan(at)greenplum(dot)com> |
---|---|
To: | "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org>, "Pollard, Mike" <mpollard(at)cincom(dot)com> |
Cc: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ice-broker scan thread |
Date: | 2005-11-29 23:42:27 |
Message-ID: | BFB22763.14A58%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff,
On 11/29/05 9:35 AM, "Jeffrey W. Baker" <jwbaker(at)acm(dot)org> wrote:
> On Tue, 2005-11-29 at 09:45 -0500, Pollard, Mike wrote:
>
>> Anyway, what I did was the following. When doing a sequential scan, we
>> were starting at the beginning of the table and scanning forward. If I
>> threw up some threads to read ahead, then my user thread and my read
>> ahead threads would thrash on trying to lock the buffer slots. So, I
>> had the read ahead threads start at some distance into the table, and
>> work toward the beginning.
>
> I believe this is commonly called a synchronous scan.
I think sync scan refers to the use of a scanner shared among concurrent
queries, where they can join a scan in progress from it's current location.
It sounds like the logic could be shared. Sync scan (as I've described
above) is another important optimization we'd like to see.
- Luke
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-11-29 23:51:53 | Re: Using multi-row technique with COPY |
Previous Message | Simon Riggs | 2005-11-29 22:53:38 | Re: slow IN() clause for many cases |