Postgres Performance Date Index

• Thread Index

• Re: How to move pg_xlog to another drive on Windows????
  • From: Anthony Presley
• Re: Configuration settings for 32GB RAM server
  • From: Scott Marlowe
• Re: How to move pg_xlog to another drive on Windows????
  • From: Merlin Moncure
• Re: Configuration settings for 32GB RAM server
  • From: Joshua Marsh
• Re: Configuration settings for 32GB RAM server
  • From: Vivek Khera
• Re: Bad iostat numbers
  • From: Scott Marlowe
• Re: Bad iostat numbers
  • From: Scott Marlowe
• Re: Bad iostat numbers
  • From: Michael Stone
• Re: Bad iostat numbers
  • From: Alex Turner
• How to move pg_xlog to another drive on Windows????
  • From: Joost Kraaijeveld
• Re: Bad iostat numbers
  • From: Michael Stone
• Re: Configuration settings for 32GB RAM server
  • From: Jeff Davis
• Re: Bad iostat numbers
  • From: Alex Turner
• Configuration settings for 32GB RAM server
  • From: Mark Lonsdale
• Re: Is Vacuum/analyze destroying my performance?
  • From: Carlo Stonebanks
• Re: 8.2rc1 (much) slower than 8.2dev?
  • From: Arjen van der Meijden
• Re: Bad iostat numbers
  • From: Scott Marlowe
• Re: Bad iostat numbers
  • From: Scott Marlowe
• Re: 8.2rc1 (much) slower than 8.2dev?
  • From: Tom Lane
• Re: Is Vacuum/analyze destroying my performance?
  • From: Matthew O'Connor
• 8.2rc1 (much) slower than 8.2dev?
  • From: Arjen van der Meijden
• Re: Bad iostat numbers
  • From: Alex Turner
• Re: Bad iostat numbers
  • From: Greg Smith
• Re: Is Vacuum/analyze destroying my performance?
  • From: Carlo Stonebanks
• Is Vacuum/analyze destroying my performance?
  • From: Carlo Stonebanks
• Re: Enabling constraint_exclusion does not avoid scanning all child partitions
  • From: Fayza Sultan
• Re: Enabling constraint_exclusion does not avoid scanning all child partitions
  • From: Tom Lane
• Enabling constraint_exclusion does not avoid scanning all child partitions
  • From: Fayza Sultan
• Re: Hardware advice
  • From: Alexandru Coseru
• Re: Hardware advice
  • From: Josh Berkus
• Re: Propagating outer join conditions
  • From: Tom Lane
• Hardware advice
  • From: Alexandru Coseru
• Re: Propagating outer join conditions
  • From: Aaron Birkland
• Re: Propagating outer join conditions
  • From: Jonathan Blitz
• Propagating outer join conditions
  • From: Aaron Birkland
• Re: Regex performance issue
  • From: Alexandru Coseru
• Re: Which query analiser tools are available?
  • From: Andreas Kretschmer
• Which query analiser tools are available?
  • From: Joost Kraaijeveld
• Re: Regex performance issue
  • From: Oleg Bartunov
• Re: Regex performance issue
  • From: Tom Lane
• Re: Regex performance issue
  • From: Scott Marlowe
• Re: Regex performance issue
  • From: Alexandru Coseru
• Re: Regex performance issue
  • From: Alexandru Coseru
• Re: Regex performance issue
  • From: Heikki Linnakangas
• Re: Regex performance issue
  • From: Alexandru Coseru
• Re: Regex performance issue
  • From: Heikki Linnakangas
• Re: Regex performance issue
  • From: Oleg Bartunov
• Re: Regex performance issue
  • From: Alexandru Coseru
• Re: Regex performance issue
  • From: Dave Dutcher
• Regex performance issue
  • From: Alexandru Coseru
• Re: Dump performance problems following server crash
  • From: Kim
• Re: Dump performance problems following server crash
  • From: Tom Lane
• Dump performance problems following server crash
  • From: Kim
• Re: Performance of Perc 5i
  • From: Bucky Jordan
• Performance of Perc 5i
  • From: Alex Turner
• Re: RES: Bad iostat numbers
  • From: David Boreham
• Re: NAMEDATALEN and performance
  • From: Tom Lane
• RES: Bad iostat numbers
  • From: Carlos H. Reimer
• RES: Bad iostat numbers
  • From: Carlos H. Reimer
• Re: Defining performance.
  • From: Heikki Linnakangas
• Re: NAMEDATALEN and performance
  • From: Alessandro Baretta
• Re: Defining performance.
  • From: Tobias Brox
• Re: Defining performance.
  • From: Chris
• Re: Bad iostat numbers
  • From: Mark Kirkwood
• Re: Bad iostat numbers
  • From: David Boreham
• Re: Bad iostat numbers
  • From: Mark Kirkwood
• Re: Defining performance.
  • From: Tobias Brox
• Re: Defining performance.
  • From: nospam
• Re: Defining performance.
  • From: Tobias Brox
• Re: Defining performance.
  • From: Jeff Davis
• Bad iostat numbers
  • From: Carlos H. Reimer
• Re: Defining performance.
  • From: Scott Marlowe
• Re: Defining performance.
  • From: Tom Lane
• Re: Defining performance.
  • From: Tobias Brox
