Re: [PATCHES] improve routine vacuuming docs
Robert Treat <[EMAIL PROTECTED]> writes: > Should be "TRUNCATE removes the entire content of > the table immediately, without requiring a subsequent > VACUUM or VACUUM FULL to > reclaim the now-unused disk space." I think the is overkill, but otherwise I've made this change. > Maybe better is ..."risk of OID wraparound failures". Why? XID wraparound and OID wraparound are completely distinct issues. I think from the context it's pretty clear that XID wraparound is what is being referred to here. > What differentiates the first SELECT as a command and the second > SELECT as a literal? Some question for CASE really... Well, the rule-of-thumb is that SQL commands are marked with , but clauses of commands or entire example queries are marked with . I think the CASE is correct, but on closer examination, the second SELECT should probably also be marked with . I've attached a revised patch that incorporates these changes. Thanks for the feedback! -Neil Index: doc/src/sgml/maintenance.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/maintenance.sgml,v retrieving revision 1.29 diff -c -r1.29 maintenance.sgml *** doc/src/sgml/maintenance.sgml 29 Nov 2003 19:51:37 - 1.29 --- doc/src/sgml/maintenance.sgml 11 Dec 2003 17:05:41 - *** *** 87,93 of VACUUM can run in parallel with normal database operations (selects, inserts, updates, deletes, but not changes to table definitions). Routine vacuuming is therefore not nearly as intrusive as it was in prior !releases, and it's not as critical to try to schedule it at low-usage times of day. --- 87,93 of VACUUM can run in parallel with normal database operations (selects, inserts, updates, deletes, but not changes to table definitions). Routine vacuuming is therefore not nearly as intrusive as it was in prior !releases, and it is not as critical to try to schedule it at low-usage times of day. *** *** 115,121 Clearly, a table that receives frequent updates or deletes will need to be vacuumed more often than tables that are seldom updated. It may be useful to set up periodic cron tasks that ! vacuum only selected tables, skipping tables that are known not to change often. This is only likely to be helpful if you have both large heavily-updated tables and large seldom-updated tables --- the extra cost of vacuuming a small table isn't enough to be worth --- 115,121 Clearly, a table that receives frequent updates or deletes will need to be vacuumed more often than tables that are seldom updated. It may be useful to set up periodic cron tasks that ! VACUUM only selected tables, skipping tables that are known not to change often. This is only likely to be helpful if you have both large heavily-updated tables and large seldom-updated tables --- the extra cost of vacuuming a small table isn't enough to be worth *** *** 123,161 ! The standard form of VACUUM is best used with the goal of ! maintaining a fairly level steady-state usage of disk space. The standard ! form finds old row versions and makes their space available for re-use within ! the table, but it does not try very hard to shorten the table file and ! return disk space to the operating system. If you need to return disk ! space to the operating system you can use VACUUM FULL --- ! but what's the point of releasing disk space that will only have to be ! allocated again soon? Moderately frequent standard VACUUM runs ! are a better approach than infrequent VACUUM FULL runs for ! maintaining heavily-updated tables. Recommended practice for most sites is to schedule a database-wide ! VACUUM once a day at a low-usage time of day, supplemented ! by more frequent vacuuming of heavily-updated tables if necessary. ! (If you have multiple databases in a cluster, don't forget to ! vacuum each one; the program vacuumdb may be helpful.) ! Use plain VACUUM, not VACUUM FULL, for routine ! vacuuming for space recovery. ! VACUUM FULL is recommended for cases where you know you have ! deleted the majority of rows in a table, so that the steady-state size ! of the table can be shrunk substantially with VACUUM FULL's ! more aggressive approach. ! If you have a table whose contents are deleted completely every so often, ! consider doing it with TRUNCATE rather than using ! DELETE followed by VACUUM. --- 123,191 ! There are two variants of the VACUUM ! command. The first form, known as lazy vacuum or ! just VACUUM, marks expired data in tables and ! indexes for future reuse; it does not attempt ! to reclaim the space used by this expired d
[PATCHES] initdb italian translation
This is an initial italian translation for initdb. It still isn't complete. Regards, Fabrizio Mazzoni initdb-it.po Description: Binary data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] make "wal_debug" GUC var a boolean
The "wal_debug" GUC variable was of type "integer", but it was used in the code effectively as a boolean: the code only tested whether it was zero or non-zero. This patch makes it a proper boolean. -Neil Index: doc/src/sgml/runtime.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.226 diff -c -r1.226 runtime.sgml *** doc/src/sgml/runtime.sgml 6 Dec 2003 23:10:23 - 1.226 --- doc/src/sgml/runtime.sgml 11 Dec 2003 18:46:14 - *** *** 2667,2676 ! wal_debug (integer) ! If nonzero, turn on WAL-related debugging output. --- 2667,2676 ! wal_debug (boolean) ! If true, emit WAL-related debugging output. Index: doc/src/sgml/wal.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/wal.sgml,v retrieving revision 1.26 diff -c -r1.26 wal.sgml *** doc/src/sgml/wal.sgml 29 Nov 2003 19:51:38 - 1.26 --- doc/src/sgml/wal.sgml 11 Dec 2003 18:50:06 - *** *** 19,28 transaction processing. Briefly, WAL's central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged, !that is, when log records have been flushed to permanent !storage. If we follow this procedure, we do not need to flush !data pages to disk on every transaction commit, because we know !that in the event of a crash we will be able to recover the database using the log: any changes that have not been applied to the data pages will first be redone from the log records (this is roll-forward recovery, also known as REDO) and then changes made by --- 19,28 transaction processing. Briefly, WAL's central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged, !that is, when log records describing the changes have been flushed !to permanent storage. If we follow this procedure, we do not need !to flush data pages to disk on every transaction commit, because we !know that in the event of a crash we will be able to recover the database using the log: any changes that have not been applied to the data pages will first be redone from the log records (this is roll-forward recovery, also known as REDO) and then changes made by *** *** 187,193 There will be at least one 16 MB segment file, and will normally not be more than 2 * checkpoint_segments + 1 !files. You can use this to estimate space requirements for WAL. Ordinarily, when old log segment files are no longer needed, they are recycled (renamed to become the next segments in the numbered sequence). If, due to a short-term peak of log output rate, there --- 187,193 There will be at least one 16 MB segment file, and will normally not be more than 2 * checkpoint_segments + 1 !files. You can use this to estimate space requirements for WAL. Ordinarily, when old log segment files are no longer needed, they are recycled (renamed to become the next segments in the numbered sequence). If, due to a short-term peak of log output rate, there *** *** 254,260 The wal_sync_method parameter determines how PostgreSQL will ask the kernel to force ! WAL updates out to disk. All the options should be the same as far as reliability goes, but it's quite platform-specific which one will be the fastest. Note that this parameter is irrelevant if fsync --- 254,260 The wal_sync_method parameter determines how PostgreSQL will ask the kernel to force ! WAL updates out to disk. All the options should be the same as far as reliability goes, but it's quite platform-specific which one will be the fastest. Note that this parameter is irrelevant if fsync *** *** 262,272 !Setting the wal_debug parameter to any nonzero !value will result in each LogInsert and LogFlush WAL call being !logged to the server log. At present, it makes no difference what !the nonzero value is. This option may be replaced by a more general mechanism in the future. --- 262,271 !Enabling the wal_debug configuration parameter !will result in each LogInsert and LogFlush WAL call being !logged to the server log. This option may be replaced by a more general mechanism in the future. Index: doc/src/sgml/ref/show.sgml === RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/show.sgml,v retrieving revision 1.3
Re: [PATCHES] psql-current italian translation updates
[EMAIL PROTECTED] wrote: > Updated italian po file for psql-current. This work is pretty much wasted at this time, because we're about one year away from making a new release, and who knows what will be changed until then. I recommend that you concentrate on finishing the translations in the 7.4 branch first. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] initdb italian translation
[EMAIL PROTECTED] wrote: > his is an initial italian translation for initdb. It still isn't > complete. Installed. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] fix vpath doc builds
Neil Conway wrote: > At present, trying to build the documentation from outside the source > tree (i.e. a "vpath build") fails. This patch fixes that. Two changes > were required: Patch installed. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] YA Doc patch
David Fetter wrote: > I hope this one actually does what Tom said. It appears to work :) Probably, but that does not seem to be the right place in the documentation for this. The location you propose explains EXTRACT, and we should leave it at that. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] improvements to SGML
Neil Conway wrote: > This patch makes some editorial improvements to the bug reporting > guidelines and the LOCK reference page. Looks good, but did you have a specific reason to prefer LOCK TABLE over plain LOCK? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] improve routine vacuuming docs
Neil Conway wrote: > This patch makes some improvements and adds some details to the > documentation on routine database maintenance activities. Any > comments on the new text would be appreciated. It's kind of hard to see what you have really changed. Can you provide a summary? > I also corrected a bunch of instances of SGML usage. One of these > days I'll get around to writing a style guide for the PostgreSQL SGML > docs... Please do. But note that the first thing I'd add to such a document would be not to write things like that: You should VACUUM your database every day. Instead, either write You should vacuum your database every day. or You should run the command VACUUM in your database every day. If you need a verb, write a verb; don't abuse nouns. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] make "wal_debug" GUC var a boolean
Neil Conway wrote: > The "wal_debug" GUC variable was of type "integer", but it was used > in the code effectively as a boolean: the code only tested whether it > was zero or non-zero. This patch makes it a proper boolean. I agree with this, but would it be possible to fold it into the normal debug output mechanisms? I don't think debugging WAL is any more important nowadays than any other component. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
