Re: List of pages from versions 9, 10, and 11 that don't exist in "current"
Thank you Jonathan. Yes good thinking on a thorough way, I may need to go down that route. I hadn't considered entries that exist in new versions but have changed name or URL, glad to hear these might be handled well on the docs themselves soon. I'll consider how to avoid getting in the way there. As a starting point, I remembered that depesz's site has the ability to search release notes between versions. A search for deprecated found me a few more: https://why-upgrade.depesz.com/show?from=9.0&to=12.2&keywords=deprecated Thanks again. On Sat, Apr 25, 2020 at 6:26 PM Jonathan S. Katz wrote: > > On 4/25/20 1:12 PM, Michael Christofides wrote: > > Hi there, > > > > Does anyone have an easy way of seeing which pages from the 9.x, 10, > > or 11 docs don't have a "current" version? > > I don't have an easy way, but I have a pedantic way: > > 1. Set up the pgweb app[1] > 2. Set up the requirements for the docload.py utility > (tools/docs/docload.py) > 3. Download the release source PG12 all the way down. You would really > only need one, likely the latest (e.g. at the time of this writing 12.2, > 11.7, ...) > 4. Load each one into the database. You may need to explicitly create > the "Version" objects in the admin for pgweb > 5. Write SQL to see which filenames are present in an earlier version > but not a later one. > > > For context, I've built a Firefox extension that redirects old > > versions of the docs to their "current" version, except when either: > > * you're already on the docs, or > > * when a "current" version of the page doesn't exist. > > Sounds interesting. There is presently a patch[3] that could/should help > to address this case. The challenge, outside of the file that was the > impetus for the patch, would be finding the forwarding addresses for the > new pages. I believe Step 5 in the above would help with that. > > Thanks! > > Jonathan > > [1] https://www.postgresql.org/developer/related-projects/ > [2] https://www.postgresql.org/ftp/source/ > [3] > https://www.postgresql.org/message-id/4490e710-85f7-87a9-74dd-793d27440bed%40postgresql.org >
Re: [PATCH] Clarified websearch_to_tqsuery syntax in textsearch.sgml
Pavel Borisov writes: > This patch little bit clarifies parsing of operators websearch_to_tqsuery() > function I pushed a version of this. Thanks for noticing the omission. regards, tom lane
Rendering pi more nicely in PDF
In the department of nitpickery ...
"π" renders poorly in our PDF docs: as shown in the attached
screenshot, it doesn't line up on the baseline. I realized that
this is the same problem I'd run into recently with right-arrow,
and it can be solved in the same way, namely we have to specify
use of the symbol font explicitly. So attached is a proposed
patch to fix it.
Use of a new processing-instruction might not be the most elegant
way to do this ... anyone have a better suggestion?
(BTW, I tried to use "π" in the stylesheet files and it
didn't work; apparently that entity isn't loaded yet.)
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index b0afaeb..fdbd4a0 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -1365,7 +1365,7 @@ repeat('Pg', 4) PgPgPgPg
pi ( )
double precision
-Approximate value of π
+Approximate value of
pi()
3.141592653589793
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 58a2aa3..01bec32 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -1528,7 +1528,7 @@ SELECT 4 AS four \; SELECT 5 AS five \aset
pi()
double
- value of the constant PI
+ value of the constant
pi()
3.14159265358979323846
diff --git a/doc/src/sgml/stylesheet-common.xsl b/doc/src/sgml/stylesheet-common.xsl
index b772f87..c9a9181 100644
--- a/doc/src/sgml/stylesheet-common.xsl
+++ b/doc/src/sgml/stylesheet-common.xsl
@@ -108,4 +108,8 @@
+
+
+π
+
diff --git a/doc/src/sgml/stylesheet-fo.xsl b/doc/src/sgml/stylesheet-fo.xsl
index 6797e06..7bfc819 100644
--- a/doc/src/sgml/stylesheet-fo.xsl
+++ b/doc/src/sgml/stylesheet-fo.xsl
@@ -101,6 +101,11 @@
+
+
+ π
+
+
Re: explanation for random_page_cost is outdated
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. Detail: I run the PostgreSQL 11 on an SSD hardware. The database has two small tables with 6MB and 16MB separately. The pgbench runs a select join query in 1 min. The result shows that when the random_page_cost is 1, the average latency is 14ms. When the random_page_cost is 1.5, 2, 3 or 4, the average latency is 26ms. This result suggests that setting random_page_cost to a value larger than 1.5 would cause almost 2x latency. If I increase the 6MB table to 60MB and rerun the sysbench, the result shows that when the random_page_cost is 1, the average latency is 13ms. When the random_page_cost is 1.5,2,3 or 4, the average latency is 17ms. I attached my testing script, the postgresql configuration file, and planner output. On Mon, Apr 27, 2020 at 3:19 AM Олег Самойлов wrote: > Yep. Unclear. What parameter is recommended for SSD? Lower? 3? 2? 1? > > Much better will be write: if you use SSD set 1. > > Олег > > > 19 марта 2020 г., в 23:56, Bruce Momjian написал(а): > > > > On Thu, Feb 27, 2020 at 02:48:44PM +, PG Doc comments form wrote: > >> The following documentation comment has been logged on the website: > >> > >> Page: https://www.postgresql.org/docs/12/runtime-config-query.html > >> Description: > >> > >> Explanation for random_page_cost is rather outdated, because it did > only for > >> case of mechanical hdd. But all modern database servers, which I know, > made > >> upon SSD. Do or not do default value for random_page_cost equal to 1 is > the > >> question, but, IMHO, at list in the documentation about > random_page_cost > >> need to add in a speculation about SSD. > >> > >> It's important because a business programming now is mostly web > programming. > >> Most database is poorly designed by web programmer, tables looked like a > >> primary key and a huge json (containing all) with large gin index upon > it. > >> Now I am seeing a table with a GIN index 50% of the table size. The > database > >> is on SSD, of cause. With default random_page_cost=4 GIN index don't > used > >> by planner, but with random_page_cost=1 the result may be not > excellent, but > >> acceptable for web programmers. > > > > Does this sentence in the random_page_cost docs unclear or not have > enough > > visibility: > > > > > https://www.postgresql.org/docs/12/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS > > > >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. > > > > -- > > 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 + > > > > > > postgresql.conf Description: Binary data query_analytical.sh Description: application/shellscript planner_output Description: Binary data
Re: explanation for random_page_cost is outdated
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. > Detail: > > I run the PostgreSQL 11 on an SSD hardware. The database has two small > tables with 6MB and 16MB separately. The pgbench runs a select join query > in 1 min. The result shows that when the random_page_cost is 1, the average > latency is 14ms. When the random_page_cost is 1.5, 2, 3 or 4, the average > latency is 26ms. This result suggests that setting random_page_cost to a > value larger than 1.5 would cause almost 2x latency. If I increase the 6MB > table to 60MB and rerun the sysbench, the result shows that when the > random_page_cost is 1, the average latency is 13ms. When the > random_page_cost is 1.5,2,3 or 4, the average latency is 17ms. > > I attached my testing script, the postgresql configuration file, and > planner output. > > On Mon, Apr 27, 2020 at 3:19 AM Олег Самойлов wrote: > >> Yep. Unclear. What parameter is recommended for SSD? Lower? 3? 2? 1? >> >> Much better will be write: if you use SSD set 1. >> >> Олег >> >> > 19 марта 2020 г., в 23:56, Bruce Momjian написал(а): >> > >> > On Thu, Feb 27, 2020 at 02:48:44PM +, PG Doc comments form wrote: >> >> The following documentation comment has been logged on the website: >> >> >> >> Page: https://www.postgresql.org/docs/12/runtime-config-query.html >> >> Description: >> >> >> >> Explanation for random_page_cost is rather outdated, because it did >> only for >> >> case of mechanical hdd. But all modern database servers, which I know, >> made >> >> upon SSD. Do or not do default value for random_page_cost equal to 1 >> is the >> >> question, but, IMHO, at list in the documentation about >> random_page_cost >> >> need to add in a speculation about SSD. >> >> >> >> It's important because a business programming now is mostly web >> programming. >> >> Most database is poorly designed by web programmer, tables looked like >> a >> >> primary key and a huge json (containing all) with large gin index upon >> it. >> >> Now I am seeing a table with a GIN index 50% of the table size. The >> database >> >> is on SSD, of cause. With default random_page_cost=4 GIN index don't >> used >> >> by planner, but with random_page_cost=1 the result may be not >> excellent, but >> >> acceptable for web programmers. >> > >> > Does this sentence in the random_page_cost docs unclear or not have >> enough >> > visibility: >> > >> > >> https://www.postgresql.org/docs/12/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS >> > >> >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. >> > >> > -- >> > 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: Rendering pi more nicely in PDF
>From the symbolic unit of the department...
Hello Tom,
26.04.2020 22:13, Tom Lane wrote:
> In the department of nitpickery ...
>
> "π" renders poorly in our PDF docs: as shown in the attached
> screenshot, it doesn't line up on the baseline. I realized that
> this is the same problem I'd run into recently with right-arrow,
> and it can be solved in the same way, namely we have to specify
> use of the symbol font explicitly. So attached is a proposed
> patch to fix it.
>
> 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].
The "phrase" sounds too generic, but it doesn't require yet another
processing instruction e.g. for ∑ or a similar entity.
[1] http://www.sagehill.net/docbookxsl/CustomInlines.html
[2] https://tdg.docbook.org/tdg/4.5/phrase.html
Best regards,
Alexander
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index b0afaebf728..16a4a679d1c 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -1365,7 +1365,7 @@ repeat('Pg', 4) PgPgPgPg
pi ( )
double precision
-Approximate value of π
+Approximate value of π
pi()
3.141592653589793
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 58a2aa3bf20..8c5bf18f79c 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -1528,7 +1528,7 @@ SELECT 4 AS four \; SELECT 5 AS five \aset
pi()
double
- value of the constant PI
+ value of the constant π
pi()
3.14159265358979323846
diff --git a/doc/src/sgml/stylesheet-fo.xsl b/doc/src/sgml/stylesheet-fo.xsl
index 6797e06a77c..3d3ab02ae9a 100644
--- a/doc/src/sgml/stylesheet-fo.xsl
+++ b/doc/src/sgml/stylesheet-fo.xsl
@@ -132,4 +132,8 @@
+
+
+
+