• Defining performance.
  • From: Paul Lathrop
• Re: RES: Priority to a mission critical transaction
  • From: Josh Berkus
• Re: Fw: [GENERAL] Including unique users in huge data
  • From: Luke Lonergan
• Fw: [GENERAL] Including unique users in huge data warehouse in Postgresql...
  • From: Mark Jensen
• Re: RES: Priority to a mission critical transaction
  • From: Ron Mayer
• OT - how to size/match multiple databases/apps for a single server
  • From: Kevin Kempter
• Re: RES: Priority to a mission critical transaction
  • From: Brian Hurt
• Re: RES: Priority to a mission critical transaction
  • From: Ron Mayer
• Re: NAMEDATALEN and performance
  • From: Tom Lane
• Re: RES: Priority to a mission critical transaction
  • From: Brian Hurt
• Re: RES: Priority to a mission critical transaction
  • From: Mark Lewis
• Re: RES: Priority to a mission critical transaction
  • From: Brian Hurt
• NAMEDATALEN and performance
  • From: Alessandro Baretta
• Re: RES: Priority to a mission critical transaction
  • From: Ron Mayer
• Re: RES: Priority to a mission critical transaction
  • From: Mark Kirkwood
• Re: RES: Priority to a mission critical transaction
  • From: Mark Kirkwood
• Re: RES: Priority to a mission critical transaction
  • From: Ron Mayer
• Re: RES: Priority to a mission critical transaction
  • From: Bruce Momjian
• Re: RES: Priority to a mission critical transaction
  • From: Ron Mayer
• Re: RES: Priority to a mission critical transaction
  • From: Josh Berkus
• Re: RES: Priority to a mission critical transaction
  • From: Andreas Kostyrka
• Re: RES: Priority to a mission critical transaction
  • From: Tom Lane
• RES: Priority to a mission critical transaction
  • From: Carlos H. Reimer
• Re: Postgres scalability and performance on windows
  • From: J. Andrew Rogers
• Re: Postgres scalability and performance on windows
  • From: Tom Lane
• Re: Postgres scalability and performance on windows
  • From: Gopal
• Re: BUG #2784: Performance serious degrades over a period
  • From: Bill Moran
• Re: BUG #2784: Performance serious degrades over a period of a month
  • From: Bruno Wolff III
• Re: When to vacuum a table?
  • From: Kevin Grittner
• Re: Postgres server crash
  • From: Florian Weimer
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: AgentM
• Re: Postgres server crash
  • From: Michael Stone
• Re: shared_buffers > 284263 on OS X
  • From: Jim C. Nasby
• Re: Massive delete of rows, how to proceed?
  • From: Merlin Moncure
• Plattform comparison (lies, damn lies and benchmarks)
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Brian Wipf
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Brian Wipf
• Re: shared_buffers > 284263 on OS X
  • From: Tom Lane
• Re: shared_buffers > 284263 on OS X
  • From: Brendan Duddridge
• Re: When to vacuum a table?
  • From: Jim C. Nasby
• Re: Priority to a mission critical transaction
  • From: Jim C. Nasby
• Re: Postgres server crash
  • From: Jim C. Nasby
• Re: availability of SATA vendors
  • From: Jim C. Nasby
• Re: availability of SATA vendors
  • From: Jim C. Nasby
• Re: shared_buffers > 284263 on OS X
  • From: Jim C. Nasby
• Re: When to vacuum a table?
  • From: Joshua D. Drake
• Re: When to vacuum a table?
  • From: Tom Lane
• Re: When to vacuum a table?
  • From: Craig A. James
• Re: When to vacuum a table?
  • From: Andrew Sullivan
• Re: When to vacuum a table?
  • From: Rod Taylor
• Re: When to vacuum a table?
  • From: Marcelo Costa
• Re: When to vacuum a table?
  • From: Steinar H. Gunderson
• Re: When to vacuum a table?
  • From: Marcelo Costa
• When to vacuum a table?
  • From: Joost Kraaijeveld
• Re: Massive delete of rows, how to proceed?
  • From: andrew
• Massive delete of rows, how to proceed?
  • From: Peter Childs
• Re: Postgres scalability and performance on windows
  • From: Tom Lane
• Massive delete of rows, how to proceed?
  • From: Arnau
• Re: Postgres scalability and performance on windows
  • From: Frank Wiles
• Re: TPC-H Benchmark
  • From: Luke Lonergan
• TPC-H Benchmark
  • From: Felipe Rondon Rocha
• Re: Postgres scalability and performance on windows
  • From: Gopal
• Re: Postgres scalability and performance on windows
  • From: Guido Neitzer
• Re: Direct I/O issues
  • From: Bruce Momjian
• Re: Postgres scalability and performance on windows
  • From: Heikki Linnakangas
• Postgres scalability and performance on windows
  • From: Gopal
• Re: Priority to a mission critical transaction
  • From: Brad Nicholson
• Re: Direct I/O issues
  • From: Greg Smith
• Re: Direct I/O issues
  • From: Tom Lane
