Make 'Genetic Algorithm' a real figure
Currently the 'figure' of a genetic algorithm is created with some kind
of 'ascii art'. The patch makes it a real figure.
Kind regards
Jürgen Purtz
diff --git a/doc/src/sgml/geqo.sgml b/doc/src/sgml/geqo.sgml
index 5120dfbb42..5a52fb46db 100644
--- a/doc/src/sgml/geqo.sgml
+++ b/doc/src/sgml/geqo.sgml
@@ -84,7 +84,8 @@
Through simulation of the evolutionary operations recombination,
mutation, and
selection new generations of search points are found
-that show a higher average fitness than their ancestors.
+that show a higher average fitness than their ancestors.
+illustrates in which order and how long the three steps are processed.
@@ -94,48 +95,13 @@
non-random (better than random).
-
-Structured Diagram of a Genetic Algorithm
-
-
-
-
-
-P(t)
-generation of ancestors at a time t
-
-
-
-P''(t)
-generation of descendants at a time t
-
-
-
-
-
-
-+=+
-|>>> Algorithm GA <<|
-+=+
-| INITIALIZE t := 0 |
-+=+
-| INITIALIZE P(t) |
-+=+
-| evaluate FITNESS of P(t)|
-+=+
-| while not STOPPING CRITERION do |
-| +-+
-| | P'(t) := RECOMBINATION{P(t)} |
-| +-+
-| | P''(t) := MUTATION{P'(t)} |
-| +-+
-| | P(t+1) := SELECTION{P''(t) + P(t)} |
-| +-+
-| | evaluate FITNESS of P''(t) |
-| +-+
-| | t := t + 1 |
-+===+=+
-
+
+Structure of a Genetic Algorithm
+
+
+
+
+
diff --git a/doc/src/sgml/images/Makefile b/doc/src/sgml/images/Makefile
index 1e7993020b..f9e356348b 100644
--- a/doc/src/sgml/images/Makefile
+++ b/doc/src/sgml/images/Makefile
@@ -3,6 +3,7 @@
# see README in this directory about image handling
ALL_IMAGES = \
+ genetic-algorithm.svg \
gin.svg \
pagelayout.svg
diff --git a/doc/src/sgml/images/genetic-algorithm.gv b/doc/src/sgml/images/genetic-algorithm.gv
index e69de29bb2..170cc9ee28 100644
--- a/doc/src/sgml/images/genetic-algorithm.gv
+++ b/doc/src/sgml/images/genetic-algorithm.gv
@@ -0,0 +1,44 @@
+digraph {
+layout=dot;
+splines=ortho;
+nodesep=0.3;
+ranksep=0.3;
+node [shape=box; width=2.2; fontsize=8];
+pad="1.0, 0.5";
+bgcolor=grey95;
+
+// title
+// label="Structure of a Genetic Algorithm" fontsize=26;
+
+
+// nodes
+a1[label="INITIALIZE t := 0"];
+a2[label="INITIALIZE P(t)"];
+a3[label="evaluate FITNESS of P(t)"];
+a4[shape="diamond", label="STOPPING CRITERION"; width=4];
+
+// connect 'end' node with 'a9' node (bottom of figure)
+{
+ rank=same;
+ a9[label="t := t + 1"];
+ // end-symbol similar to UML notation
+ end[shape=doublecircle; label="end"; width=0.5];
+}
+
+a5[label="P'(t) := RECOMBINATION{P(t)}"];
+a6[label="P''(t) := MUTATION{P'(t)}"];
+a7[label="P(t+1) := SELECTION{P''(t) + P(t)}"];
+a8[label="evaluate FITNESS of P''(t)"];
+
+// edges
+a1 -> a2 -> a3 -> a4;
+a4 -> a5[xlabel="false "; fontsize=10];
+a4 -> end[xlabel="true "; fontsize=10];
+a5 -> a6 -> a7 -> a8 -> a9;
+a4 -> a9 [dir=back]; // forces 'true'-edge to right side of figure
+
+// explain the notation
+expl [shape=plaintext; fontsize=10; width=3.2;
+ label="P(t) generation of ancestors at a time t\nP''(t) generation of descendants at a time t"];
+
+}
diff --git a/doc/src/sgml/images/genetic-algorithm.svg b/doc/src/sgml/images/genetic-algorithm.svg
index e69de29bb2..2db8bef230 100644
--- a/doc/src/sgml/images/genetic-algorithm.svg
+++ b/doc/src/sgml/images/genetic-algorithm.svg
@@ -0,0 +1,139 @@
+
+
+
+http://www.w3.org/2000/svg"; xmlns:xlink="http://www.w3.org/1999/xlink"; width="619pt" height="580pt" viewBox="0.00 0.00 619.00 580.00">
+
+%3
+
+
+
+a1
+
+INITIALIZE t := 0
+
+
+
+a2
+
+INITIALIZE P(t)
+
+
+
+a1->a2
+
+
+
+
+
+a3
+
+evaluate FITNESS of P(t)
+
+
+
+a2->a3
+
+
+
+
+
+a4
+
+STOPPING CRITERION
+
+
+
+a3->a4
+
+
+
+
+
+a9
+
+t := t + 1
+
+
+
+a4->a9
+
+
+
+
+
+end
+
+
+end
+
+
+
+a4->end
+
+
+true Â
+
+
+
+a5
+
+P'(t) := RECOMBINATION{P(t)}
+
+
+
+a4->a5
+
+
+false  Â
+
+
+
+a6
+
+P''(t) := MUTATION{P'(t)}
+
+
+
+a5->a6
+
+
+
+
+
+a7
+
+P(t+1) := SELECTION{P''(t) + P(t)}
+
+
+
+a6->a7
+
+
+
+
+
+a8
+
+evaluate FITNESS of P''(t)
+
+
+
+a7->a8
+
+
+
+
+
+a8->a9
+
+
+
Ambiguous language in Table 8.13. Special Date/Time Inputs
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/datatype-datetime.html Description: In Table 8.13. Special Date/Time Inputs, the description for the special values 'today', 'tomorrow' and 'yesterday' uses the word 'midnight' e.g. the special value 'today' is defined as 'midnight today'. I propose that the word 'midnight' is ambiguous, because it can be interpreted either as midnight at the start of the day in question, or midnight at the end of the day. This ambiguity can be avoided if 'midnight' is replaced by '00:00:00', or better, '00:00:00 local time'. Astronomers have deprecated the word 'midnight' for many years precisely to avoid this ambiguity. David Harper Senior DBA (and former astronomer) Wellcome Sanger Institute Cambridge, England
Re: TOC: List of Figures
On 2019-07-08 07:20, Jürgen Purtz wrote: > To support the didactic method of media changes we > should promote graphics with a summarizing list at a prominent place in > front of the manual. This would make sense if we had fifty images spread evenly throughout the documentation, or moreover, we had an image for every topic. Then learning by just flipping through the images would be interesting. But we are not nearly there yet. Promoting a list of images now would just make those looking for that kind of learning sad. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: TOC: List of Figures
> On 8 Jul 2019, at 21:43, Peter Eisentraut > wrote: > > On 2019-07-08 07:20, Jürgen Purtz wrote: >> To support the didactic method of media changes we >> should promote graphics with a summarizing list at a prominent place in >> front of the manual. > > This would make sense if we had fifty images spread evenly throughout > the documentation, or moreover, we had an image for every topic. Then > learning by just flipping through the images would be interesting. But > we are not nearly there yet. Promoting a list of images now would just > make those looking for that kind of learning sad. We regularly include scaffolding for things to come in Postgres, I don’t see this being much different. It will have just a few images now, but by the time v13 ships we are likely to have a longer list which increase the value of this further. cheers ./daniel
Re: TOC: List of Figures
Daniel Gustafsson writes: >> On 8 Jul 2019, at 21:43, Peter Eisentraut >> wrote: >> This would make sense if we had fifty images spread evenly throughout >> the documentation, or moreover, we had an image for every topic. Then >> learning by just flipping through the images would be interesting. But >> we are not nearly there yet. Promoting a list of images now would just >> make those looking for that kind of learning sad. > We regularly include scaffolding for things to come in Postgres, I don’t see > this being much different. It will have just a few images now, but by the > time > v13 ships we are likely to have a longer list which increase the value of this > further. I tend to agree with Peter's argument here --- let's wait till there's a meaningful number of figures and then reconsider whether there's use in a list of them. It's not like it will be any harder to make that change in a year or two than it is today. regards, tom lane
Re: TOC: List of Figures
> On 8 Jul 2019, at 22:10, Tom Lane wrote: > let's wait till there's a > meaningful number of figures and then reconsider whether there's use in > a list of them. It's not like it will be any harder to make that change > in a year or two than it is today. In that case, let’s record this in the commitfest app and punt it forwards towards the release as the CFs move along so we don’t forget to re-evaluate in the last commitfest before 13. cheers ./daniel
Re: TOC: List of Figures
On 7/8/19 4:21 PM, Daniel Gustafsson wrote: >> On 8 Jul 2019, at 22:10, Tom Lane wrote: > >> let's wait till there's a >> meaningful number of figures and then reconsider whether there's use in >> a list of them. It's not like it will be any harder to make that change >> in a year or two than it is today. > > In that case, let’s record this in the commitfest app and punt it forwards > towards the release as the CFs move along so we don’t forget to re-evaluate in > the last commitfest before 13. Done[1]. Jonathan [1] https://commitfest.postgresql.org/24/2204/ signature.asc Description: OpenPGP digital signature
Re: Postgres 11: Table Partitioning and Primary Keys
On Fri, Jul 5, 2019 at 09:20:07PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/11/ddl-partitioning.html
> Description:
>
> In the documentation for Postgres 11 table partitioning, there is no mention
> of the requirement that the Primary Key of a partitioned table must contain
> the partition key.
> In fact the documentation on primary keys is so light that I am not even
> 100% sure the above is correct. If the following table is not possible in
> Postgres 11, the documentation should find some way to make that clear.
>
> -- Create partitioned table with partition key not in primary key
> create table events (
> id bigint not null default nextval('events_id_seq'),
> created_date timestamp not null,
> constraint events_pk primary key (id)
> ) partition by range (created_date);
> -- end create table
>
> I believe this should be documented in section "5.10.2.3. Limitations"
Can someone comment on this? CC to hackers.
--
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: Postgres 11: Table Partitioning and Primary Keys
On Mon, Jul 08, 2019 at 10:37:37PM -0400, Bruce Momjian wrote: > On Fri, Jul 5, 2019 at 09:20:07PM +, PG Doc comments form wrote: >> In the documentation for Postgres 11 table partitioning, there is no mention >> of the requirement that the Primary Key of a partitioned table must contain >> the partition key. >> In fact the documentation on primary keys is so light that I am not even >> 100% sure the above is correct. If the following table is not possible in >> Postgres 11, the documentation should find some way to make that clear. >> >> I believe this should be documented in section "5.10.2.3. Limitations" > > Can someone comment on this? CC to hackers. Yep, that's the case: =# CREATE TABLE parent_tab (id int, id2 int primary key) PARTITION BY RANGE (id); ERROR: 0A000: insufficient columns in PRIMARY KEY constraint definition DETAIL: PRIMARY KEY constraint on table "parent_tab" lacks column "id" which is part of the partition key. LOCATION: DefineIndex, indexcmds.c:894 I agree with the report here that adding one sentence to 5.10.2.3 which is for the limitations of declarative partitioning would be a good idea. We don't mention the limitation in CREATE TABLE either (which would be rather incorrect IMO). Attached is an idea of patch for the documentation, using this wording: + + + When defining a primary key on a partitioned table, the primary + key column must be included in the partition key. + + If somebody has any better idea for that paragraph, please feel free. -- Michael signature.asc Description: PGP signature
Re: Postgres 11: Table Partitioning and Primary Keys
Michael Paquier writes: > Attached is an idea of patch for the documentation, using this > wording: > + > + > + When defining a primary key on a partitioned table, the primary > + key column must be included in the partition key. > + > + Isn't it the other way around, that the partition key column(s) must be included in the primary key? Maybe I'm confused, but it seems like we couldn't enforce PK uniqueness otherwise. regards, tom lane
Re: Postgres 11: Table Partitioning and Primary Keys
On Mon, Jul 8, 2019 at 7:59 PM Michael Paquier wrote: > Attached is an idea of patch for the documentation, using this > wording: > + > + > + When defining a primary key on a partitioned table, the primary > + key column must be included in the partition key. > + > + > If somebody has any better idea for that paragraph, please feel free. > Reads a bit backward. How about: "As uniqueness can only be enforced within an individual partition when defining a primary key on a partitioned table all columns present in the partition key must also exist in the primary key." David J.
Re: Ambiguous language in Table 8.13. Special Date/Time Inputs
On Mon, Jul 8, 2019 at 10:07:59AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/datatype-datetime.html > Description: > > In Table 8.13. Special Date/Time Inputs, the description for the special > values 'today', 'tomorrow' and 'yesterday' uses the word 'midnight' e.g. the > special value 'today' is defined as 'midnight today'. I propose that the > word 'midnight' is ambiguous, because it can be interpreted either as > midnight at the start of the day in question, or midnight at the end of the > day. This ambiguity can be avoided if 'midnight' is replaced by '00:00:00', > or better, '00:00:00 local time'. Astronomers have deprecated the word > 'midnight' for many years precisely to avoid this ambiguity. Uh, I believe midnight is always the start of the day. I think 00:00:00 looks awkward. -- 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: Postgres 11: Table Partitioning and Primary Keys
On Tue, Jul 9, 2019 at 8:29 AM Michael Paquier wrote: > On Mon, Jul 08, 2019 at 10:37:37PM -0400, Bruce Momjian wrote: > > On Fri, Jul 5, 2019 at 09:20:07PM +, PG Doc comments form wrote: > >> In the documentation for Postgres 11 table partitioning, there is no > mention > >> of the requirement that the Primary Key of a partitioned table must > contain > >> the partition key. > >> In fact the documentation on primary keys is so light that I am not even > >> 100% sure the above is correct. If the following table is not possible > in > >> Postgres 11, the documentation should find some way to make that > clear. > >> > >> I believe this should be documented in section "5.10.2.3. Limitations" > > > > Can someone comment on this? CC to hackers. > > Yep, that's the case: > =# CREATE TABLE parent_tab (id int, id2 int primary key) > PARTITION BY RANGE (id); > ERROR: 0A000: insufficient columns in PRIMARY KEY constraint > definition > DETAIL: PRIMARY KEY constraint on table "parent_tab" lacks column > "id" which is part of the partition key. > LOCATION: DefineIndex, indexcmds.c:894 > same is valid for UNIQUE constraint also. postgres=# CREATE TABLE parent_tab (id int, id2 int unique) PARTITION BY RANGE (id); ERROR: insufficient columns in UNIQUE constraint definition DETAIL: UNIQUE constraint on table "parent_tab" lacks column "id" which is part of the partition key. > > I agree with the report here that adding one sentence to 5.10.2.3 > which is for the limitations of declarative partitioning would be a > good idea. We don't mention the limitation in CREATE TABLE either > (which would be rather incorrect IMO). > > Attached is an idea of patch for the documentation, using this > wording: > + > + > + When defining a primary key on a partitioned table, the primary > + key column must be included in the partition key. > + > + > If somebody has any better idea for that paragraph, please feel free. > -- > Michael >
Re: Postgres 11: Table Partitioning and Primary Keys
On Mon, Jul 08, 2019 at 08:12:18PM -0700, David G. Johnston wrote: > Reads a bit backward. How about: > > "As uniqueness can only be enforced within an individual partition when > defining a primary key on a partitioned table all columns present in the > partition key must also exist in the primary key." Yes, I was not really inspired on this one. Looking closely at the code in DefineIndex() (and as Rajkumar has mentioned upthread for unique constraints) this can happen for primary keys, unique constraints and exclusion constraints. So we had better mention all three of them. I am not sure that we need to be explicit about the uniqueness part though, let's say the following: "When defining a primary key, a unique constraint or an exclusion constraint on a partitioned table, all the columns present in the constraint definition must be included in the partition key." -- Michael signature.asc Description: PGP signature
Re: Postgres 11: Table Partitioning and Primary Keys
On Mon, Jul 08, 2019 at 11:10:51PM -0400, Tom Lane wrote: > Isn't it the other way around, that the partition key column(s) must > be > included in the primary key? Maybe I'm confused, but it seems like > we couldn't enforce PK uniqueness otherwise. Yes you are right. The full column list of the partition key needs to be included in the constraint, but that's not true the other way around. -- Michael signature.asc Description: PGP signature
Re: Postgres 11: Table Partitioning and Primary Keys
On Tue, Jul 09, 2019 at 03:34:48PM +0900, Michael Paquier wrote: > Looking closely at the code in DefineIndex() (and as Rajkumar has > mentioned upthread for unique constraints) this can happen for primary > keys, unique constraints and exclusion constraints. So we had better > mention all three of them. I am not sure that we need to be explicit > about the uniqueness part though, let's say the following: > "When defining a primary key, a unique constraint or an exclusion > constraint on a partitioned table, all the columns present in the > constraint definition must be included in the partition key." Let's try again that (that's a long day..): "When defining a primary key, a unique constraint or an exclusion constraint on a partitioned table, all the columns present in the partition key must be included in the constraint definition." -- Michael signature.asc Description: PGP signature
