Re: Another pg_dump using split and gzip for large databases
On Sat, Jul 17, 2021 at 03:09:52PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/backup-dump.html > Description: > > pg_dump ccbank | split -b 2048m --filter='gzip > $FILE.gz' Wow, odd we didn't have an example of using gzip and split together; patch attached. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion. diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index 8c9186d277..96e7f06485 100644 --- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -273,10 +273,10 @@ cat filename.gz | gunzip | psql split command allows you to split the output into smaller files that are acceptable in size to the underlying file system. For example, to - make chunks of 1 megabyte: + make 2 gigabyte chunks: -pg_dump dbname | split -b 1m - filename +pg_dump dbname | split -b 2G - filename Reload with: @@ -284,6 +284,14 @@ pg_dump dbname | split -b 1m - cat filename* | psql dbname + + It is possible to use split and gzip: + + +pg_dump dbname | split -b 2G --filter='gzip > $FILE.gz' + + + It can be restored using zcat.
Re: Indexes on Expressions - a note to remind users to run ANALYZE after creation
On Mon, Jul 19, 2021 at 12:59:10PM +0200, Laurenz Albe wrote: > On Fri, 2021-07-16 at 22:00 -0700, Nikolay Samokhvalov wrote: > > diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml > > index > > 671299ff059d972ff95bdb1d67ed4c89bf5040b2..c7eaf9a608e995ef9957b4e0f677b36a8303be55 > > 100644 > > --- a/doc/src/sgml/indices.sgml > > +++ b/doc/src/sgml/indices.sgml > > @@ -741,6 +741,15 @@ CREATE INDEX people_names ON people ((first_name || ' > > ' || last_name)); > > query. Thus, indexes on expressions are useful when retrieval speed > > is more important than insertion and update speed. > > > > + > > + > > + Note > > + > > +Once an index on an expression is successfully created, it is > > important to > > +run ANALYZE on the corresponding table to gather > > +statistics for the expression. > > + > > + > > > > I agree in principle. It should be "has been created" rather than "is > created", > and I would say something less drastic like "usually a good idea" rather than > "important". Uh, CREATE INDEX already has this mentioend: The system regularly collects statistics on all of a table's columns. Newly-created non-expression indexes can immediately use these statistics to determine an index's usefulness. For new expression indexes, it is necessary to run ANALYZE or wait for the autovacuum daemon to analyze the table to generate statistics for these indexes. Do we need it here too? -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
Re: Logical error
On Fri, Jul 16, 2021 at 02:18:11PM -0500, Doug Tracy wrote: > > > From the URL https://www.postgresql.org/files/documentation/pdf/12/ > postgresql-12-A4.pdf > > Page xxxi > > PostgreSQL is an object-relational database management system (ORDBMS) based > on > POSTGRES, Version 4.21 > > Page 7 > > 2.2. Concepts > > PostgreSQL is a relational database management system (RDBMS) Uh, the first mention is talking about the object-relational aspects of Postgres, while the second is talking about the pure relational parts --- not sure if this can be improved. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
Re: Logical error
On Wed, Jul 28, 2021 at 6:12 PM Bruce Momjian wrote: > On Fri, Jul 16, 2021 at 02:18:11PM -0500, Doug Tracy wrote: > > > > > > From the URL https://www.postgresql.org/files/documentation/pdf/12/ > > postgresql-12-A4.pdf > > > > Page xxxi > > > > PostgreSQL is an object-relational database management system (ORDBMS) > based on > > POSTGRES, Version 4.21 > > > > Page 7 > > > > 2.2. Concepts > > > > PostgreSQL is a relational database management system (RDBMS) > > Uh, the first mention is talking about the object-relational aspects of > Postgres, while the second is talking about the pure relational parts > --- not sure if this can be improved. > > The first mention is talking about the history of the project but clearly defines, as part of its history, that PostgreSQL is an "Object-Relational DBMS". However, when we go into describing concepts we forget about the "Object" part of what we are and just focus on the relational side. This omission seems fairly readily corrected if the "Object" part of our ORDBMS identity is truly something we wish to identify with and claim is different from just being an "RDBMS". It could go something like: PostgreSQL is an Object-Relational Database Management System. This is actually two separate concepts melded into a single implementation. The more well-known aspect of this is being a "Relational Database Management System". (the rest of the existing concept page does indeed then go one to describe what this means in terms of features). The reason we add "Object" to this is that our system is readily extensible through the creation of user-defined objects. The most common of these are functions and procedures, (blah blah blah)... I haven't gone looking beyond the two sections pointed out in this thread but the observation that our non-frontmatter material ignores the "object" part of our "object-relational" classification seems to have merit. David J.