• Re: Lying drives [Was: Re: Which OS provides the
  • From: Bruce Momjian
• Re: PostgreSQL underestimates sorting
  • From: Simon Riggs
• Re: availability of SATA vendors
  • From: Arjen van der Meijden
• Re: Lying drives [Was: Re: Which OS provides the _fastest_
  • From: Greg Smith
• Direct I/O issues
  • From: Greg Smith
• Re: availability of SATA vendors
  • From: Luke Lonergan
• Re: availability of SATA vendors
  • From: Bucky Jordan
• Re: availability of SATA vendors
  • From: Scott Marlowe
• Re: PostgreSQL underestimates sorting
  • From: Frank Wiles
• Re: availability of SATA vendors
  • From: Joshua D. Drake
• Re: availability of SATA vendors
  • From: Arjen van der Meijden
• Re: availability of SATA vendors
  • From: Jeff Frost
• Re: availability of SATA vendors
  • From: Joshua D. Drake
• Re: PostgreSQL underestimates sorting
  • From: Markus Schaber
• Re: availability of SATA vendors
  • From: Jeff Frost
• Re: PostgreSQL underestimates sorting
  • From: Markus Schaber
• Re: availability of SATA vendors
  • From: Bucky Jordan
• Re: PostgreSQL underestimates sorting
  • From: Steinar H. Gunderson
• PostgreSQL underestimates sorting
  • From: Markus Schaber
• Re: availability of SATA vendors
  • From: Joshua D. Drake
• Re: availability of SATA vendors
  • From: Jeff Frost
• Re: availability of SATA vendors
  • From: Joshua D. Drake
• Priority to a mission critical transaction
  • From: Carlos H. Reimer
• Re: availability of SATA vendors
  • From: Jeff Frost
• Re: Slow Query
  • From: Joe Lester
• Slow Query
  • From: Joe Lester
• Re: BitMapScan performance degradation
  • From: Jérôme BENOIS
• Re: BitMapScan performance degradation
  • From: db
• Re: BitMapScan performance degradation
  • From: Tom Lane
• RES: Context switching
  • From: Carlos H. Reimer
• BitMapScan performance degradation
  • From: Jérôme BENOIS
• Re: Postgres server crash
  • From: Markus Schaber
• Re: Postgres server crash
  • From: Mattias Kregert
• Re: Postgres server crash
  • From: Craig A. James
• Re: Postgres server crash
  • From: Bruno Wolff III
• Re: Postgres server crash
  • From: Craig A. James
• Re: Postgres server crash
  • From: Michael Stone
• PostgreSQL with 64 bit was: Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: Postgres server crash
  • From: Craig A. James
• Re: Postgres server crash
  • From: Michael Stone
• Re: Postgres server crash
  • From: Richard Broersma Jr
• Re: Postgres server crash
  • From: Michael Stone
• Re: Postgres server crash
  • From: Ron Mayer
• Re: Postgres server crash
  • From: Ron Mayer
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: Postgres server crash
  • From: Tom Lane
• Re: Postgres server crash
  • From: Craig A. James
• Fwd: start up cost estimate
  • From: rakesh kumar
• Re: shared_buffers > 284263 on OS X
  • From: Brian Wipf
• Re: Postgres server crash
  • From: Richard Troy
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Tom Lane
• Re: start up cost estimate
  • From: Tom Lane
• Re: shared_buffers > 284263 on OS X
  • From: Dave Cramer
• Re: start up cost estimate
  • From: Joshua Marsh
• Re: Optimicing Postgres for SunSolaris10 on V240
  • From: Marc Cousin
• start up cost estimate
  • From: rakesh kumar
• Re: availability of SATA vendors
  • From: Luke Lonergan
• Re: availability of SATA vendors
  • From: Steve Atkins
• Re: availability of SATA vendors
  • From: Ron
• Re: availability of SATA vendors
  • From: Arjen van der Meijden
• Re: Optimicing Postgres for SunSolaris10 on V240
  • From: Josh Berkus
• availability of SATA vendors
  • From: Jeff Frost
• Re: [BUGS] BUG #2737: hash indexing large tablefails,while
  • From: Julius.Stroffek
• Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works
  • From: Tom Lane
• Re: [BUGS] BUG #2737: hash indexing largetablefails,while btree of same index works
  • From: Simon Riggs
• Re: Keeping processes open for re-use
  • From: Richard Huxton
• Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works
  • From: Simon Riggs
• shared_buffers > 284263 on OS X
  • From: Brian Wipf
• Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works
  • From: Tom Lane
• Re: Context switch storm
  • From: Jim Nasby
• Re: Postgres server crash
  • From: Ben
• Re: Postgres server crash
  • From: Merlin Moncure
• Re: Postgres server crash
  • From: Richard Huxton
• Re: Postgres server crash
  • From: Tom Lane
• Re: Postgres server crash
  • From: Tom Lane
• Re: Keeping processes open for re-use
  • From: Jean-Max Reymond
• Re: Postgres server crash
  • From: Richard Huxton
• Re: Postgres server crash
  • From: Craig A. James
• Re: Postgres server crash
  • From: Richard Huxton
• Re: Postgres server crash
  • From: Craig A. James
• Re: Postgres server crash
  • From: Richard Huxton
• Re: Slow SELECT on three or more clients
  • From: AMIR FRANCO D. JOVEN
• Re: Postgres server crash
  • From: Russell Smith
• Postgres server crash
  • From: Craig A. James
• Re: Hundreds of database and FSM
  • From: Steinar H. Gunderson
• Re: Hundreds of database and FSM
  • From: Alvaro Herrera
• Hundreds of database and FSM
  • From: Craig A. James
• Re: Slow SELECT on three or more clients
  • From: Markus Schaber
• Re: Slow SELECT on three or more clients
  • From: Merlin Moncure
• Re: Slow SELECT on three or more clients
  • From: Gregory S. Williamson
• Re: Slow SELECT on three or more clients
  • From: Russell Smith
• Re: Slow SELECT on three or more clients
  • From: Andreas Kostyrka
• Slow SELECT on three or more clients
  • From: AMIR FRANCO D. JOVEN
• Re: Context switch storm
  • From: Simon Riggs
• Re: Context switch storm
  • From: Cosimo Streppone
• Re: Context switch storm
  • From: Merlin Moncure
• Re: Context switch storm
  • From: Bucky Jordan
• Re: Context switch storm
  • From: Jim C. Nasby
• Re: Context switch storm
  • From: Merlin Moncure
• Re: Context switch storm
  • From: Andreas Kostyrka
• Re: Context switch storm
  • From: Cosimo Streppone
• Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]
  • From: Guy Thornley
• Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works
  • From: Simon Riggs
• Re: [BUGS] BUG #2737: hash indexing large table fails, while btree of same index works
  • From: Tom Lane
• Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]
  • From: Ron Mayer
