Andres Freund <and...@anarazel.de> writes: > On 2016-10-12 16:33:38 -0400, Tom Lane wrote: >> Also, if you look into /sys then you are going to see multiple >> possible values and it's not clear how to choose the right one.
> That's a fair point. It'd probably be good to use the largest we can, > bounded by a percentage of max waste or such. But that's likely > something for another day. Yeah. Merlin pointed out that on versions of Linux newer than my RHEL6 box, mmap accepts additional flag bits that let you specify which hugepage size to use. So we would need to use those if we wanted to work with anything besides the default size. Now AFAICT from the documentation I've seen, configuring hugepages is all still pretty manual, ie the sysadmin has to set up so many huge pages of each size at or near boot. So I'm thinking that using a non-default size should be something that happens only if the user tells us to, ie we'd need to add a GUC saying "use size X". That's pretty ugly but if the admin is intending PG to use pages from a certain pool, how else would we ensure that the right thing happens? And it'd provide a way of overriding our default 2MB guess on non-Linux platforms. Anyway, anything involving a new GUC is certainly new-feature, HEAD-only material. I think though that reading the default hugepage size out of /proc/meminfo is a back-patchable bug fix. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers