Re: Synchronized Scan update

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Synchronized Scan update
Date: 2007-03-13 17:36:27
Message-ID: 1173807387.23455.107.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2007-03-13 at 17:17 +0000, Simon Riggs wrote:
> On Tue, 2007-03-13 at 10:08 -0700, Jeff Davis wrote:
> > On Tue, 2007-03-13 at 12:53 -0400, Tom Lane wrote:
> > > Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> > > > I agree that ss_report_loc() doesn't need to report on every call. If
> > > > there's any significant overhead I agree that it should report less
> > > > often. Do you think that the overhead is significant on such a simple
> > > > function?
> > >
> > > One extra LWLock cycle per page processed definitely *is* a significant
> > > overhead ... can you say "context swap storm"? I'd think about doing it
> > > once every 100 or so pages.
> > >
> >
> > No lock is needed to store the hint. If somehow the hint (which is
> > stored in a static table, no pointers) gets invalid data due to a race
> > condition, the new scan will simply consider the hint invalid and start
> > at 0.
> >
> > I did this precisely to avoid causing a performance regression for usage
> > patterns that don't benefit from sync scans.
>
> Shared memory access is still a performance/scalability concern because
> so many people want access to it at the same time.
>
> There really is no need to do this after each block. 8 CPUs ought to be
> able to do 8 scans without tripping over each other. Especially if they
> are on separate tables.
>

Ok, I'll do it every 100 pages.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-03-13 17:42:45 8.1.x (tested 8.1.8) timezone bugs
Previous Message David Fetter 2007-03-13 17:34:32 Re: My honours project - databases using dynamically attached entity-properties