Re: MMAP Buffers - Mailing list pgsql-hackers

From Joshua Berkus
Subject Re: MMAP Buffers
Date
Msg-id 309059930.294300.1302978790081.JavaMail.root@mail-1.01.com
Whole thread Raw
In response to Re: MMAP Buffers  (Radosław Smogura <rsmogura@softperience.eu>)
Responses Re: MMAP Buffers
List pgsql-hackers
Radoslaw,

> I think 10% is quite good, as my stand-alone test of mmap vs. read
> shown that
> speed up of copying 100MB data to mem may be from ~20ms to ~100ms
> (depends on
> destination address). Of course deeper, system test simulating real
> usage will
> say more. In any case after good deals with writes, I will speed up
> reads. I
> think to bypass smgr/md much more and to expose shared id's (1,2,3...)
> for
> each file segment.

Well, given the risks to durability and stability associated with using MMAP, I doubt anyone would even consider it for
a10% throughput improvement.  However, I don't think the test you used demonstrates the best case for MMAP as a
performanceimprovement.
 

> In attachment I sent test-scripts which I used to fill data, nothing
> complex
> (left from 2nd level caches).
> 
> Query I've used to measure was SELECT count(substr(content, 1, 1))
> FROM
> testcase1 WHERE multi_id > 50000;
> 
> Timings ware taken from psql.
> 
> I didn't made load (I have about 2GB of free sapce at /home, and 4GB
> RAM) and
> stress (I'm not quite ready to try concurrent updates of same page -
> may fail,
> notice is and place to fix is in code) tests yet.

Yes, but this test case doesn't offer much advantage to MMAP.  Where I expect it would shine would be cases where the
databaseis almost as big as, or much bigger than RAM ... where the extra data copying by current code is both frequent
andwastes buffer space we need to use.  As well as concurrent reads from the same rows.
 

You can write a relatively simple custom script using pgBench to test this; you don't need a big complicated benchmark.
Once we get over the patch cleanup issues, I might be able to help with this. 
 

> Netbeans is quite good, of course it depends who likes what. Just try
> 7.0 RC
> 2.

I don't know if you've followed the formatting discussion, but apparently there's an issue with Netbeans re-indenting
linesyou didn't even edit.  It makes your patch hard to read or apply.  I expect that Netbeans has some method to
reconfigureindenting, etc.; do you think you could configure it to PostgresQL standards so that this doesn't get in the
wayof evaluation of your ideas?
 

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco


pgsql-hackers by date:

Previous
From: Joshua Berkus
Date:
Subject: Re: Formatting Curmudgeons WAS: MMAP Buffers
Next
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Rename pg_regress option --multibyte to --encoding