• Text Size: Normal / Large
• Donate
• Contact

Section Navigation

• Community
• Contributors
• Mailing Lists
  • Subscribe
  • User lists
    • pgsql-admin
    • pgsql-advocacy
    • pgsql-announce
    • pgsql-bugs
    • pgsql-docs
    • pgsql-general
    • pgsql-jobs
    • pgsql-novice
    • pgsql-performance
    • pgsql-php
    • pgsql-sql
    • pgsql-students
  • Developer lists
  • Regional lists
  • Associations
  • User groups
  • Project lists
  • Inactive lists
• IRC
• Featured Users
• International Sites
• Propaganda
• Resources
• Weekly News
• Community login
  • Profile
  • Lost password

pgsql-performance 2006-11 Chronological Index (1/2)

• Thread Index
• [Prev Page]
• [Next Page]

• 01 December 2006
  • Re: Defining performance. Chris (03:32)
  • Re: Bad iostat numbers Mark Kirkwood (03:00)
  • Re: Bad iostat numbers David Boreham (02:24)
  • Re: Bad iostat numbers Mark Kirkwood (01:47)
  • Re: Defining performance. Tobias Brox (01:16)
  • Re: Defining performance. nospam (01:10)
  • Re: Defining performance. Tobias Brox (01:08)
  • Re: Defining performance. Jeff Davis (00:58)
  • Bad iostat numbers Carlos H. Reimer (00:44)
  • Re: Defining performance. Scott Marlowe (00:44)
  • Re: Defining performance. Tom Lane (00:26)
  • Re: Defining performance. Tobias Brox (00:05)
• 30 November 2006
  • Defining performance. Paul Lathrop (23:31)
  • Re: RES: Priority to a mission critical transaction Josh Berkus (04:29)
• 29 November 2006
  • Re: Fw: [GENERAL] Including unique users in huge data Luke Lonergan (21:55)
  • Fw: [GENERAL] Including unique users in huge data warehouse in Postgresql... Mark Jensen (19:43)
  • Re: RES: Priority to a mission critical transaction Ron Mayer (18:47)
  • OT - how to size/match multiple databases/apps for a single server Kevin Kempter (18:09)
  • Re: RES: Priority to a mission critical transaction Brian Hurt (17:21)
  • Re: RES: Priority to a mission critical transaction Ron Mayer (16:43)
  • Re: NAMEDATALEN and performance Tom Lane (15:50)
  • Re: RES: Priority to a mission critical transaction Brian Hurt (15:17)
  • Re: RES: Priority to a mission critical transaction Mark Lewis (15:03)
  • Re: RES: Priority to a mission critical transaction Brian Hurt (13:26)
  • NAMEDATALEN and performance Alessandro Baretta (11:32)
  • Re: RES: Priority to a mission critical transaction Ron Mayer (10:55)
  • Re: RES: Priority to a mission critical transaction Mark Kirkwood (01:43)
  • Re: RES: Priority to a mission critical transaction Mark Kirkwood (01:26)
  • Re: RES: Priority to a mission critical transaction Ron Mayer (01:20)
• 28 November 2006
  • Re: RES: Priority to a mission critical transaction Bruce Momjian (23:44)
  • Re: RES: Priority to a mission critical transaction Ron Mayer (20:31)
  • Re: RES: Priority to a mission critical transaction Josh Berkus (19:45)
  • Re: RES: Priority to a mission critical transaction Andreas Kostyrka (19:17)
  • Re: RES: Priority to a mission critical transaction Tom Lane (19:07)
  • RES: Priority to a mission critical transaction Carlos H. Reimer (19:01)
  • Re: Postgres scalability and performance on windows J. Andrew Rogers (16:51)
  • Re: Postgres scalability and performance on windows Tom Lane (16:25)
  • Re: Postgres scalability and performance on windows Gopal (12:27)
  • Re: BUG #2784: Performance serious degrades over a period Bill Moran (11:34)
  • Re: BUG #2784: Performance serious degrades over a period of a month Bruno Wolff III (04:25)
• 27 November 2006
  • Re: When to vacuum a table? Kevin Grittner (18:59)
  • Re: Postgres server crash Florian Weimer (18:33)
  • Re: shared_buffers > 284263 on OS X Guido Neitzer (16:21)
  • Re: shared_buffers > 284263 on OS X AgentM (16:05)
  • Re: Postgres server crash Michael Stone (13:20)
  • Re: shared_buffers > 284263 on OS X Jim C. Nasby (09:23)
  • Re: Massive delete of rows, how to proceed? Merlin Moncure (08:44)
  • Plattform comparison (lies, damn lies and benchmarks) Guido Neitzer (08:09)
  • Re: shared_buffers > 284263 on OS X Guido Neitzer (07:35)
  • Re: shared_buffers > 284263 on OS X Brian Wipf (07:24)
  • Re: shared_buffers > 284263 on OS X Guido Neitzer (07:11)
  • Re: shared_buffers > 284263 on OS X Guido Neitzer (07:11)
  • Re: shared_buffers > 284263 on OS X Brian Wipf (04:11)
  • Re: shared_buffers > 284263 on OS X Tom Lane (04:04)
  • Re: shared_buffers > 284263 on OS X Brendan Duddridge (03:51)
  • Re: When to vacuum a table? Jim C. Nasby (01:01)
  • Re: Priority to a mission critical transaction Jim C. Nasby (00:52)