• Re: 10x rowcount mis-estimation favouring merge over nestloop
  • From: Abhijit Menon-Sen
• Re: 10x rowcount mis-estimation favouring merge over nestloop
  • From: Tom Lane
• 10x rowcount mis-estimation favouring merge over nestloop
  • From: Abhijit Menon-Sen
• Re: Keeping processes open for re-use
  • From: Joshua D. Drake
• Re: Keeping processes open for re-use
  • From: Shane Ambler
• Re: Keeping processes open for re-use
  • From: imad
• Re: Easy read-heavy benchmark kicking around?
  • From: Merlin Moncure
• Re: Keeping processes open for re-use
  • From: Csaba Nagy
• Keeping processes open for re-use
  • From: Hilary Forbes
• Re: Easy read-heavy benchmark kicking around?
  • From: Luke Lonergan
• Re: Which OS provides the _fastest_ PostgreSQL performance?
  • From: Ron Mayer
• Re: Easy read-heavy benchmark kicking around?
  • From: Cosimo Streppone
• Re: Easy read-heavy benchmark kicking around?
  • From: Merlin Moncure
• Re: Easy read-heavy benchmark kicking around?
  • From: Markus Schaber
• Re: Context switching
  • From: Josh Berkus
• Re: Easy read-heavy benchmark kicking around?
  • From: Dimitri Fontaine
• Re: Easy read-heavy benchmark kicking around?
  • From: Mark Kirkwood
• Re: Help w/speeding up range queries?
  • From: Jim Nasby
• Re: Context switch storm
  • From: Cosimo Streppone
• Re: Easy read-heavy benchmark kicking around?
  • From: Scott Marlowe
• Re: Easy read-heavy benchmark kicking around?
  • From: Merlin Moncure
• Re: Easy read-heavy benchmark kicking around?
  • From: Luke Lonergan
• Easy read-heavy benchmark kicking around?
  • From: Brian Hurt
• RES: Context switching
  • From: Carlos H. Reimer
• Re: Yet another question on LIMIT performance :/
  • From: Tom Lane
• Re: Setting "nice" values
  • From: Madison Kelly
• Re: Yet another question on LIMIT performance :/
  • From: Hannes Dorbath
• Re: Yet another question on LIMIT performance :/
  • From: Heikki Linnakangas
• Re: Setting "nice" values
  • From: Tobias Brox
• Yet another question on LIMIT performance :/
  • From: Hannes Dorbath
• Re: Setting "nice" values
  • From: Madison Kelly
• Re: Setting "nice" values
  • From: Tobias Brox
• Re: Setting "nice" values
  • From: Madison Kelly
• Re: Setting "nice" values
  • From: Madison Kelly
• Re: Setting "nice" values
  • From: Madison Kelly
• [no subject]
  • From: Unknown
• [no subject]
  • From: Unknown
• [no subject]
  • From: Unknown
• Re: Setting "nice" values
  • From: Jim Nasby
• Re: Slow functional indexes?
  • From: Gene
• Re: Slow functional indexes?
  • From: Tom Lane
• Re: Slow functional indexes?
  • From: Stuart Bishop
• Re: profiling PL/pgSQL?
  • From: korryd
• EXISTS optimization
  • From: Kevin Grittner
• Re: Context switch storm
  • From: Andreas Kostyrka
• Re: Context switch storm
  • From: Tom Lane
• Re: profiling PL/pgSQL?
  • From: Jonah H. Harris
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Tom Lane
• Re: Context switch storm
  • From: Richard Huxton
• Re: Context switch storm
  • From: creimer
• Re: Context switch storm
  • From: Cosimo Streppone
• Re: Context switch storm
  • From: Richard Huxton
• Re: Context switch storm
  • From: Richard Troy
• Re: Context switch storm
  • From: Andreas Kostyrka
• Re: Setting "nice" values
  • From: Andreas Kostyrka
• Re: Context switch storm
  • From: Richard Huxton
