Large Pages and Super Pages for PostgreSQL
Hi Hacker Solaris and FreeBSD supports large/super pages, and can be used automatically by applications. Seems Postgres can't use the large/super pages on Solaris and FreeBSD os(I think can't use the large/super page HPUX and AIX), is there anyone could take a look? following is my testing: 1. check OS supported large page size -bash-4.3$ pagesize -a 4096 2097152 1073741824 2. the OS version is 5.11 -bash-4.3$ uname -a SunOS 08a6a65f-b5a0-c159-f184-e81c379d1f5d 5.11 hunghu-20220114T101258Z:a3282be5a8 i86pc i386 i86pc -bash-4.3$ 3. PostgreSQL shared buffers is 11G -bash-4.3$ grep -i shared_buffer postgresql.conf shared_buffers = 11GB # min 128kB 4. checked on Solaris OS, all of the memory are 4k page for PostgreSQL , had not use 2M or 1G page size -bash-4.3$ cat postmaster.pid |head -n 1 31637 -bash-4.3$ pmap -sxa 31637 31637: /opt/local/bin/postgres Address Kbytes RSS Anon Locked Pgsz Mode Mapped File 0040 4 4 - - 4K r-x-- postgres 00401000 872 28 - - - r-x-- postgres 004DB000 84 84 - - 4K r-x-- postgres 004F 184 24 - - - r-x-- postgres 0051E000 248 248 - - 4K r-x-- postgres 0055C000 8 8 - - - r-x-- postgres 0055E000 8 8 - - 4K r-x-- postgres 0056 16 12 - - - r-x-- postgres 00564000 4 4 - - 4K r-x-- postgres 00565000 20 20 - - - r-x-- postgres 0056A000 4 4 - - 4K r-x-- postgres 0056B000 24 24 - - - r-x-- postgres 00571000 8 8 - - 4K r-x-- postgres 00573000 4 4 - - - r-x-- postgres 00574000 16 16 - - 4K r-x-- postgres 00578000 24 4 - - - r-x-- postgres 0057E000 4 4 - - 4K r-x-- postgres 0057F000 8 8 - - - r-x-- postgres 00581000 8 8 - - 4K r-x-- postgres 00583000 4 4 - - - r-x-- postgres 00584000 188 188 - - 4K r-x-- postgres 005B3000 84 28 - - - r-x-- postgres 005C8000 24 24 - - 4K r-x-- postgres 005CE000 76 40 - - - r-x-- postgres 005E1000 4 4 - - 4K r-x-- postgres 005E2000 368 280 - - - r-x-- postgres 0063E000 4 4 - - 4K r-x-- postgres 0063F000 80 36 - - - r-x-- postgres 00653000 12 12 - - 4K r-x-- postgres 00656000 8 8 - - - r-x-- postgres 00658000 4 4 - - 4K r-x-- postgres 00659000 12 12 - - - r-x-- postgres 0065C000 8 8 - - 4K r-x-- postgres 0065E000 4 4 - - - r-x-- postgres 0065F000 4 4 - - 4K r-x-- postgres 0066 12 12 - - - r-x-- postgres 00663000 8 8 - - 4K r-x-- postgres 00665000 12 12 - - - r-x-- postgres 00668000 4 4 - - 4K r-x-- postgres 00669000 4 4 - - - r-x-- postgres 0066A000 8 8 - - 4K r-x-- postgres 0066C000 32 32 - - - r-x-- postgres 00674000 4 4 - - 4K r-x-- postgres 00675000 4 4 - - - r-x-- postgres 00676000 4 4 - - 4K r-x-- postgres 00677000 156 156 - - - r-x-- postgres 0069E000 4 4 - - 4K r-x-- postgres 0069F000 416 396 - - - r-x-- postgres 00707000 4
Re: So, about that cast-to-typmod-minus-one business
+1 backporting Tony On 2021/9/19 01:06, Tom Lane wrote: > We had left it as an open issue whether or not to risk back-patching > 5c056b0c2 into stable branches [1]. While updating the v14 release notes, > I realized that we can't put off that decision any longer, because we > have to decide now whether to document that as a new behavior in v14. > > I'm inclined to back-patch, since nobody has complained about this > in 14beta3. Thoughts? > > regards, tom lane > > [1] > https://www.postgresql.org/message-id/flat/CABNQVagu3bZGqiTjb31a8D5Od3fUMs7Oh3gmZMQZVHZ%3DuWWWfQ%40mail.gmail.com
Re: New committers: Melanie Plageman, Richard Guo
Congratulations! On 2024/4/26 19:54, Jonathan S. Katz wrote: The Core Team would like to extend our congratulations to Melanie Plageman and Richard Guo, who have accepted invitations to become our newest PostgreSQL committers. Please join us in wishing them much success and few reverts! Thanks, Jonathan
Re: Retiring some encodings?
Hi Michael Yeah, that's a good point. I would also question what's the benefit in using GB18030 over UTF-8, though. An obvious one I can see is because legacy applications never get updated. The GB18030 encoding standard is a mandatory Chinese character encoding standard required by regulations. Software sold and used in China must support GB18030, with its latest version being the 2023 edition. The primary advantage of GB18030 is that most Chinese characters require only 2 bytes for storage, whereas UTF-8 necessitates 3 bytes for the same characters. This makes GB18030 significantly more storage-efficient compared to UTF-8 in terms of space utilization. Tony