• 26 November 2006
  • Re: Postgres server crash Jim C. Nasby (23:41)
  • Re: availability of SATA vendors Jim C. Nasby (23:34)
  • Re: availability of SATA vendors Jim C. Nasby (23:31)
  • Re: shared_buffers > 284263 on OS X Jim C. Nasby (23:25)
  • Re: When to vacuum a table? Joshua D. Drake (17:46)
  • Re: When to vacuum a table? Tom Lane (17:06)
  • Re: When to vacuum a table? Craig A. James (16:28)
  • Re: When to vacuum a table? Andrew Sullivan (14:34)
  • Re: When to vacuum a table? Rod Taylor (14:31)
  • Re: When to vacuum a table? Marcelo Costa (13:46)
  • Re: When to vacuum a table? Steinar H. Gunderson (13:30)
  • Re: When to vacuum a table? Marcelo Costa (12:43)
  • When to vacuum a table? Joost Kraaijeveld (11:24)
  • Re: Massive delete of rows, how to proceed? andrew (01:26)
• 25 November 2006
  • Massive delete of rows, how to proceed? Peter Childs (15:45)
  • Re: Postgres scalability and performance on windows Tom Lane (00:10)
• 24 November 2006
  • Massive delete of rows, how to proceed? Arnau (19:26)
  • Re: Postgres scalability and performance on windows Frank Wiles (17:50)
  • Re: TPC-H Benchmark Luke Lonergan (16:31)
  • TPC-H Benchmark Felipe Rondon Rocha (14:08)
  • Re: Postgres scalability and performance on windows Gopal (10:14)
  • Re: Postgres scalability and performance on windows Guido Neitzer (08:27)
  • Re: Direct I/O issues Bruce Momjian (04:06)