• Re: Context switch storm
  • From: Richard Huxton
• Re: Context switch storm
  • From: Gregory S. Williamson
• Context switch storm
  • From: creimer
• Re: profiling PL/pgSQL?
  • From: Richard Huxton
• Re: profiling PL/pgSQL?
  • From: A. Kretschmer
• profiling PL/pgSQL?
  • From: Drew Wilson
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Arjen van der Meijden
• Re: Locking vs. Exceptions
  • From: Benjamin Minshall
• Re: VACUUMs take twice as long across all nodes
  • From: Vivek Khera
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Alvaro Herrera
• Re: Setting "nice" values
  • From: Tobias Brox
• Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed
  • From: Alvaro Herrera
• Re: Setting "nice" values
  • From: Scott Marlowe
• Re: Setting "nice" values
  • From: Madison Kelly
• Re: Setting "nice" values
  • From: Scott Marlowe
• Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed
  • From: Steven Flatt
• Setting "nice" values
  • From: Madison Kelly
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Dave Dutcher
• Locking vs. Exceptions
  • From: Robins
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Richard Huxton
• Query plan for "heavy" SELECT with "lite" sub-SELECTs
  • From: Nikolay Samokhvalov
• Re: Help w/speeding up range queries?
  • From: Simon Riggs
• Re: Help w/speeding up range queries?
  • From: Marcin Mank
• Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed
  • From: Simon Riggs
• Re: Database-wide vacuum can take a long time, during which
  • From: Matthew O'Connor
• Database-wide vacuum can take a long time, during which tables are not being analyzed
  • From: Steven Flatt
• Re: big transaction slows down over time - but disk seems
  • From: Richard Huxton
• Re: big transaction slows down over time - but disk seems
  • From: Ben
• Re: big transaction slows down over time - but disk seems almost unused
  • From: Ben
• Re: big transaction slows down over time - but disk seems
  • From: Richard Huxton
• Re: MVCC & indexes?
  • From: Ivan Voras
• Re: big transaction slows down over time - but disk
  • From: Andreas Kostyrka
• Re: big transaction slows down over time - but disk seems almost unused
  • From: Ben
• Re: big transaction slows down over time - but disk seems
  • From: Heikki Linnakangas
• big transaction slows down over time - but disk seems almost unused
  • From: Ben
• Re: pg_trgm indexes giving bad estimations?
  • From: Tom Lane
• Re: Help w/speeding up range queries?
  • From: Tom Lane
• Re: pg_trgm indexes giving bad estimations?
  • From: Ben
• Re: Help w/speeding up range queries?
  • From: Luke Lonergan
• Context switching
  • From: Carlos H. Reimer
• Re: Help w/speeding up range queries?
  • From: Tom Lane
• Re: MVCC & indexes?
  • From: mark
• Re: Help w/speeding up range queries?
  • From: Luke Lonergan
• Re: Help w/speeding up range queries?
  • From: Weslee Bilodeau
• Re: Help w/speeding up range queries?
  • From: Luke Lonergan
• Help w/speeding up range queries?
  • From: John Major
• Re: MVCC & indexes?
  • From: Alvaro Herrera
• MVCC & indexes?
  • From: Ivan Voras
• Re: Best COPY Performance
  • From: Teemu Torma
• Re: commit so slow program looks frozen
  • From: Rob Lemley
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Index ignored on column containing mostly 0 values
  • From: Andreas Kostyrka
• Re: client crashes in PQfinish
  • From: Richard Huxton
• Re: client crashes in PQfinish
  • From: soni de
• Re: Index ignored on column containing mostly 0 values
  • From: Tom Lane
• Re: Index ignored on column containing mostly 0 values
  • From: Michael Glaesemann
• Index ignored on column containing mostly 0 values
  • From: Leif Mortenson
• Re: partitioned table performance
  • From: Simon Riggs
• Re: partitioned table performance
  • From: Andreas Kostyrka
• Re: commit so slow program looks frozen
  • From: Bucky Jordan
• Re: Best COPY Performance
  • From: Stefan Kaltenbrunner
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Stefan Kaltenbrunner
• Re: Strange plan in pg 8.1.0
  • From: Steinar H. Gunderson
• Re: Strange plan in pg 8.1.0
  • From: Mattias Kregert
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Strange plan in pg 8.1.0
  • From: Tom Lane
• Re: Strange plan in pg 8.1.0
  • From: Mattias Kregert
• Re: Best COPY Performance
  • From: Spiegelberg, Greg
• Re: Strange plan in pg 8.1.0
  • From: Steinar H. Gunderson
• Strange plan in pg 8.1.0
  • From: Mattias Kregert
• Re: partitioned table performance
  • From: Simon Riggs
• Re: VACUUMs take twice as long across all nodes
  • From: Andreas Kostyrka
• Re: VACUUMs take twice as long across all nodes
  • From: Andrew Sullivan
• Re: VACUUMs take twice as long across all nodes
  • From: Andreas Kostyrka
• Re: VACUUMs take twice as long across all nodes
  • From: Andrew Sullivan
• Re: VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Re: VACUUMs take twice as long across all nodes
  • From: Andrew Sullivan
• partitioned table performance
  • From: Andreas Kostyrka
