Skip site navigation (1) Skip section navigation (2)

Re: Seq scans status update

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Seq scans status update
Date: 2007-05-30 21:45:51
Message-ID: 21802.1180561551@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Wed, 2007-05-30 at 15:56 -0400, Tom Lane wrote:
>> In the sync-scan case the idea seems pretty bogus anyway, because the
>> actual working set will be N backends' rings not just one.

> I don't follow. Ideally, in the sync-scan case, the sets of buffers in
> the ring of different scans on the same relation will overlap
> completely, right?

> We might not be at the ideal, but the sets of buffers in the rings
> shouldn't be disjoint, should they?

According to Heikki's explanation here
http://archives.postgresql.org/pgsql-patches/2007-05/msg00498.php
each backend doing a heapscan would collect its own ring of buffers.
You might have a few backends that are always followers, never leaders,
and so never actually fetch any pages --- but for each backend that
actually did any I/O there would be a separate ring.  In practice I'd
expect the lead would "change hands" pretty often and so you'd see all
the backends accumulating their own rings.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Jeff DavisDate: 2007-05-30 22:23:58
Subject: Re: Seq scans status update
Previous:From: Jeff DavisDate: 2007-05-30 20:43:15
Subject: Re: Seq scans status update

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group