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

Re: First set of OSDL Shared Mem scalability results, some wierdness ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Curt Sampson <cjs(at)cynic(dot)net>
Cc: Kevin Brown <kevin(at)sysexperts(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: First set of OSDL Shared Mem scalability results, some wierdness ...
Date: 2004-10-23 18:11:04
Message-ID: 26467.1098555064@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Curt Sampson <cjs(at)cynic(dot)net> writes:
> Back when I was working out how to do this, I reckoned that you could
> use mmap by keeping a write queue for each modified page. Reading,
> you'd have to read the datum from the page and then check the write
> queue for that page to see if that datum had been updated, using the
> new value if it's there. Writing, you'd add the modified datum to the
> write queue, but not apply the write queue to the page until you'd had
> confirmation that the corresponding transaction log entry had been
> written. So multiple writes are no big deal; they just all queue up in
> the write queue, and at any time you can apply as much of the write
> queue to the page itself as the current log entry will allow.

Seems to me the overhead of any such scheme would swamp the savings from
avoiding kernel/userspace copies ... the locking issues alone would be
painful.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2004-10-23 18:21:10
Subject: Re: futex results with dbt-3
Previous:From: Bjorn BengthDate: 2004-10-23 15:54:05
Subject: different io elevators in linux

pgsql-hackers by date

Next:From: Steve CrawfordDate: 2004-10-23 21:16:34
Subject: Re: Time off
Previous:From: Oliver ElphickDate: 2004-10-23 15:59:26
Subject: Re: Slony-I 1.0.4 Released

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