• Re: commit so slow program looks frozen
  • From: Merlin Moncure
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Michael Artz
• Re: commit so slow program looks frozen
  • From: Simon Riggs
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Merlin Moncure
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Merlin Moncure
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: VACUUMs take twice as long across all nodes
  • From: Tom Lane
• Re: query produces 1 GB temp file
  • From: Scott Marlowe
• Re: query produces 1 GB temp file
  • From: Thomas Burdairon
• Re: query produces 1 GB temp file
  • From: Dirk Lutzebäck
• Re: query produces 1 GB temp file
  • From: Alexander Staubo
• Re: query produces 1 GB temp file
  • From: Bricklen Anderson
• Re: query produces 1 GB temp file
  • From: Merlin Moncure
• Re: Regarding Bitmap Scan
  • From: soni de
• client crashes in PQfinish
  • From: soni de
• query produces 1 GB temp file
  • From: Dirk Lutzebaeck
• Re: VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Index ignored with "is not distinct from", 8.2 beta2
  • From: JEAN-PIERRE PELLETIER
• Re: query slows down drastically with increased number of
  • From: Tom Darci
• Re: query slows down drastically with increased number of fields
  • From: Tom Lane
• Re: query slows down drastically with increased number of fields
  • From: Jim C. Nasby
• Re: VACUUMs take twice as long across all nodes
  • From: Andrew Sullivan
• Re: query slows down drastically with increased number of fields
  • From: George Pavlov
• Re: VACUUMs take twice as long across all nodes
  • From: Jim C. Nasby
• Re: query slows down drastically with increased number of fields
  • From: Tom Lane
• Re: VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Re: Stored procedure slower than sql?
  • From: Jim C. Nasby
• Re: VACUUMs take twice as long across all nodes
  • From: Jim C. Nasby
• Re: Configuration Issue ?
  • From: Jim C. Nasby
• Re: OT: TCL vs Perl Re: commit so slow program looks frozen
  • From: Joshua D. Drake
• OT: TCL vs Perl Re: commit so slow program looks frozen
  • From: mark
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: commit so slow program looks frozen
  • From: Richard Troy
• Re: commit so slow program looks frozen
  • From: Richard Troy
• Re: Stored procedure slower than sql?
  • From: Matthew Peters
• Re: Stored procedure slower than sql?
  • From: Tom Lane
• Stored procedure slower than sql?
  • From: Matthew Peters
• Re: VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Re: commit so slow program looks frozen
  • From: Merlin Moncure
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: VACUUMs take twice as long across all nodes
  • From: Tom Lane
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: commit so slow program looks frozen
  • From: Rocco Altier
• Re: commit so slow program looks frozen
  • From: Magnus Hagander
• VACUUMs take twice as long across all nodes
  • From: Gavin Hamill
• Re: commit so slow program looks frozen
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: commit so slow program looks frozen
  • From: Joshua D. Drake
• Re: commit so slow program looks frozen
  • From: Scott Marlowe
• Re: Configuration Issue ?
  • From: Joshua D. Drake
• Re: Configuration Issue ?
  • From: Mark Lonsdale
• Re: Configuration Issue ?
  • From: Joshua D. Drake
• Re: Configuration Issue ?
  • From: Richard Huxton
• Re: Configuration Issue ?
  • From: Mark Lonsdale
• Re: commit so slow program looks frozen
  • From: Brian Hurt
• Re: Configuration Issue ?
  • From: Joshua D. Drake
• Configuration Issue ?
  • From: Mark Lonsdale
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: Best COPY Performance
  • From: Markus Schaber
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: commit so slow program looks frozen
  • From: Alvaro Herrera
• Re: ACCESS EXCLUSIVE lock
  • From: Atesz
• Re: Best COPY Performance
  • From: Craig A. James
• query slows down drastically with increased number of fields
  • From: Tom Darci
• Re: Best COPY Performance
  • From: Spiegelberg, Greg
• Re: Best COPY Performance
  • From: Craig A. James
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Worky Workerson
• commit so slow program looks frozen
  • From: Carlo Stonebanks
• Re: Best COPY Performance
  • From: Merlin Moncure
• Re: Problems using a function in a where clause
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Best COPY Performance
  • From: Merlin Moncure
• Re: Best COPY Performance
  • From: Markus Schaber
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Best COPY Performance
  • From: Alex Stapleton
• Re: Best COPY Performance
  • From: Craig A. James
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Copy database performance issue
  • From: Jim C. Nasby
• Re: Problems using a function in a where clause
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: Is ODBC that slow?
  • From: Carlo Stonebanks
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Optimizing disk throughput on quad Opteron
  • From: Bucky Jordan
• Re: Copy database performance issue
  • From: Jignesh Shah
• Re: Index on two columns not used
  • From: Markus Schaber
• Re: Slow functional indexes?
  • From: Stuart Bishop
• Re: Index on two columns not used
  • From: Péter Kovács
• Re: Best COPY Performance
  • From: Craig A. James
• Copy database performance issue
  • From: Steve
• Re: Best COPY Performance
  • From: Joshua D. Drake
• Re: Optimizing disk throughput on quad Opteron
  • From: Jim C. Nasby
• Re: Best COPY Performance
  • From: Jim C. Nasby
• Re: New hardware thoughts
  • From: Jim C. Nasby
