| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Cc: | Wilm Hoyer <W(dot)Hoyer(at)dental-vision(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work. |
| Date: | 2022-07-07 22:38:49 |
| Message-ID: | YsdgeTimQONuzEDQ@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Tue, Apr 26, 2022 at 12:54:35PM +0800, Julien Rouhaud wrote:
> Their API is entirely useless, so I'm still on the opinion that we should
> unconditionally use the FILE_MAP_LARGE_PAGES flag if it's defined and call it a
> day.
Now that the minimal runtime version is Windows 10 in v16~ thanks to
495ed0e, we could be much more aggressive and do the attached, which
is roughly what Thomas has proposed upthread at the exception of
assuming that FILE_MAP_LARGE_PAGES always exists, because updates are
forced by MS in this environment. We could make it conditional, of
course, with an extra #ifdef painting.
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Fix-huge_pages-on-current-Windows.patch | text/x-diff | 1.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2022-07-09 01:35:42 | BUG #17542: tsquery returns incorrect results with nested, conjuncted followed-by operators |
| Previous Message | Tom Lane | 2022-07-07 18:02:24 | Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-07-07 22:42:37 | Re: index for inet column |
| Previous Message | Michael Paquier | 2022-07-07 22:38:23 | Re: Remove support for Visual Studio 2013 |