From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Gunther <raj(at)gusw(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Block / Page Size Optimization |
Date: | 2019-04-17 20:14:59 |
Message-ID: | 20190417201459.kmddlcnevt2mp4cv@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Apr 15, 2019 at 06:19:06PM +0200, Tomas Vondra wrote:
> On Mon, Apr 08, 2019 at 11:09:07AM -0400, Gunther wrote:
> > What really is the theoretical issue with the file system block size?
> > Where does -- in theory -- the benefit come from of using an XFS block
> > size of 8 kB, or even increasing the PostgreSQL page size to 16 kB and
> > then the XFS block size also to 16 kB? I remember having seen standard
> > UFS block sizes of 16 kB. But then why is Linux so tough on refusing to
> > mount an 8 kB XFS because it's VM page size is only 4 kB?
> >
> > Doesn't this all have one straight explanation?
> >
>
> Not really. AFAICS the limitation is due to a mix of reasons, and is
> mostly a trade-off between code complexity and potential benefits. It's
> probably simpler to manage filesystems with pages smaller than a memory
> page, and removing the limitation did not seem very useful compared to
> the added complexity. But it's probably a question for kernel hackers.
My guess is that having the file system block size be the same as the
virtual memory page size allows flipping pages from kernel to userspace
memory much simpler.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Schmidt | 2019-04-17 20:59:13 | Best Filesystem for PostgreSQL |
Previous Message | Laurenz Albe | 2019-04-17 17:11:42 | Re: Pg10 : Client Configuration for Parallelism ? |