• Re: Vacuum and Memory Loss
  • From: Jim C. Nasby
• Re: New hardware thoughts
  • From: Joshua D. Drake
• Re: New hardware thoughts
  • From: Vivek Khera
• Re: Optimizing disk throughput on quad Opteron
  • From: Joshua D. Drake
• Re: Optimizing disk throughput on quad Opteron
  • From: Vivek Khera
• Re: New hardware thoughts
  • From: Joshua D. Drake
• Re: New hardware thoughts
  • From: Vivek Khera
• Re: Optimizing disk throughput on quad Opteron
  • From: Joshua D. Drake
• Re: Optimizing disk throughput on quad Opteron
  • From: Vivek Khera
• Re: New hardware thoughts
  • From: Bucky Jordan
• Problems using a function in a where clause
  • From: Mara Dalponte
• Re: Index on two columns not used
  • From: Tom Lane
• Re: Best COPY Performance
  • From: Worky Workerson
• Re: Index on two columns not used
  • From: Markus Schaber
• Re: Best COPY Performance
  • From: Luke Lonergan
• Re: Index on two columns not used
  • From: Alvaro Herrera
• Re: Index on two columns not used
  • From: Markus Schaber
• Re: Optimizing disk throughput on quad Opteron
  • From: John Philips
• Re: Best COPY Performance
  • From: Markus Schaber
• Re: Vacuum and Memory Loss
  • From: Richard Huxton
• Re: New hardware thoughts
  • From: Arjen van der Meijden
• Re: New hardware thoughts
  • From: Joshua D. Drake
• Re: New hardware thoughts
  • From: Arjen van der Meijden
• Re: pgBench on Windows
  • From: Harald Armin Massa
• Re: Vacuum and Memory Loss
  • From: Dave Dutcher
• Re: New hardware thoughts
  • From: Bucky Jordan
• Re: Jdbc/postgres performance
  • From: Dave Cramer
• Re: Optimizing disk throughput on quad Opteron
  • From: Ben Suffolk
• Re: Optimizing disk throughput on quad Opteron
  • From: Joshua D. Drake
• Re: Is ODBC that slow?
  • From: Joshua D. Drake
• Re: Is ODBC that slow?
  • From: Alvaro Herrera
• Optimizing disk throughput on quad Opteron
  • From: John Philips
• Re: Is ODBC that slow?
  • From: Carlo Stonebanks
• Re: pgBench on Windows
  • From: Magnus Hagander
• Re: Index on two columns not used
  • From: Péter Kovács
• Re: VACUUM Performance
  • From: Tom Lane
• Re: Is ODBC that slow?
  • From: Joshua D. Drake
• Re: Is ODBC that slow?
  • From: Joshua D. Drake
• Re: Slow functional indexes?
  • From: Tom Lane
• Re: Is ODBC that slow?
  • From: Merlin Moncure
• Re: Slow functional indexes?
  • From: Merlin Moncure
• Re: Is ODBC that slow?
  • From: Alvaro Herrera
• Re: Best COPY Performance
  • From: Merlin Moncure
• Re: Is ODBC that slow?
  • From: Merlin Moncure
• Is ODBC that slow?
  • From: Carlo Stonebanks
• VACUUM Performance
  • From: Steve Oualline
• [no subject]
  • From: Unknown
• [no subject]
  • From: Unknown
• Re: New hardware thoughts
  • From: alvis
• Re: New hardware thoughts
  • From: Ben Suffolk
• Best COPY Performance
  • From: Worky Workerson
• Re: New hardware thoughts
  • From: Joshua D. Drake
• Re: New hardware thoughts
  • From: Ben Suffolk
• Re: New hardware thoughts
  • From: Ben Suffolk
• Re: New hardware thoughts
  • From: Dave Cramer
• Re: New hardware thoughts
  • From: Shane Ambler
• Re: measuring shared memory usage on Windows
  • From: David Boreham
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: VACUUM FULL ANALYZE on 8.1.4 is slower then on 8.0
  • From: Markus Schaber
• pgBench on Windows
  • From: Harald Armin Massa
• Re: measuring shared memory usage on Windows
  • From: Harald Armin Massa
• Re: measuring shared memory usage on Windows
  • From: Harald Armin Massa
• New hardware thoughts
  • From: Ben Suffolk
• Slow functional indexes?
  • From: Stuart Bishop
• Vacuum and Memory Loss
  • From: Mike
• Re: Swappiness setting on a linux pg server
  • From: Kevin
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Merlin Moncure
• Re: Swappiness setting on a linux pg server
  • From: Ron
• Re: DB Performance decreases due to often written/accessed table
  • From: Merlin Moncure
• Re: DB Performance decreases due to often written/accessed table
  • From: Jens Schipkowski
• Re: DB Performance decreases due to often written/accessed
  • From: Richard Huxton
• Re: DB Performance decreases due to often written/accessed table
  • From: Merlin Moncure
• Re: DB Performance decreases due to often written/accessed
  • From: Jim C. Nasby
• Re: DB Performance decreases due to often written/accessed
  • From: Richard Huxton
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: DB Performance decreases due to often written/accessed table
  • From: Jens Schipkowski
