| From: | Jan Kara <jack(at)suse(dot)cz> |
|---|---|
| To: | Mel Gorman <mgorman(at)suse(dot)de> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Joshua Drake <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "lsf-pc(at)lists(dot)linux-foundation(dot)org" <lsf-pc(at)lists(dot)linux-foundation(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
| Subject: | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
| Date: | 2014-01-13 22:38:44 |
| Message-ID: | 20140113223844.GB10366@quack.suse.cz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon 13-01-14 22:26:45, Mel Gorman wrote:
> The flipside is also meant to hold true. If you know data will be needed
> in the near future then posix_fadvise(POSIX_FADV_WILLNEED). Glancing at
> the implementation it does a forced read-ahead on the range of pages of
> interest. It doesn't look like it would block.
That's not quite true. POSIX_FADV_WILLNEED still needs to map logical
file offsets to physical disk blocks and create IO requests. This happens
synchronously. So if your disk is congested and relevant metadata is out of
cache, or we simply run out of free IO requests, POSIX_FADV_WILLNEED can
block for a significant amount of time.
Honza
--
Jan Kara <jack(at)suse(dot)cz>
SUSE Labs, CR
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2014-01-13 22:44:53 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
| Previous Message | Mel Gorman | 2014-01-13 22:36:06 | Re: Linux kernel impact on PostgreSQL performance |