Roles for pg_basebackup
Based on a recent conversation about backups I had I propose a small tweak to the pg_basebackup documentation. Listing the user types in the reverse order from today, putting superuser last, makes it IMO a little clearer that a REPLICATION role is preferrable to using a superuser for running backups. cheers ./daniel pg_basebackup_user.diff Description: Binary data
Re: Rendering pi more nicely in PDF
Alexander Lakhin writes: > 26.04.2020 22:13, Tom Lane wrote: >> Use of a new processing-instruction might not be the most elegant >> way to do this ... anyone have a better suggestion? > I would use the phrase tag, which is intended for such uses: [1] [2]. Good idea, done that way. > The "phrase" sounds too generic, but it doesn't require yet another > processing instruction e.g. for ∑ or a similar entity. Yeah, lack of easy applicability to other cases was the main thing bothering me about the processing-instruction fix. BTW, I tried to also use this markup inside the template for , so we'd only need one font-switching special case not two. Didn't work though --- apparently templates don't get applied recursively? Oh well. regards, tom lane
Re: Rendering pi more nicely in PDF
27.04.2020 18:04, Tom Lane wrote: > Alexander Lakhin writes: >> 26.04.2020 22:13, Tom Lane wrote: >> BTW, I tried to also use this markup inside the template for >> , so we'd only need one font-switching special case not two. >> Didn't work though --- apparently templates don't get applied recursively? >> Oh well. We can have a single template "symbol_font" and reuse it, but it doesn't seem cleaner to me (for just two cases). (Placing into wouldn't work as such a content goes into the output, whilst all xsl:templates apply to the input tree.) Best regards, Alexander diff --git a/doc/src/sgml/stylesheet-fo.xsl b/doc/src/sgml/stylesheet-fo.xsl index 2f2517d8ce..38c96737d5 100644 --- a/doc/src/sgml/stylesheet-fo.xsl +++ b/doc/src/sgml/stylesheet-fo.xsl @@ -92,7 +92,7 @@ - → + @@ -102,8 +102,9 @@ - - + + +
Re: explanation for random_page_cost is outdated
On Mon, Apr 27, 2020 at 06:02:41AM +0200, Pavel Stehule wrote: > > > ne 26. 4. 2020 v 21:25 odesílatel yigong hu napsal: > > Sorry to hijack the thread, I also recently have similar observation that > the statement about random_page_cost on SSD is ambiguous. The current > document says that > > > Storage that has a low random read cost relative to sequential, e.g. > solid-state drives, might also be better modeled with a lower value for > random_page_cost. > > However, this statement does not clarify what values might be good. For > some workload, the default value 4.0 would cause bad performance and > lowering random_page_cost to a value 3.0 or 2.0 does not solve the > performance problem. Only when the random_page_cost is lowered to below > 1.2 > will the bad performance be mitigated. Thus, I would suggest elaborating > on > this description further as: > > > Storage that has a low random read cost relative to sequential, e.g. > solid-state drives, might also be better modeled with a value that is > close > to 1 for random_page_cost. > > > I depends on estimation. Lot of people use random_page_cost as fix of broken > estimation. Then configures this value to some strange values. Lot of other > queries with good estimation can be worse then. I have been recommending 1.1 as a value for random_page_cost for SSDs for years, and I think it would be helpful to suggest that value, so doc patch attached. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml new file mode 100644 index a14df06..38ae273 *** a/doc/src/sgml/config.sgml --- b/doc/src/sgml/config.sgml *** ANY num_s *** 4915,4921 the database is smaller than the total server memory, decreasing random_page_cost can be appropriate. Storage that has a low random read cost relative to sequential, e.g. solid-state drives, might ! also be better modeled with a lower value for random_page_cost. --- 4915,4922 the database is smaller than the total server memory, decreasing random_page_cost can be appropriate. Storage that has a low random read cost relative to sequential, e.g. solid-state drives, might ! also be better modeled with a lower value for random_page_cost, ! e.g., 1.1.
Re: Rendering pi more nicely in PDF
Alexander Lakhin writes: > 27.04.2020 18:04, Tom Lane wrote: >> BTW, I tried to also use this markup inside the template for >> , so we'd only need one font-switching special case not two. >> Didn't work though --- apparently templates don't get applied recursively? > We can have a single template "symbol_font" and reuse it, but it doesn't > seem cleaner to me (for just two cases). Yeah, I agree, that's not an improvement. It's invoking the template two different ways, which seems pretty weird (at least to an XSL novice like me). regards, tom lane
Re: explanation for random_page_cost is outdated
Yes, I saw recommendations for 1.1 early, but why? Why such exactly precision number, why 1.1? Is here ever a theoretical or experimental prof? As for me, random_page_cost depended not only not characteristic of a storage device (hdd or ssd), but also on assumptions about how much of the database is in memory cache (90% by default). And this is a very rough assumption (of cause in ideal whole database must fit in the memory cache). And so I don't see any reason to recommend exactly value 1.1, simple 1 is good too, especially for an ideal server with huge memory cache. > 27 апр. 2020 г., в 19:16, Bruce Momjian написал(а): > > I have been recommending 1.1 as a value for random_page_cost for SSDs > for years, and I think it would be helpful to suggest that value, so doc > patch attached. > > -- > Bruce Momjian https://momjian.us > EnterpriseDB https://enterprisedb.com > > + As you are, so once was I. As I am, so you will be. + > + Ancient Roman grave inscription + >
Re: explanation for random_page_cost is outdated
On Mon, Apr 27, 2020 at 07:24:45PM +0300, Олег Самойлов wrote: > Yes, I saw recommendations for 1.1 early, but why? Why such exactly > precision number, why 1.1? Is here ever a theoretical or experimental > prof? Well, SSD random performance is slightly slower than sequential, so the value should be slighly larger than 1.1. Clearly 2.0 or higher is not recommended. Could it be 1.05 or 1.01 or 1.15? Yeah, but probably giving 1.1 is at least a good suggestion to start with. > As for me, random_page_cost depended not only not characteristic of a > storage device (hdd or ssd), but also on assumptions about how much of > the database is in memory cache (90% by default). And this is a very > rough assumption (of cause in ideal whole database must fit in the > memory cache). True. > And so I don't see any reason to recommend exactly value 1.1, simple 1 > is good too, especially for an ideal server with huge memory cache. Uh, well, 1.0 is fine for non-SSDs too if all the data is in cache, and there are no database writes. --- > > > > 27 апр. 2020 г., в 19:16, Bruce Momjian > > написал(а): > > > > I have been recommending 1.1 as a value for random_page_cost for > > SSDs for years, and I think it would be helpful to suggest that > > value, so doc patch attached. > > > > -- Bruce Momjian https://momjian.us EnterpriseDB > > https://enterprisedb.com > > > > + As you are, so once was I. As I am, so you will be. + + Ancient > > Roman grave inscription + > -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Roles for pg_basebackup
On Mon, Apr 27, 2020 at 12:16:41PM +0200, Daniel Gustafsson wrote: > Based on a recent conversation about backups I had I propose a small tweak to > the pg_basebackup documentation. Listing the user types in the reverse order > from today, putting superuser last, makes it IMO a little clearer that a > REPLICATION role is preferrable to using a superuser for running backups. Makes sense to me. We do that in logical-replication.sgml as well as pg_rewind.sgml (the latter outlines superuser rights last). Any objections from others? -- Michael signature.asc Description: PGP signature
Re: Roles for pg_basebackup
On 2020/04/28 13:37, Michael Paquier wrote: On Mon, Apr 27, 2020 at 12:16:41PM +0200, Daniel Gustafsson wrote: Based on a recent conversation about backups I had I propose a small tweak to the pg_basebackup documentation. Listing the user types in the reverse order from today, putting superuser last, makes it IMO a little clearer that a REPLICATION role is preferrable to using a superuser for running backups. Makes sense to me. We do that in logical-replication.sgml as well as pg_rewind.sgml (the latter outlines superuser rights last). Seems there are other documentations having the similar description, for example, pg_receivewal.sgml, func.sgml and high-availability.sgml. Isn't it better to update also them at the same time? Any objections from others? No. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