• Re: Swappiness setting on a linux pg server
  • From: Jim C. Nasby
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Jim C. Nasby
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Jim C. Nasby
• Re: Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: Swappiness setting on a linux pg server
  • From: Jim C. Nasby
• Re: DB Performance decreases due to often written/accessed
  • From: Richard Huxton
• Re: VACUUM FULL ANALYZE on 8.1.4 is slower then on 8.0
  • From: Tom Lane
• Re: VACUUM FULL ANALYZE on 8.1.4 is slower then on 8.0
  • From: Michael Fuhr
• Swappiness setting on a linux pg server
  • From: Tobias Brox
• Re: ACCESS EXCLUSIVE lock
  • From: Atesz
• VACUUM FULL ANALYZE on 8.1.4 is slower then on 8.0
  • From: Andrzej Zawadzki
• DB Performance decreases due to often written/accessed table
  • From: Jens Schipkowski
• [no subject]
  • From: Rohit_Behl
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Ioana Danes
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Ioana Danes
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Ioana Danes
• Re: measuring shared memory usage on Windows
  • From: Mark Kirkwood
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jeff Davis
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Tom Lane
• Re: index growth problem
  • From: Tom Lane
• Re: index growth problem
  • From: Jim C. Nasby
• Re: index growth problem
  • From: Graham Davis
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jim C. Nasby
• Re: index growth problem
  • From: Jim C. Nasby
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jeff Davis
• index growth problem
  • From: Graham Davis
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jim C. Nasby
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jeff Davis
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Dimitri Fontaine
• Re: [GENERAL] UDF and cache
  • From: Jim C. Nasby
• Re: [HACKERS] UDF and cache
  • From: Jim C. Nasby
• UDF and cache
  • From: jungmin shin
• Re: Postgresql 8.1.4 - performance issues for select on
  • From: Jeff Davis
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Ioana Danes
• Re: [ADMIN] autovacuum on a -mostly- r/o table
  • From: Larry Rosenman
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Ioana Danes
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Joshua Marsh
• Re: Postgresql 8.1.4 - performance issues for select on view using max
  • From: Dimitri Fontaine
• Postgresql 8.1.4 - performance issues for select on view using max
  • From: Ioana Danes
• Re: Optimization of this SQL sentence
  • From: Merlin Moncure
• Re: Optimization of this SQL sentence (SOLVED)
  • From: Jim C. Nasby
• Re: Optimization of this SQL sentence
  • From: Jim C. Nasby
• Re: [ADMIN] autovacuum on a -mostly- r/o table
  • From: Jim C. Nasby
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Jim C. Nasby
• Re: Index on two columns not used
  • From: Arnaud Lesauvage
• Re: Index on two columns not used
  • From: Tom Lane
• Re: Hints proposal
  • From: Robert Treat
• Re: ACCESS EXCLUSIVE lock
  • From: Tom Lane
• Re: ACCESS EXCLUSIVE lock
  • From: Scott Marlowe
• Re: Index on two columns not used
  • From: Arnaud Lesauvage
• ACCESS EXCLUSIVE lock
  • From: Atesz
• Re: Index on two columns not used
  • From: Heikki Linnakangas
• Re: Index on two columns not used
  • From: Arnaud Lesauvage
• Re: Index on two columns not used
  • From: Heikki Linnakangas
• Re: Jdbc/postgres performance
  • From: Merlin Moncure
• Re: Jdbc/postgres performance
  • From: Merlin Moncure
• Re: Jdbc/postgres performance
  • From: Heikki Linnakangas
• Re: Optimization of this SQL sentence
  • From: mark
• Re: Index on two columns not used
  • From: Arnaud Lesauvage
• Re: Jdbc/postgres performance
  • From: Rohit_Behl
• Re: Jdbc/postgres performance
  • From: Rohit_Behl
• Re: Index on two columns not used
  • From: Heikki Linnakangas
• Index on two columns not used
  • From: Arnaud Lesauvage
• Re: Optimization of this SQL sentence
  • From: Mark Kirkwood
• Re: Optimization of this SQL sentence
  • From: Mario Weilguni
• Re: Optimization of this SQL sentence
  • From: Ruben Rubio
• Re: Jdbc/postgres performance
  • From: Tom Lane
• Re: Jdbc/postgres performance
  • From: Merlin Moncure
• Re: Hints proposal
  • From: Tom Lane
• Re: Optimization of this SQL sentence
  • From: Craig A. James
• Re: Hints proposal
  • From: Robert Treat
• Re: [HACKERS] Hints proposal
  • From: Robert Treat
• Re: Jdbc/postgres performance
  • From: Bucky Jordan
• Re: Jdbc/postgres performance
  • From: Merlin Moncure
• Jdbc/postgres performance
  • From: Rohit_Behl
• Re: Optimization of this SQL sentence
  • From: Shane Ambler
• Re: Optimization of this SQL sentence
  • From: Christopher Browne
• Jdbc/postgres performance
  • From: Behl, Rohit (Infosys)
• Re: Optimization of this SQL sentence
  • From: Shane Ambler
• Re: Optimization of this SQL sentence
  • From: Chris Browne
• Re: Optimization of this SQL sentence
  • From: Chris Browne
• Re: Optimization of this SQL sentence
  • From: Merlin Moncure
• Re: Optimization of this SQL sentence
  • From: Mario Weilguni