| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Anderson Carniel <accarniel(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: What is the posix_memalign() equivalent for the PostgreSQL? |
| Date: | 2016-09-02 17:17:49 |
| Message-ID: | 20160902171749.ykdjdu55usvjojxg@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2016-09-02 13:05:37 -0400, Tom Lane wrote:
> Anderson Carniel <accarniel(at)gmail(dot)com> writes:
> > If not, according to your experience, is there a
> > significance difference between the performance of the O_DIRECT or not?
>
> AFAIK, nobody's really bothered to measure whether that would be useful
> for Postgres. The results would probably be quite platform-specific
> anyway.
I've played with patches to make postgres use O_DIRECT. On linux, it's
rather beneficial for some workloads (fits into memory), but it also
works really badly for some others, because our IO code isn't
intelligent enough. We pretty much rely on write() being nearly
instantaneous when done by normal backends (during buffer replacement),
we rely on readahead, we rely on the kernel to stopgap some bad
replacement decisions we're making.
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2016-09-02 17:21:42 | Re: Logical decoding slots can go backwards when used from SQL, docs are wrong |
| Previous Message | Tom Lane | 2016-09-02 17:05:37 | Re: What is the posix_memalign() equivalent for the PostgreSQL? |