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

Re: posix_fadvise v22

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: posix_fadvise v22
Date: 2009-01-03 00:51:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> In principle you should be able to adjust the constant so that vmstat
>> shows about 50% CPU busy, and then enabling fadvise should improve
>> matters significantly.

> I think in practice individual queries don't interleave much cpu with i/o
> work. A single random page fetch is 5ms which is an awful lot of cpu cycles to
> be sinking somewhere. In practice I think this is going to be single-digit
> percentages.

The point of the suggestion is to prove that the patch works as
advertised.  How wide the sweet spot is for this test isn't nearly as
interesting as proving that there *is* a sweet spot.  If you can't
find one it suggests that either the patch or the local posix_fadvise
doesn't work.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Alex HunsakerDate: 2009-01-03 01:20:19
Subject: Re: Hashtable entry recycling algorithm in pg_stat_statements
Previous:From: Tom LaneDate: 2009-01-03 00:22:40
Subject: Hashtable entry recycling algorithm in pg_stat_statements

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