Re: [DOCS] OS/X startup scripts

[Bruce Momjian]

Patch applied and moved to a separate osx directory.  Thanks.

---


David Fetter wrote:
> Folks,
> 
> The attached tarball should be unpacked in contrib/startup-scripts,
> and supplants PostgreSQL.darwin and StartupParameters.plist.darwin.
> Thanks to Mark Cotner of Reflectr
>  fame for this update :)
> 
> I haven't included the customary diffs.  This points me to some of the
> many deficiencies of CVS, namely that I would need write access in
> order to have it create a diff, and write access is boolean, which
> means that I can't get write access only to the parts of the tree that
> make sense for me to have write access to.
> 
> What say we consider using Git, which includes a CVS interface,
> starting after 8.3 gets out the door?
> 
> Cheers,
> David.
> -- 
> David Fetter <[EMAIL PROTECTED]> http://fetter.org/
> phone: +1 415 235 3778AIM: dfetter666
>   Skype: davidfetter
> 
> Remember to vote!
> Consider donating to PostgreSQL: http://www.postgresql.org/about/donate

[ Attachment, skipping... ]

> 
> ---(end of broadcast)---
> TIP 4: Have you searched our list archives?
> 
>http://archives.postgresql.org

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [DOCS] Documentation of pg_badkend_pid and stats functions

[Bruce Momjian]

Patch applied.  Thanks.

---


Jim Nasby wrote:
> On May 13, 2007, at 6:45 PM, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >> On Sun, May 13, 2007 at 06:48:01PM -0400, Tom Lane wrote:
> >>> Surely a section should not *begin* with a cross-reference to
> >>> someplace else.
> >
> >> My concern is that folks will see the table right below it, not find
> >> what they're looking for there, and move on... what about immediately
> >> after the table?
> >
> > Immediately after is fine with me.  For that matter, you could  
> > probably
> > get away with putting it between the introductory para and the table
> > proper.  I'm just allergic to sections that don't begin with a topic
> > sentence telling you what they are about.
> 
> See attached. I wanted to not put it between the paragraph  
> referencing the table and the table itself, but couldn't think of a  
> better intro paragraph for the section...
[ Attachment, skipping... ]

> 
> --
> Jim Nasby[EMAIL PROTECTED]
> EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)
> 
> 
> 
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining column's datatypes do not
>match

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[DOCS] Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

[Bruce Momjian]

Patch attached and applied.  Thanks.

I added a mention of CLUSTER.

---


Guillaume Cottenceau wrote:
> Dear all,
> 
> After some time spent better understanding how the VACUUM process
> works, what problems we had in production and how to improve our
> maintenance policy[1], I've come up with a little documentation
> patch - basically, I think the documentation under estimates (or
> sometimes misses) the benefit of VACUUM FULL for scans, and the
> needs of VACUUM FULL if the routine VACUUM hasn't been done
> properly since the database was put in production. Find the patch
> against snapshot attached (text not filled, to ease reading). It
> might help others in my situation in the future.
> 

[ Attachment, skipping... ]

> 
> Ref: 
> [1] http://archives.postgresql.org/pgsql-performance/2006-08/msg00419.php
> http://archives.postgresql.org/pgsql-performance/2007-05/msg00112.php
> 
> -- 
> Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent Company
> Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 50 36
> 
> ---(end of broadcast)---
> TIP 6: explain analyze is your friend

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/maintenance.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v
retrieving revision 1.74
diff -c -c -r1.74 maintenance.sgml
*** doc/src/sgml/maintenance.sgml	15 May 2007 15:52:40 -	1.74
--- doc/src/sgml/maintenance.sgml	30 May 2007 19:39:44 -
***
*** 157,163 
  command. This uses a more aggressive algorithm for reclaiming the
  space consumed by dead row versions. Any space that is freed by
  VACUUM FULL is immediately returned to the
! operating system. Unfortunately, this variant of the
  VACUUM command acquires an exclusive lock on
  each table while VACUUM FULL is processing
  it. Therefore, frequently using VACUUM FULL can
--- 157,164 
  command. This uses a more aggressive algorithm for reclaiming the
  space consumed by dead row versions. Any space that is freed by
  VACUUM FULL is immediately returned to the
! operating system, and the table data is physically compacted on
! the disk. Unfortunately, this variant of the
  VACUUM command acquires an exclusive lock on
  each table while VACUUM FULL is processing
  it. Therefore, frequently using VACUUM FULL can
***
*** 168,179 
 
  The standard form of VACUUM is best used with the goal
  of maintaining a fairly level steady-state usage of disk space. 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.
 
  
 
--- 169,184 
 
  The standard form of VACUUM is best used with the goal
  of maintaining a fairly level steady-state usage of disk space. 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. However, if some heavily-updated tables
! have gone too long with infrequent VACUUM, you can
! use VACUUM FULL or CLUSTER to get performance
! back (it is much slower to scan a table containing almost only dead
! rows).
 
  
 
Index: doc/src/sgml/ref/vacuum.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v
retrieving revision 1.47
diff -c -c -r1.47 vacuum.sgml
*** doc/src/sgml/ref/vacuum.sgml	31 Jan 2007 23:26:04 -	1.47
--- doc/src/sgml/ref/vacuum.sgml	30 May 2007 19:39:44 -
***
*** 164,173 
 
  The FULL option is not recommended for routine use,
  but might be useful in special cases.  An example is when you have deleted
! most of the rows in a table and would like the table to physically shrink
! to occupy less disk space.  VACUUM FULL will usually
! shrink the table more than a plain VACUUM would.
! The FULL option does not shrink indexes; a periodic
  REINDEX is still recommended.  In fact, it is often faster
  to drop all indexes, VACUUM FULL, and recreate the indexes.
 
--- 164,174 
 
  The FULL option is not recommended for routine use,