• 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 Thread Index (1/2)

• Main Index
• [Prev Page]
• [Next Page]

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

---

• Main Index
• [Prev Page]
• [Next Page]

---

Mail converted by MHonArc