• Text Size: Normal / Large
• Donate
• Contact

Section Navigation

• Community
• Mailing Lists
  • Subscribe
  • User lists
    • pgsql-admin
    • pgsql-advocacy
    • pgsql-announce
    • pgsql-bugs
    • pgsql-docs
    • pgsql-cygwin
    • pgsql-general
    • pgsql-interfaces
    • pgsql-jdbc
    • pgsql-jobs
    • pgsql-novice
    • pgsql-odbc
    • pgsql -performance
    • pgsql-php
    • pgsql-ports
    • pgsql-sql
  • Developer lists
  • Regional lists
  • Project lists
  • User groups
  • Inactive lists
• IRC
• In The Real World
• International Sites
• Propaganda
• Resources
• Weekly News

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

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

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

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