Re: New PostgreSQL Contributors
On Fri, Oct 4, 2024 at 10:08 AM Greg Sabino Mullane wrote: > Congratulations to all! This seems the sort of thing we should crosspost > to -general and/or -announce, no? > > Congratulations to all! +1 on Greg's suggestion. Roberto
Re: Changing the default random_page_cost value
On Fri, Sep 27, 2024 at 8:07 AM Greg Sabino Mullane wrote: > tl;dr let's assume SSDs are popular and HDDs are the exception and flip > our default > > Granted, there are other factors involved, and yes, perhaps we should > tweak some of the similar settings as well, but ranom_page_cost is the one > setting most out of sync with today's hardware realities. So I'll be brave > and throw a number out there: 1.2. And change our docs to say wordage like > "if you are using an older hard disk drive technology, you may want to try > raising rpc" to replace our fairly-hidden note about SSDs buried in the > last sentence - of the fourth paragraph - of the rpc docs. > +1 I suggest a slightly nicer comment in the default conf file, like "For spinning hard drives, raise this to at least 3 and test" Roberto
Re: Why mention to Oracle ?
On Sun, Sep 22, 2024 at 8:10 AM Marcos Pegoraro wrote: > Em sáb., 21 de set. de 2024 às 18:42, Bruce Momjian > escreveu: > >> I suggest you explain what changes would make the docs better (meaing >> more useful). >> > > So, if we have a "Compatibility/Translation/Feature Comparison/ ... with > other Databases", it would be so cool. > But we don't have this kind of page, so why do we need to mention just one > of them ? > Because people contributed those. > Searching on SGML there are 0 mentions to SQL Server and MySQL, but there > are almost 50 mentions to Oracle. > So this is my point, if you don't do the same for others, why do it for > Oracle ? > Because people contributed those. > And again, I'm not saying that migrations from Oracle are not important, > I'm saying migrations from Oracle have the same importance than from MySQL, > SQL Server, Mongo, ... > Again, different people at different times felt it was important to contribute patches to the documentation explaining Oracle differences, or porting, etc. That's why those are in the current docs. If you're volunteering to add a MySQL, SQL Server, Mongo, etc porting to the docs, I'm sure it could be a nice addition. Roberto
Re: Why mention to Oracle ?
On Fri, Sep 20, 2024 at 11:43 AM Marcos Pegoraro wrote: > > My suggestion is: Postgres DOCs are written and have to be read by > Postgres users, just that. If you are Oracle user, search for a tutorial on > how to migrate to Postgres or find tools for it, but not in DOCs > As Tomas, Tom and others pointed out, it's simply because it is a common database people migrate from and ask for help, and people contributed patches to the documentation out of their own need, or to help others. (Several) years ago I wrote a since-deprecated section of the docs to port from PL/SQL to PL/pgSQL because it was needed back then. Because if you write something for Oracle users, SQL Server users can claim > why there is no "Porting from T-SQL to PL/pgSQL" ? > And MySQL users can do the same, and so on. > And those users are welcome to contribute patches to the docs explaining why they think those additions to our docs would be helpful. > Maybe Oracle was the most common DB which migrated to Postgres, but I'm > not sure this is true for today. > I don't know about you, but in my experience that is absolutely not true. I deal with lots of people and companies migrating from Oracle, or whose staff have experience with Oracle and need help adapting that knowledge to Postgres. Roberto
Re: New committers: Melanie Plageman, Richard Guo
On Fri, Apr 26, 2024 at 5:54 AM 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! > Amazing accomplishment. Thank you for your contributions to PostgreSQL. Well deserved! Roberto
Re: An improved README experience for PostgreSQL
On Wed, Feb 28, 2024 at 11:55 AM David E. Wheeler wrote: > > IME the keys to decent-looking Markdown are: > > 1. Wrapping lines to a legible width (76-80 chars) > 2. Link references rather than inline links +1 on Markdown including David's suggestions above. Agree that without proper guidelines, md files can become messy looking. Roberto
Re: documentation structure
On Mon, Mar 18, 2024 at 10:12 AM Robert Haas wrote: > I was looking at the documentation index this morning[1], and I can't > help feeling like there are some parts of it that are over-emphasized > and some parts that are under-emphasized. I'm not sure what we can do > about this exactly, but I thought it worth writing an email and seeing > what other people think. > I agree, and my usage patterns of the docs are similar. As the project progresses and more features are added and tacked on to existing docs, things can get murky or buried. I imagine that web access and search logs could paint a picture of documentation usage. I don't know what other people's experience is, but for me, wanting to > know what a command does or what a setting does is extremely common. > Therefore, I think these chapters are disproportionately important and > should be emphasized more. In the case of the GUC reference, one idea > +1 I have is to split up "III. Server Administration". My proposal is > that we divide it into three sections. The first would be called "III. > Server Installation" and would cover chapters 16 (installation from > binaries) through 19 (server setup and operation). The second would be > called "IV. Server Configuration" -- so every section that's currently > a subsection of "server configuration" would become a top-level > chapter. The third division would be "V. Server Administration," and > would cover the current chapters 21-33. This is probably far from I like all of those. > I don't know what to do about "I. SQL commands". It's obviously > impractical to promote that to a top-level section, because it's got a > zillion sub-pages which I don't think we want in the top-level > documentation index. But having it as one of several unnumbered > chapters interposed between 51 and 52 doesn't seem great either. > I think it'd be easier to read if current "VI. Reference" came right after "Server Administration", ahead of "Client Interfaces" and "Server Programming", which are of interest to a much smaller subset of users. Also if the subchapters were numbered like the rest of them. I don't think the roman numerals are particularly helpful. The stuff that I think is over-emphasized is as follows: (a) chapters > 1-3, the tutorial; (b) chapters 4-6, which are essentially a ... Also +1 Thoughts? I realize that this topic is HIGHLY prone to ENDLESS > bikeshedding, and it's inevitable that not everybody is going to > agree. But I hope we can agree that it's completely silly that it's > vastly easier to find the documentation about the backup manifest > format than it is to find the documentation on CREATE TABLE or > shared_buffers, and if we can agree on that, then perhaps we can agree > on some way to make things better. > Impossible to please everyone, but I'm sure we can improve things. I've contributed to different parts of the docs over the years, and would be happy to help with this work. Roberto
Re: [DOC] Add detail regarding resource consumption wrt max_connections
On Fri, Jan 12, 2024 at 3:15 PM Cary Huang wrote: > I think it is good to warn the user about the increased allocation of > memory for certain parameters so that they do not abuse it by setting it to > a huge number without knowing the consequences. > > It is true that max_connections can increase the size of proc array and > other resources, which are allocated in the shared buffer, which also means > less shared buffer to perform regular data operations. I am sure this is > not the only parameter that affects the memory allocation. > "max_prepared_xacts" can also affect the shared memory allocation too so > the same warning message applies here as well. Maybe there are other > parameters with similar effects. > > Instead of stating that higher max_connections results in higher > allocation, It may be better to tell the user that if the value needs to be > set much higher, consider increasing the "shared_buffers" setting as well. > Appreciate the review, Cary. My goal was to inform the reader that there are implications to setting max_connections higher. I've personally seen a user mindlessly set this to 50k connections, unaware it would cause unintended consequences. I can add a suggestion for the user to consider increasing shared_buffers in accordance with higher max_connections, but it would be better if there was a "rule of thumb" guideline to go along. I'm open to suggestions. I can revise with a similar warning in max_prepared_xacts as well. Sincerely, Roberto
Re: Add minimal C example and SQL registration example for custom table access methods.
Suggestion: In the C example you added you mention in the comment: + /* Methods from TableAmRoutine omitted from example, but all + non-optional ones must be provided here. */ Perhaps you could provide a "see " to point the reader finding your example where he could find these non-optional methods he must provide? Nitpicking a little: your patch appears to change more lines than it does, because it added line breaks earlier in the lines. I would generally avoid that unless there's good reason to do so.
[DOC] Add detail regarding resource consumption wrt max_connections
The documentation for max_connections does not mention that just by having a higher value for max_connections, PostgreSQL will use more resources. While working with different customers, I noticed that several of them set max_connections to very high numbers, even though they never expected to actually have that many connections to their PostgreSQL instance. In one extreme case, the user set max_connections to 20 and was befuddled that the instance was using more memory than another with the same number of connections. This patch adds language to the documentation pointing to the fact that higher value of max_connections leads to higher consumption of resources by Postgres, adding one paragraph to doc/src/sgml/config.sgml PostgreSQL sizes certain resources based directly on the value of max_connections. Increasing its value leads to higher allocation of those resources, including shared memory. Sincerely, Roberto Mello max-connections-guc-detail.patch Description: Binary data
Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
On Mon, Oct 30, 2023 at 1:09 AM Michael Paquier wrote: > > I have been reviewing the patch, and applied portions of it as of > dc5bd388 and 1ffdc03c and they're quite independent pieces. After > that, the remaining bits of the patch to change the behavior is now > straight-forward. I have written a commit message for it, while on > it, as per the attached. > A suggestion for the hint message in an effort to improve readability: "If you are restoring from a backup, ensure \"%s/recovery.signal\" or \"%s/standby.signal\" is present and add required recovery options." I realize the original use of "touch" is a valid shortcut for what I suggest above, however that will be less clear for the not-so-un*x-inclined users of Postgres, while for some it'll be downright confusing, IMHO. It also provides the advantage of being crystal clear on what needs to be done to fix the problem. Roberto
Re: PG 16 draft release notes ready
Adding to this thread as suggested by jkatz for consideration of adding to release notes... In [1] I mention the omission of ldap_password_hook and a suggested paragraph. Roberto [1] https://www.postgresql.org/message-id/CAKz%3D%3DbLzGb-9O294AoZHqEWpAi2Ki58yCr4gaqg1HnZyh3L1uA%40mail.gmail.com
Re: PostgreSQL 16 Beta 2 release announcement draft
On Tue, Jun 27, 2023 at 11:40 AM Jonathan S. Katz wrote: > > Was this discussed on the release notes thread?[1]. It can always be > added to the release notes -- those aren't finalized until GA. > > After Beta 1, the announcements are either about new feature > additions/removals since the last beta release, or bug fixes. I don't > think it makes sense to include this here. It wasn't. I'll add it to that thread. Thank you, Roberto
Re: PostgreSQL 16 Beta 2 release announcement draft
On Tue, Jun 27, 2023 at 8:32 AM Jonathan S. Katz wrote: > > I used the open items list[1] to build the draft. If there are any > notable please omissions, please let me know. I noticed that ldap_password_hook [1] was omitted from the release notes. I believe it should be included if nothing else so that it's written somewhere that it's there. AFAIK there's no other documentation about it. Andrew Dunstan and John Naylor can add comments here, but a paragraph like this could be added: "A hook for modifying the ldapbind password was added to libpq. The hook can be installed by a shared_preload library. This will allow users who have to work with LDAP authentication to create their own methods of dealing with ldap bind passwords. An example is provided at test/modules/ldap_password_func/ldap_password_func.c" Thanks, Roberto [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=419a8dd8142afef790dafd91ba39afac2ca48aaf https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/test/modules/ldap_password_func/ldap_password_func.c;h=4d980d28b1ef3e37da365ebbd4ca998f4786b827;hb=419a8dd8142afef790dafd91ba39afac2ca48aaf
Re: Postgres Version want to update from 9.2 to 9.5 version in CentOS 7.9
On Fri, Apr 28, 2023 at 12:10 PM Gautham Raj wrote: > Thank you for the quick response. > > Yes, I'm willing to get the latest version. I read some articles CentOS 7 > doesn't support the latest versions. So was trying the old versions. > > I tried the article shared but, got the below error at the step. > You have bigger problems to solve with your setup. Basic programs are failing to run, so there are other things that need fixing with your package manager that are completely unrelated to PostgreSQL. Although Tom kindly responded to your initial question, this list (-hackers) is the wrong place to be asking that type of question, as its purpose is to discuss the *development* of PostgreSQL, not installation and upgrade issues. There are many other places better suited to your question, including the pgsql-general list [1], IRC channel [2] and Slack channel [3]. -Roberto [1] https://www.postgresql.org/list/pgsql-general/ [2] https://www.postgresql.org/community/irc/ [3] https://join.slack.com/t/postgresteam/shared_invite/zt-1qj14i9sj-E9WqIFlvcOiHsEk2yFEMjA
Re: PostgreSQL 16 Release Management Team & Feature Freeze
On Tue, Mar 21, 2023 at 9:35 AM Jonathan S. Katz wrote: > > You can track open items for the PostgreSQL 16 release here: > > https://wiki.postgresql.org/wiki/PostgreSQL_16_Open_Items The wiki page references April 8th, 2022, btw. Roberto
Re: doc: BRIN indexes and autosummarize
On Tue, Jul 5, 2022 at 5:47 AM Alvaro Herrera wrote: > OK, I have adopted all your proposed changes, thanks for submitting in > both forms. I did some more wordsmithing and pushed, to branches 12 and > up. 11 fails 'make check', I think for lack of Docbook id tags, and I > didn't want to waste more time. Kindly re-read the result and let me > know if I left something unaddressed, or made something worse. The > updated text is already visible in the website: > https://www.postgresql.org/docs/devel/brin-intro.html > You removed the reference to the functions' documentation at functions-admin-index choosing instead to duplicate a summarized version of the docs, and to boot getting the next block to be blobbed together with it. Keeping with the reduced-readability theme, you made the paragraphs even bigger. While I do appreciate the time to clarify things a bit, as was my original intent with the patch, We should be writing documentation with the user in mind, not for our developer eyes. Different target audiences. It is less helpful to have awesome features that don't get used because users can't really grasp the docs. Paragraphs such as this feel like we're playing "summary bingo": When a new page is created that does not fall within the last summarized range, the range that the new page belongs into does not automatically acquire a summary tuple; those tuples remain unsummarized until a summarization run is invoked later, creating the initial summary for that range Roberto -- Crunchy Data -- passion for open source PostgreSQL
Re: doc: BRIN indexes and autosummarize
On Mon, Jul 4, 2022 at 9:20 AM Alvaro Herrera wrote: > > [Some of] these additions are wrong actually. It says that autovacuum > will not summarize new entries; but it does. If you just let the table > sit idle, any autovacuum run that cleans the table will also summarize > any ranges that need summarization. > > What 'autosummarization=off' means is that the behavior to trigger an > immediate summarization of a range once it becomes full is not default. > This is very different. > Without having read through the code, I'll take your word for it. I simply went with what was written on this phrase of the docs: "or by automatic summarization executed by autovacuum, as insertions occur. (This last trigger is disabled by default and can be enabled with the autosummarize parameter.)" To me this did not indicate a third behavior, which is what you are describing, so I'm glad we're having this discussion to clarify it. As for the new s that you added, I'd say they're > stylistically wrong. Each paragraph is supposed to be one fully > contained idea; what these tags do is split each idea across several > smaller paragraphs. This is likely subjective though. > While I don't disagree with you, readability is more important. We have lots of places (such as that one on the docs) where we have a big blob of text, reducing readability, IMHO. In the source they are broken by new lines, but in the rendered HTML, which is what the vast majority of people read, they get rendered into a big blob-looking-thing. > What would be the downside (if any) of having autosummarize=on by default? > > I'm not aware of any. Maybe we should turn it on by default. > +1 Thanks for looking at this Alvaro. Roberto -- Cunchy Data -- passion for open source PostgreSQL
Re: Patch proposal: New hooks in the connection path
On Fri, Jul 1, 2022 at 5:00 PM Nathan Bossart wrote: > > > That being said, I don't see why this information couldn't be provided in a > system view. IMO it is generically useful. +1 for a system view with appropriate permissions, in addition to the hooks. That would make the information easily accessible to a number or monitoring systems besides the admin. Roberto — Crunchy Data — passion for open source PostgreSQL >
doc: BRIN indexes and autosummarize
Here's a patch to clarify the BRIN indexes documentation, particularly with
regards
to autosummarize, vacuum and autovacuum. It basically breaks down a big
blob of a
paragraph into multiple paragraphs for clarity, plus explicitly tells how
summarization
happens manually or automatically.
I also added cross-references to various relevant sections, including the
create index
page.
On this topic... I'm not familiar with with the internals of BRIN indexes
and in
backend/access/common/reloptions.c I see:
{
"autosummarize",
"Enables automatic summarization on this BRIN index",
RELOPT_KIND_BRIN,
AccessExclusiveLock
},
Is the exclusive lock on the index why autosummarize is off by default?
What would be the downside (if any) of having autosummarize=on by default?
Roberto
--
Crunchy Data - passion for open source PostgreSQL
brin-autosummarize-docs.patch
Description: Binary data
Re: pgcon unconference / impact of block size on performance
On Sat, Jun 4, 2022 at 5:23 PM Tomas Vondra wrote: > Hi, > > At on of the pgcon unconference sessions a couple days ago, I presented > a bunch of benchmark results comparing performance with different > data/WAL block size. Most of the OLTP results showed significant gains > (up to 50%) with smaller (4k) data pages. Thanks for sharing this Thomas. We’ve been doing similar tests with different storage classes in kubernetes clusters. Roberto >
Re: "an SQL" vs. "a SQL"
On Thu, Jun 10, 2021 at 1:27 AM David Rowley wrote: > > I think we should change all 55 instances of "a SQL" in the docs to > use "an SQL" and leave the 800 other instances of "a SQL" alone. +1 Consistency is good. Roberto
