| From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
|---|---|
| To: | James Bottomley <James(dot)Bottomley(at)HansenPartnership(dot)com>, Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Andres Freund <andres(at)2ndquadrant(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>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Mel Gorman <mgorman(at)suse(dot)de>, Jim Nasby <jim(at)nasby(dot)net>, 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-14 08:20:23 |
| Message-ID: | 52D4F347.30802@2ndQuadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 01/13/2014 11:22 PM, James Bottomley wrote:
>
>> The less exciting, more conservative option would be to add kernel
>> interfaces to teach Postgres about things like raid geometries. Then
>> Postgres could use directio and decide to do prefetching based on the
>> raid geometry, how much available i/o bandwidth and iops is available,
>> etc.
>>
>> Reimplementing i/o schedulers and all the rest of the work that the
>> kernel provides inside Postgres just seems like something outside our
>> competency and that none of us is really excited about doing.
> This would also be a well trodden path ... I believe that some large
> database company introduced Direct IO for roughly this purpose.
>
The file system at that time were much worse than they are now,
so said large companies had no choice but to write their own.
As linux file handling has been much better for most of active
development of postgresql we have been able to avoid
it and still have reasonable performance.
What was been pointed out above are some (allegedly
desktop/mobile influenced) decisions which broke good
performance.
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2014-01-14 08:21:40 | Re: plpgsql.consistent_into |
| Previous Message | Marti Raudsepp | 2014-01-14 08:18:48 | Re: Capturing EXPLAIN ANALYZE for a query without discarding the normal result set |