• 23 November 2006
  • Re: Postgres scalability and performance on windows Heikki Linnakangas (22:51)
  • Postgres scalability and performance on windows Gopal (22:38)
  • Re: Priority to a mission critical transaction Brad Nicholson (20:40)
  • Re: Direct I/O issues Greg Smith (18:10)
  • Re: Direct I/O issues Tom Lane (16:46)
  • Re: Lying drives [Was: Re: Which OS provides the Bruce Momjian (16:44)
  • Re: PostgreSQL underestimates sorting Simon Riggs (15:20)
  • Re: availability of SATA vendors Arjen van der Meijden (08:40)
  • Re: Lying drives [Was: Re: Which OS provides the _fastest_ Greg Smith (07:31)
  • Direct I/O issues Greg Smith (06:40)
• 22 November 2006
  • Re: availability of SATA vendors Luke Lonergan (23:03)
  • Re: availability of SATA vendors Bucky Jordan (22:38)
  • Re: availability of SATA vendors Scott Marlowe (17:34)
  • Re: PostgreSQL underestimates sorting Frank Wiles (17:11)
  • Re: availability of SATA vendors Joshua D. Drake (17:10)
  • Re: availability of SATA vendors Arjen van der Meijden (17:07)
  • Re: availability of SATA vendors Jeff Frost (17:02)
  • Re: availability of SATA vendors Joshua D. Drake (17:00)
  • Re: PostgreSQL underestimates sorting Markus Schaber (16:59)
  • Re: availability of SATA vendors Jeff Frost (16:36)
  • Re: PostgreSQL underestimates sorting Markus Schaber (14:28)
  • Re: availability of SATA vendors Bucky Jordan (14:18)
  • Re: PostgreSQL underestimates sorting Steinar H. Gunderson (13:58)
  • PostgreSQL underestimates sorting Markus Schaber (13:51)
  • Re: availability of SATA vendors Joshua D. Drake (02:37)
  • Re: availability of SATA vendors Jeff Frost (02:15)
  • Re: availability of SATA vendors Joshua D. Drake (02:13)
  • Priority to a mission critical transaction Carlos H. Reimer (02:11)
  • Re: availability of SATA vendors Jeff Frost (01:54)
• 21 November 2006
  • Re: Slow Query Joe Lester (20:28)
  • Slow Query Joe Lester (17:39)
  • Re: BitMapScan performance degradation Jérôme BENOIS (17:01)
  • Re: BitMapScan performance degradation db (15:51)
  • Re: BitMapScan performance degradation Tom Lane (15:44)
  • RES: Context switching Carlos H. Reimer (14:48)
  • BitMapScan performance degradation Jérôme BENOIS (14:45)
  • Re: Postgres server crash Markus Schaber (14:08)
• 20 November 2006
  • Re: Postgres server crash Mattias Kregert (22:58)
  • Re: Postgres server crash Craig A. James (06:43)
  • Re: Postgres server crash Bruno Wolff III (01:59)
  • Re: Postgres server crash Craig A. James (01:02)
• 19 November 2006
  • Re: Postgres server crash Michael Stone (22:32)
  • PostgreSQL with 64 bit was: Re: shared_buffers > 284263 on OS X Guido Neitzer (22:22)
  • Re: Postgres server crash Craig A. James (22:13)
  • Re: Postgres server crash Michael Stone (21:25)
  • Re: Postgres server crash Richard Broersma Jr (20:42)
  • Re: Postgres server crash Michael Stone (19:41)
  • Re: Postgres server crash Ron Mayer (17:07)
  • Re: Postgres server crash Ron Mayer (17:01)
  • Re: shared_buffers > 284263 on OS X Guido Neitzer (15:20)
  • Re: Postgres server crash Tom Lane (06:51)
  • Re: Postgres server crash Craig A. James (06:45)
  • Fwd: start up cost estimate rakesh kumar (04:05)
  • Re: shared_buffers > 284263 on OS X Brian Wipf (03:13)
  • Re: Postgres server crash Richard Troy (01:18)
• 18 November 2006
  • Re: shared_buffers > 284263 on OS X Guido Neitzer (18:48)
  • Re: shared_buffers > 284263 on OS X Guido Neitzer (18:48)
  • Re: shared_buffers > 284263 on OS X Tom Lane (18:30)
  • Re: start up cost estimate Tom Lane (18:11)
  • Re: shared_buffers > 284263 on OS X Dave Cramer (16:17)
  • Re: start up cost estimate Joshua Marsh (14:27)
  • Re: Optimicing Postgres for SunSolaris10 on V240 Marc Cousin (10:09)
  • start up cost estimate rakesh kumar (09:33)
• 17 November 2006
  • Re: availability of SATA vendors Luke Lonergan (21:54)
  • Re: availability of SATA vendors Steve Atkins (20:44)
  • Re: availability of SATA vendors Ron (20:00)
  • Re: availability of SATA vendors Arjen van der Meijden (19:20)
  • Re: Optimicing Postgres for SunSolaris10 on V240 Josh Berkus (18:45)
  • availability of SATA vendors Jeff Frost (17:45)
  • Re: [BUGS] BUG #2737: hash indexing large tablefails,while Julius.Stroffek (15:36)
  • Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works Tom Lane (15:08)
  • Re: [BUGS] BUG #2737: hash indexing largetablefails,while btree of same index works Simon Riggs (14:38)
  • Re: Keeping processes open for re-use Richard Huxton (11:18)
  • Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works Simon Riggs (10:59)
  • shared_buffers > 284263 on OS X Brian Wipf (00:33)
• 16 November 2006
  • Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works Tom Lane (22:48)
  • Re: Context switch storm Jim Nasby (21:01)
  • Re: Postgres server crash Ben (20:51)
  • Re: Postgres server crash Merlin Moncure (18:26)
  • Re: Postgres server crash Richard Huxton (18:19)
  • Re: Postgres server crash Tom Lane (18:14)
  • Re: Postgres server crash Tom Lane (18:10)
  • Re: Keeping processes open for re-use Jean-Max Reymond (17:39)
  • Re: Postgres server crash Richard Huxton (17:27)
  • Re: Postgres server crash Craig A. James (17:17)
  • Re: Postgres server crash Richard Huxton (17:08)
  • Re: Postgres server crash Craig A. James (17:02)
  • Re: Postgres server crash Richard Huxton (10:46)
  • Re: Slow SELECT on three or more clients AMIR FRANCO D. JOVEN (08:54)
  • Re: Postgres server crash Russell Smith (02:28)
  • Postgres server crash Craig A. James (02:23)
• 15 November 2006
  • Re: Hundreds of database and FSM Steinar H. Gunderson (17:43)
  • Re: Hundreds of database and FSM Alvaro Herrera (17:31)
  • Hundreds of database and FSM Craig A. James (16:38)
  • Re: Slow SELECT on three or more clients Markus Schaber (14:47)
  • Re: Slow SELECT on three or more clients Merlin Moncure (14:17)
  • Re: Slow SELECT on three or more clients Gregory S. Williamson (13:59)
  • Re: Slow SELECT on three or more clients Russell Smith (13:32)
  • Re: Slow SELECT on three or more clients Andreas Kostyrka (13:26)
  • Slow SELECT on three or more clients AMIR FRANCO D. JOVEN (11:44)

• Thread Index
• [Prev Page]
• [Next Page]