Re: [DOCS] vacuum and routine maintenance docs
On Wed, 2006-01-18 at 17:24 -0800, Joshua D. Drake wrote: > Why is Managing Database and Routine Database Management separate? I assume you mean the "Managing Databases" and "Routine Database Maintenance Tasks" chapters. I think these chapters are separate because they address fairly different subject matter. You could call the latter chapter "Routine Maintenance Tasks" without loss of meaning, as it doesn't focus on maintaining individual databases per se. > Server configuration is kind of vague... Perhaps PostgreSQL > configuration? Personally I don't think that's an improvement, although I'm not completely satisfied with "Server Configuration" either. > But then why isn't that under Managing Databases :) Because that chapter describes managing individual databases and tablespaces, not an entire PostgreSQL instance. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] vacuum and routine maintenance docs
On Wed, 2006-01-18 at 19:31, Jim C. Nasby wrote: > On Wed, Jan 18, 2006 at 08:19:16PM -0500, Tom Lane wrote: > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > > I'm wondering if people feel this is an issue with the docs in general > > > and isn't limited to just the admin stuff? > > > > Probably, but the admin stuff seems to suffer worst. In any case, Scott > > volunteered to look at redoing that part, and I'm not going to repay the > > offer by asking him to redo the whole manual ;-) > > Certainly true. :) But if we're going to start at an outline level I > think it would be enlightening to do a short (as in only 2 levels deep) > re-outline of all the docs and see how it compares to what we have. It > would at least indicate things that should be wholesale moved out of the > admin section... > > Plus hopefully we could get others to help. :) I'd certainly lend a > hand. > > Is there an easy way to get a 2-level outline out of the sgml? I agree completely. We don't probably need it in sgml just yet. From a 40,000 ft perspective, we can break administration up into several large chunks, and then decide what needs to go in each. The general "big topics" we already have seem pretty serviceable. However, I tend to think of OS env and server config as being sub topics under installation. Under that, we can put the individual subjects accordingly. - Installation -- Documentation scope specification -- Preparation (setting objectives for the installation) -- Hardware considerations (emphasizing things like fsyncing and all) -- OS configuration (i.e. shared memory) -- Software installation (source versus rpm versus pkg etc.) -- Cluster initialization (localization issues, location, etc...) -- Server configuration (i.e. pg_hba / postgresql.conf et. al.) -- Running the server (start up scripts, by hand, etc.) -- Verifying server operation (regression tests) - Management -- Databases -- Users -- Roles and Privileges - Maintenance -- Backup and Restore -- PITR -- Replication (where to look for it.) -- Monitoring -- Routine Maintenance (vacuum, analyze, etc...) - Troubleshooting (I'm not sure what to put under here right now... Will think on it.) Please, feel free to rip this up and reassemble as necessary. But I do think it's important to regroup our subjects under a few very broad topics. ---(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
Re: [DOCS] vacuum and routine maintenance docs
Am Donnerstag, 19. Januar 2006 02:31 schrieb Jim C. Nasby: > Is there an easy way to get a 2-level outline out of the sgml? How would you define the TOC that we currently produce? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] vacuum and routine maintenance docs
On Thu, 2006-01-19 at 16:00, Jim C. Nasby wrote: > On Thu, Jan 19, 2006 at 10:15:19AM -0600, Scott Marlowe wrote: > > I agree completely. We don't probably need it in sgml just yet. From a > > Actually, I was looking for how to get the view out of the existing SGML > ;) In any case, I think admin is probably broad enough that there won't > be much overlap with other sections. > > > 40,000 ft perspective, we can break administration up into several large > > chunks, and then decide what needs to go in each. The general "big > > topics" we already have seem pretty serviceable. However, I tend to > > think of OS env and server config as being sub topics under > > installation. Under that, we can put the individual subjects > > accordingly. > > > > - Installation > > -- Documentation scope specification > > -- Preparation (setting objectives for the installation) > > -- Hardware considerations (emphasizing things like fsyncing and all) > > -- OS configuration (i.e. shared memory) > > -- Software installation (source versus rpm versus pkg etc.) > > -- Cluster initialization (localization issues, location, etc...) > > -- Server configuration (i.e. pg_hba / postgresql.conf et. al.) > > -- Running the server (start up scripts, by hand, etc.) > > -- Verifying server operation (regression tests) > > Should probably mention contrib in here somewhere... and other > resources, like pgFoundry. Afterall, the install section is somewhat of > someone's introduction to PostgreSQL... Good point. I'll add that somewhere in there under software installation. > > - Management > > -- Databases > > -- Users > > -- Roles and Privileges > > Somewhere in one or both of the above should probably be some discussion > on security practices... Also, pg_hba.conf is a bit of a stickler, > because it is closely related to users and authentication. > postgresql.conf is also a bit tricky, because many of it's settings > require knowledge from other areas. Maybe the best way to deal with > these is extensive cross-linking? IE: each postgresql.conf item (or set > of items) should have a link back to whatever section explains it in > detail. Yeah, I keep thinking more and more we need a LOT of linkable resources for this, much like the ones we have for all the standard command reference stuff. I'm leaning towards having the main page of each of these things be somewhat closer to an executive summary (not that light on info, but you know what I mean) and have links to more info for each subject. So that each section can have a much more in depth coverage but not make it a huge slog to get through the documentation. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] vacuum and routine maintenance docs
On Thu, Jan 19, 2006 at 06:00:36PM +0100, Peter Eisentraut wrote: > Am Donnerstag, 19. Januar 2006 02:31 schrieb Jim C. Nasby: > > Is there an easy way to get a 2-level outline out of the sgml? > > How would you define the TOC that we currently produce? Sorry, I guess what I was actually thinking of is a 3-level one. In any case, I'm sure I can figure it out from whatever code generates index.html... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] vacuum and routine maintenance docs
On Thu, Jan 19, 2006 at 10:15:19AM -0600, Scott Marlowe wrote: > I agree completely. We don't probably need it in sgml just yet. From a Actually, I was looking for how to get the view out of the existing SGML ;) In any case, I think admin is probably broad enough that there won't be much overlap with other sections. > 40,000 ft perspective, we can break administration up into several large > chunks, and then decide what needs to go in each. The general "big > topics" we already have seem pretty serviceable. However, I tend to > think of OS env and server config as being sub topics under > installation. Under that, we can put the individual subjects > accordingly. > > - Installation > -- Documentation scope specification > -- Preparation (setting objectives for the installation) > -- Hardware considerations (emphasizing things like fsyncing and all) > -- OS configuration (i.e. shared memory) > -- Software installation (source versus rpm versus pkg etc.) > -- Cluster initialization (localization issues, location, etc...) > -- Server configuration (i.e. pg_hba / postgresql.conf et. al.) > -- Running the server (start up scripts, by hand, etc.) > -- Verifying server operation (regression tests) Should probably mention contrib in here somewhere... and other resources, like pgFoundry. Afterall, the install section is somewhat of someone's introduction to PostgreSQL... > - Management > -- Databases > -- Users > -- Roles and Privileges Somewhere in one or both of the above should probably be some discussion on security practices... Also, pg_hba.conf is a bit of a stickler, because it is closely related to users and authentication. postgresql.conf is also a bit tricky, because many of it's settings require knowledge from other areas. Maybe the best way to deal with these is extensive cross-linking? IE: each postgresql.conf item (or set of items) should have a link back to whatever section explains it in detail. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [PATCHES] Example for UPDATE FROM with correllation
Patch applied, with minor space adjustments to HEAD and 8.1.X. I also noticed a few earlier examples were missing paragraph formatting. --- David Fetter wrote: > Folks, > > Please find enclosed a doc patch that adds an example of a correllated > UPDATE. > > Cheers, > D > -- > David Fetter [EMAIL PROTECTED] http://fetter.org/ > phone: +1 415 235 3778 > > Remember to vote! [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [email protected] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/ref/update.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ref/update.sgml,v retrieving revision 1.33 diff -c -c -r1.33 update.sgml *** doc/src/sgml/ref/update.sgml12 Oct 2005 23:19:22 - 1.33 --- doc/src/sgml/ref/update.sgml19 Jan 2006 23:08:08 - *** *** 205,218 --- 205,236 WHERE accounts.name = 'Acme Corporation' AND employees.id = accounts.sales_person; + + Perform the same operation, using a sub-select in the WHERE clause: UPDATE employees SET sales_count = sales_count + 1 WHERE id = (SELECT sales_person FROM accounts WHERE name = 'Acme Corporation'); + + +Now that all the papers are signed, update the most recently closed +deal of the travelling salesperson who closed the Rocket Powered +Skates deal with the Acme Corporation. + + UPDATE employees SET last_closed_deal = deal.id + FROM accounts JOIN deals ON (account.id = deal.account_id) + WHERE deal.employee_id = employees.id + AND deal.name = 'Rocket Powered Skates' + AND accounts.name = 'Acme Corporation' + ORDER BY deal.signed_date DESC LIMIT 1; + + + + Attempt to insert a new stock item along with the quantity of stock. If the item already exists, instead update the stock count of the existing item. To do this without failing the entire transaction, use savepoints. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] vacuum and routine maintenance docs
Scott Marlowe <[EMAIL PROTECTED]> writes: > Yeah, I keep thinking more and more we need a LOT of linkable resources > for this, much like the ones we have for all the standard command > reference stuff. I'm leaning towards having the main page of each of > these things be somewhat closer to an executive summary (not that light > on info, but you know what I mean) and have links to more info for each > subject. So that each section can have a much more in depth coverage > but not make it a huge slog to get through the documentation. The refrain that I keep hearing is that the info is in there but it's not so easy to find. So this sounds like a plan to me: quick overviews with links should make it easier to find the parts people need to read. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
