Re: Proposed HTML Documentation Styles
On Thu, 11 Oct 2018 at 06:49, Dean Rasheed wrote: > For example, attached are screenshots taken from my Android tablet For the record, that was a Samsung Galaxy Tab S2 8.0, with a screen resolution of 2048x1536 and a device pixel ratio of 2.0, I think. So the logical resolution is 1024x768, and in portrait mode, the logical width is 768 pixels. Regards, Dean
Re: effective_cache_size
On Thu, Sep 13, 2018 at 03:14:08PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.6/static/runtime-config-query.html > Description: > > Hi, > > The effective_cache_size documentation (section 19.7) is: "When setting this > parameter you should consider both PostgreSQL's shared buffers and the > portion of the kernel's disk cache that will be used for PostgreSQL data > files.". > > This description seems essentially stable since v8.1. > > As far as I understand it means that the value associated to > effective_cache_size is the value of the shared_buffers plus the amount of > memory often used by the kernel for the buffercache (in Linux's parlance). > > This explanation is offered by many published documents, for example > https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server#effective_cache_size > > Alas, this seems different to what B. Momjian declared in 2012 ( > https://www.enterprisedb.com/node/3374 ): "The value doesn't have to be > perfect, but just a rough estimate of how much kernel memory is acting as > secondary cache for the shared buffers.", which (as far as I understand) > means "effective_cache_size = (approx of the often-observed buffercache > size)". > > In the sourcecode v11b3) the module src/backend/utils/misc/guc.c contains > "Sets the planner's assumption about the size of the disk cache. That is, > the portion of the kernel's disk cache that will be used for PostgreSQL data > files." (so effective_cache_size is more or less the "buffercache" size). > However in the module src/backend/optimizer/path/costsize.c a comment states > that 'We also use a rough estimate "effective_cache_size" of the number of > disk pages in Postgres + OS-level disk cache." (so effective_cache_size is > more or less the size of the shared_buffers + the size of the > "buffercache"). > This seems contradictory to me. Sorry for the delay in replying. I think you are 100% correct that there is a problem. The PG 11 docs say: https://www.postgresql.org/docs/11/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS effective_cache_size (integer) Sets the planner's assumption about the effective size of the disk -- cache that is available to a single query. This is factored into - estimates of the cost of using an index; a higher value makes it more likely index scans will be used, a lower value makes it more likely sequential scans will be used. When setting this parameter you should consider both PostgreSQL's shared buffers and the portion of the --- kernel's disk cache that will be used for PostgreSQL data files. Also, --- take into account the expected number of concurrent queries on different tables, since they will have to share the available space. This parameter has no effect on the size of shared memory allocated by PostgreSQL, nor does it reserve kernel disk cache; it is used only for estimation purposes. The system also does not assume data remains in the disk cache between queries. The default is 4 gigabytes (4GB). and the server's description of the parameter is: SELECT extra_desc FROM pg_settings WHERE name = 'effective_cache_size'; extra_desc --- That is, the portion of the kernel's disk cache that will be used for --- PostgreSQL data files. This is measured in disk pages, which are normally 8 kB each. So, there are a few problems here. First, referring to storage as "disk" probably needs to be updated in many places --- for me, "disk" means magnetic disk. SSDs are solid-state _drives_, not _disks_. There is no disk in an SSD. We can call it "drive cache" or "storage cache". Second, and I think this was your point, the server's description of the parameter talks specifically about "kernel's disk cache", while the documentation talks about simply "disk cache", and mentions shared buffers are part of that. Looking at the code, mentions of the C variable effective_cache_size don't add shared buffers to the computation, so the documentation looks to be the most accurate. However, part of the logic is that shared buffers is assumed to be much smaller than the kernel storage cache, _and_ pages in the shared buffers are likely to be also in the kernel storage cache (double-buffering), meaning that the number of data blocks in the shared buffer cache that are not already in the kernel storage cache
Re: please inform data_directory
On Thu, Oct 11, 2018 at 03:50:09PM -0300, Peter Krauss wrote: > Hi, trying to explain again, > the "SHOW data_directory" is an information that not exist in the guide > today, but must to exist... is a suggestion to add information, a > middle-expert > or non-extert reader need it. Uh, add data_directory where? Which guide? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: please inform data_directory
On Thu, Oct 11, 2018 at 03:56:42PM -0300, Peter Krauss wrote: > > The page https://www.postgresql.org/docs/10/static/functions-admin.html > need this information, is like a "pg_read_file Guide". > > > On Thu, Oct 11, 2018 at 3:51 PM Bruce Momjian wrote: > > On Thu, Oct 11, 2018 at 03:50:09PM -0300, Peter Krauss wrote: > > Hi, trying to explain again, > > the "SHOW data_directory" is an information that not exist in the > guide > > today, but must to exist... is a suggestion to add information, a > middle-expert > > or non-extert reader need it. > > Uh, add data_directory where? Which guide? How is this patch adding a mention of the data_directory setting? -- Bruce Momjian http://momjian.us EnterpriseDB http://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/func.sgml b/doc/src/sgml/func.sgml new file mode 100644 index 5193df3..0a5b30a *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml *** postgres=# SELECT * FROM pg_walfile_name *** 20297,20303 The functions shown in provide native access to files on the machine hosting the server. Only files within the ! database cluster directory and the log_directory can be accessed unless the user is granted the role pg_read_server_files. Use a relative path for files in the cluster directory, and a path matching the log_directory --- 20297,20305 The functions shown in provide native access to files on the machine hosting the server. Only files within the ! database cluster directory (see data_directory) ! and the log_directory can be accessed unless the user is granted the role pg_read_server_files. Use a relative path for files in the cluster directory, and a path matching the log_directory
Re: please inform data_directory
Hi, trying to explain again, the "SHOW data_directory" is an information that *not exist in the guide today, *but must to exist... is a suggestion to add information, a middle-expert or non-extert reader need it. On Wed, Oct 10, 2018 at 4:59 PM Bruce Momjian wrote: > On Sun, Sep 9, 2018 at 11:41:36PM +, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/10/static/functions-admin.html > > Description: > > > > It is impossible to use pg_read_file(), etc. functions without > > SHOW data_directory > > What do you mean by that? I can call pg_read_file() before calling > 'SHOW data_directory'. Are you saying that pg_read_file can only read > in the data_directory? It is designed that way. > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + As you are, so once was I. As I am, so you will be. + > + Ancient Roman grave inscription + >
Re: please inform data_directory
The page https://www.postgresql.org/docs/10/static/functions-admin.html need this information, is like a "pg_read_file Guide". On Thu, Oct 11, 2018 at 3:51 PM Bruce Momjian wrote: > On Thu, Oct 11, 2018 at 03:50:09PM -0300, Peter Krauss wrote: > > Hi, trying to explain again, > > the "SHOW data_directory" is an information that not exist in the guide > > today, but must to exist... is a suggestion to add information, a > middle-expert > > or non-extert reader need it. > > Uh, add data_directory where? Which guide? > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + As you are, so once was I. As I am, so you will be. + > + Ancient Roman grave inscription + >
Re: please inform data_directory
On Thu, Oct 11, 2018 at 12:43 PM Peter Krauss wrote: > > The page https://www.postgresql.org/docs/10/static/functions-admin.html > need this information, is like a "pg_read_file Guide". > Applies to all: "The functions shown in Table 9.88 provide native access to files on the machine hosting the server. Only files within the database cluster directory and the log_directory can be accessed. Use a relative path for files in the cluster directory, and a path matching the log_directory configuration setting for log files. Use of these functions is restricted to superusers except where stated otherwise." Applies to pg_read_file: "pg_read_file returns part of a text file, starting at the given offset, returning at most length bytes (less if the end of file is reached first). If offset is negative, it is relative to the end of the file. If offset and length are omitted, the entire file is returned. The bytes read from the file are interpreted as a string in the server encoding; an error is thrown if they are not valid in that encoding." There is nothing unclear there and by the time one gets to this part of the documentation its reasonably assumed they understand "data directory"; being verbose on that point is not an improvement. For the rare person that gets confused these lists are available to obtain clarity. But aside from the one comment I've already made - and this is very minor in nature - I'm not seeing anything obvious short-comings here. David J.
Re: Ambiguous usage of 'any' in explanation
On Sat, Sep 15, 2018 at 11:53:47AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/static/functions-subquery.html > Description: > > Hi. > > The [DOC](https://www.postgresql.org/docs/10/static/functions-subquery.html) > says: > > The result is NULL if the comparison does not return false for any > subquery row > > does *any* mean here: some or all? > > For example in > [MySQL](https://dev.mysql.com/doc/refman/8.0/en/any-in-some-subqueries.html) > I have found this explanation: > > >Use of the word SOME is rare, but this example shows why it might be > useful. To most people, the English phrase “a is not equal to any b” means > “there is no b which is equal to a,” but that is not what is meant by the > SQL syntax. The syntax means “there is some b to which a is not equal.” > Using <> SOME instead helps ensure that everyone understands the true > meaning of the query. I am kind of confused by this report. You mention SOME in the text above, which is a synonym for ANY, but the text you quote: > The result is NULL if the comparison does not return false for any > subquery row is from ALL: The result of ALL is true if the comparison returns true for all subquery rows (including the case where the subquery returns no rows). The result is false if the comparison returns false for any subquery row. The result is NULL if the comparison does not return false for any subquery row, and it returns NULL for at least one row. I see the last line is just trying to negate the line above it, but the mix of "not" and "any" is confusing. I can reword this last line to be: The result is NULL if no comparison with a subquery row returns false, and it returns NULL for at least one row. I can make similar adjustments in other places, and have attached a doc patch. Does that help? -- Bruce Momjian http://momjian.us EnterpriseDB http://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/func.sgml b/doc/src/sgml/func.sgml index 5193df3..183f081 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -15246,7 +15246,7 @@ WHERE EXISTS (SELECT 1 FROM tab2 WHERE col2 = tab1.col2); The result is false if the comparison returns false for every subquery row (including the case where the subquery returns no rows). - The result is NULL if the comparison does not return true for any row, + The result is NULL if no comparison with a subquery row returns true, and it returns NULL for at least one row. @@ -15272,7 +15272,7 @@ WHERE EXISTS (SELECT 1 FROM tab2 WHERE col2 = tab1.col2); The result of ALL is true if all rows yield true (including the case where the subquery returns no rows). The result is false if any false result is found. - The result is NULL if the comparison does not return false for any row, + The result is NULL if no comparison with a subquery row returns false, and it returns NULL for at least one row. @@ -15302,8 +15302,8 @@ WHERE EXISTS (SELECT 1 FROM tab2 WHERE col2 = tab1.col2); case where the subquery returns no rows). The result is false if the comparison returns false for any subquery row. - The result is NULL if the comparison does not return false for any - subquery row, and it returns NULL for at least one row. + The result is NULL if no comparison with a subquery row returns false, + and it returns NULL for at least one row.
Re: Ambiguous usage of 'any' in explanation
On Thursday, October 11, 2018, Bruce Momjian wrote: > > The result is NULL if no comparison with a subquery row returns > false, and it returns NULL for at least one row. > > I can make similar adjustments in other places, and have attached a doc > patch. Does that help? > +1 David J.
Re: Proposed HTML Documentation Styles
Hi Dean, On 10/11/18 3:01 AM, Dean Rasheed wrote: > On Thu, 11 Oct 2018 at 06:49, Dean Rasheed wrote: >> For example, attached are screenshots taken from my Android tablet > > For the record, that was a Samsung Galaxy Tab S2 8.0, with a screen > resolution of 2048x1536 and a device pixel ratio of 2.0, I think. So > the logical resolution is 1024x768, and in portrait mode, the logical > width is 768 pixels. Unfortunately HTML tables are not great in mobile web. With that said, we pushed up a change that should keep them from exploding as much to the right. We've also bumped up the font-size slightly from the current site so they could be slightly easier to read. (Note: when testing in the browser, they appear to be illegible unless you have super vision, but when on an actual device they are legible). There is only so much we can do now without redesigning how the tables are assembled. Thanks again for your feedback! Best, Jonathan signature.asc Description: OpenPGP digital signature
