| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Jeff Davis" <pgsql(at)j-davis(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:17:23 |
| Message-ID: | 1173806244.3641.951.camel@silverbirch.site |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2007-03-13 17:18:02 | Re: Synchronized Scan update |
| Previous Message | Michael Ledford | 2007-03-13 17:14:18 | Re: Daylight Saving Time question PostgreSQL 8.1.4 |