Postgres Performance Date Index

• Thread Index

• Re: More shared buffers causes lower performances
  • From: Tom Lane
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Greg Smith
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Shane Ambler
• Re: More shared buffers causes lower performances
  • From: Devrim GÜNDÜZ
• Re: More shared buffers causes lower performances
  • From: Greg Smith
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Greg Smith
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Bill Moran
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Bill Moran
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: pg_dump performance
  • From: Jared Mauch
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: pg_dump performance
  • From: Heikki Linnakangas
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Bill Moran
• Re: pg_dump performance
  • From: Jared Mauch
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Florian Weimer
• Re: pg_dump performance
  • From: Heikki Linnakangas
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Fernando Hevia
• pg_dump performance
  • From: Jared Mauch
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: david
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Fernando Hevia
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Fernando Hevia
• Re: More shared buffers causes lower performances
  • From: Greg Smith
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Greg Smith
• Anyone running on RHEL Cluster?
  • From: Chris Hoover
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: More shared buffers causes lower performances
  • From: Pavel Stehule
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Mark Mielke
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: With 4 disks should I go for RAID 5 or RAID 10
  • From: Bill Moran
• With 4 disks should I go for RAID 5 or RAID 10
  • From: Fernando Hevia
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: More shared buffers causes lower performances
  • From: Simon Riggs
• Re: More shared buffers causes lower performances
  • From: Cédric Villemain
• More shared buffers causes lower performances
  • From: Guillaume Smet
• Re: viewing source code
  • From: Michael Stone
• Re: viewing source code
  • From: Tom Lane
• Re: viewing source code
  • From: Trevor Talbot
• Re: viewing source code
  • From: Trevor Talbot
• Re: function body actors (was: viewing source code)
  • From: Andrew Sullivan
• Re: [HACKERS] function body actors (was: viewing source code)
  • From: Andrew Sullivan
• Re: viewing source code
  • From: Dan Langille
• Re: viewing source code
  • From: Merlin Moncure
• Re: function body actors (was: viewing source code)
  • From: Pavel Stehule
• Re: viewing source code
  • From: Bruce Momjian
• Re: function body actors (was: viewing source code)
  • From: Merlin Moncure
• Re: function body actors (was: viewing source code)
  • From: Pavel Stehule
• Re: function body actors (was: viewing source code)
  • From: Merlin Moncure
• Re: function body actors (was: viewing source code)
  • From: Tom Lane
• function body actors (was: viewing source code)
  • From: Merlin Moncure
• Re: viewing source code
  • From: Harald Armin Massa
• Re: viewing source code
  • From: Tom Lane
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Greg Smith
• Re: viewing source code
  • From: Andrew Sullivan
• Re: viewing source code
  • From: Alvaro Herrera
• Re: performance index scan vs bitmap-seq scan.
  • From: Scott Marlowe
• performance index scan vs bitmap-seq scan.
  • From: S Golly
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Andrew Sullivan
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Chris Browne
• Re: viewing source code
  • From: Andrew Sullivan
• Re: viewing source code
  • From: Andrew Sullivan
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Joshua D. Drake
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Joshua D. Drake
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Joshua D. Drake
• Re: viewing source code
  • From: Trevor Talbot
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: A.M.
• Re: viewing source code
  • From: Joshua D. Drake
• Re: viewing source code
  • From: Roberts, Jon
• Re: Reinitialising stats once only without restarting
  • From: Anton Melser
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Roberts, Jon
• Re: Dual core Opterons beating quad core Xeons?
  • From: Jan de Visser
• Re: Reinitialising stats once only without restarting
  • From: Alvaro Herrera
• Re: Minimizing dead tuples caused by update triggers
  • From: Dimitri Fontaine
• Reinitialising stats once only without restarting
  • From: Anton Melser
• Re: Dual core Opterons beating quad core Xeons?
  • From: Tom Lane
• Re: Dual core Opterons beating quad core Xeons?
  • From: Joshua D. Drake
• Re: Minimizing dead tuples caused by update triggers
  • From: Decibel!
• Re: Dual core Opterons beating quad core Xeons?
  • From: Decibel!
• Re: Measuring table and index bloat
  • From: Decibel!
• Re: Minimizing dead tuples caused by update triggers
  • From: Tom Lane
• Minimizing dead tuples caused by update triggers
  • From: Dan Harris
• Re: Dual core Opterons beating quad core Xeons?
  • From: Gregory Stark
• Re: Optimising a query
  • From: Paul Lambert
• Re: Dual core Opterons beating quad core Xeons?
  • From: Greg Smith
• Re: Dual core Opterons beating quad core Xeons?
  • From: Joshua D. Drake
• Re: Dual core Opterons beating quad core Xeons?
  • From: Ron Mayer
• Re: Dual core Opterons beating quad core Xeons?
  • From: Scott Marlowe
• Re: Dual core Opterons beating quad core Xeons?
  • From: Joshua D. Drake
• Re: Dual core Opterons beating quad core Xeons?
  • From: Scott Marlowe
• Re: Dual core Opterons beating quad core Xeons?
  • From: Joshua D. Drake
• Re: Dual core Opterons beating quad core Xeons?
  • From: Greg Smith
• Re: Optimising a query
  • From: Jeremy Harris
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Trevor Talbot
• Re: Dual core Opterons beating quad core Xeons?
  • From: Scott Marlowe
• Re: Dual core Opterons beating quad core Xeons?
  • From: Gregory Stark
• Re: Dual core Opterons beating quad core Xeons?
  • From: Cédric Villemain
• Dual core Opterons beating quad core Xeons?
  • From: Stuart Bishop
• Re: Optimising a query
  • From: Gregory Stark
• Re: Optimising a query
  • From: Gregory Stark
• Re: Optimising a query
  • From: Richard Huxton
• Re: Optimising a query
  • From: Paul Lambert
• Optimising a query
  • From: Paul Lambert
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Joshua D. Drake
• Re: viewing source code
  • From: Richard Huxton
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Roberts, Jon
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Heikki Linnakangas
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Dave Page
• Re: viewing source code
  • From: Kris Jurka
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Robert Bernabe
• Re: Multi-threading friendliness
  • From: James Mansion
• Multi-threading friendliness (was: libgcc double-free, backend won't die)
  • From: Craig James
• Re: update 600000 rows
  • From: H. Hall
• Re: viewing source code
  • From: Joshua D. Drake
• Re: VACUUM FREEZE output more than double input
  • From: Kevin Grittner
• Re: viewing source code
  • From: Merlin Moncure
• Re: viewing source code
  • From: Roberts, Jon
• Re: libgcc double-free, backend won't die
  • From: Bruce Momjian
• Re: SELECT * FROM table is too slow
  • From: andrew
• Re: libgcc double-free, backend won't die
  • From: James Mansion
• Re: update 600000 rows
  • From: andrew
• Re: Large Objects and Toast
  • From: Usama Dar
• Re: libgcc double-free, backend won't die
  • From: Gregory Stark
• Re: SELECT * FROM table is too slow
  • From: Steinar H. Gunderson
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: update 600000 rows
  • From: Merlin Moncure
• Re: SELECT * FROM table is too slow
  • From: Joshua D. Drake
• SELECT * FROM table is too slow
  • From: Adam PAPAI
• Re: libgcc double-free, backend won't die
  • From: Gregory Stark
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: James Mansion
• Re: update 600000 rows
  • From: H. Hall
• Re: RAID arrays and performance
  • From: Bruce Momjian
• Re: update 600000 rows
  • From: andrew
• Re: update 600000 rows
  • From: Greg Smith
• Re: update 600000 rows
  • From: Loïc Marteau
• Re: explanation for seeks in VACUUM
  • From: Jeff Davis
• Re: update 600000 rows
  • From: Steve Crawford
• update 600000 rows
  • From: okparanoid
• Re: explanation for seeks in VACUUM
  • From: Tom Lane
• Re: VACUUM FREEZE output more than double input
  • From: Tom Lane
• Re: viewing source code
  • From: Alvaro Herrera
• Re: viewing source code
  • From: Jonah H. Harris
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Andreas Kretschmer
• Re: viewing source code
  • From: Jonah H. Harris
• Re: explanation for seeks in VACUUM (8.2.4)
  • From: Jeff Davis
• explanation for seeks in VACUUM
  • From: Jeff Davis
• Re: viewing source code
  • From: Bill Moran
• VACUUM FREEZE output more than double input
  • From: Kevin Grittner
• Re: viewing source code
  • From: Alvaro Herrera
• Large Objects and Toast
  • From: Campbell, Lance
• Re: viewing source code
  • From: Joshua D. Drake
• Re: Heavy write activity on first vacuum of fresh TOASTa
  • From: Matthew
• Re: Heavy write activity on first vacuum of fresh TOASTa
  • From: Tom Lane
• Re: viewing source code
  • From: Bill Moran
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Heavy write activity on first vacuum of fresh TOASTa
  • From: Matthew
• Re: viewing source code
  • From: Roberts, Jon
• Re: viewing source code
  • From: Bill Moran
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• viewing source code
  • From: Roberts, Jon
• Re: Limited performance on multi core server
  • From: Heikki Linnakangas
• Re: Need help on parameters and their values to tune the postgresql database
  • From: Heikki Linnakangas
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Tom Lane
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Russell Smith
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Simon Riggs
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Putting files into fields in a table
  • From: Campbell, Lance
• Re: Putting files into fields in a table
  • From: Erik Jones
• Re: Putting files into fields in a table
  • From: Alvaro Herrera
• Re: Putting files into fields in a table
  • From: Campbell, Lance
• Re: Putting files into fields in a table
  • From: Alexander Staubo
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Simon Riggs
• Putting files into fields in a table
  • From: Campbell, Lance
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Tom Lane
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Simon Riggs
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Alvaro Herrera
• Re: Limited performance on multi core server
  • From: Joshua D. Drake
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Simon Riggs
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Tom Lane
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Limited performance on multi core server
  • From: Simon Riggs
• Re: Heavy write activity on first vacuum of fresh TOAST data
  • From: Simon Riggs
• Heavy write activity on first vacuum of fresh TOAST data
  • From: Kevin Grittner
• Re: Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.
  • From: Piotr Gasidło
• Re: Limited performance on multi core server
  • From: Joshua D. Drake
• Re: Limited performance on multi core server
  • From: Joshua D. Drake
• Re: URI to kind of a benchmark
  • From: Stefan Kaltenbrunner
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• URI to kind of a benchmark
  • From: Harald Armin Massa
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Greg Smith
• Re: Limited performance on multi core server
  • From: Claus Guttesen
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• Re: Limited performance on multi core server
  • From: Matthew Lunnon
• Re: Limited performance on multi core server
  • From: Sven Geisler
• Re: Limited performance on multi core server
  • From: Claus Guttesen
• Re: Limited performance on multi core server
  • From: Claus Guttesen
• Re: Limited performance on multi core server
  • From: Steinar H. Gunderson
• Limited performance on multi core server
  • From: Matthew Lunnon
• Need help on parameters and their values to tune the postgresql database
  • From: Bebarta, Simanchala
• Re: database tuning
  • From: Joshua D. Drake
• Re: database tuning
  • From: Michael Stone
• Re: database tuning
  • From: Greg Smith
• Re: database tuning
  • From: kelvan
• Re: TB-sized databases
  • From: Simon Riggs
• Re: database tuning
  • From: Richard Huxton
• Re: database tuning
  • From: Erik Jones
• Re: database tuning
  • From: Scott Marlowe
• Re: database tuning
  • From: Alvaro Herrera
• Re: database tuning
  • From: kelvan
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Gregory Stark
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Joshua D. Drake
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Magnus Hagander
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Alvaro Herrera
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Alvaro Herrera
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Alvaro Herrera
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Re: libgcc double-free, backend won't die
  • From: Tom Lane
• Re: libgcc double-free, backend won't die
  • From: Craig James
• Slow Query
  • From: Pallav Kalva
• Is it spam or not?
  • From: Manolo _
• Re: Benchmarking PG
  • From: Heikki Linnakangas
• Is it spam or not?
  • From: Manolo _
• Re: Benchmarking PG
  • From: Manolo _
• Re: libgcc double-free, backend won't die
  • From: Alvaro Herrera
• Re: Benchmarking PG
  • From: Josh Tolley
• Benchmarking PG
  • From: Manolo _
• libgcc double-free, backend won't die
  • From: Craig James
• Re: database tuning
  • From: Greg Smith
• Fwd: Re: database tuning
  • From: Kevin Grittner
• Re: database tuning
  • From: Kevin Grittner
• Re: database tuning
  • From: kelvan
• Re: database tuning
  • From: Scott Marlowe
• Re: Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.
  • From: Pavel Stehule
• Re: Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.
  • From: Richard Huxton
• Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.
  • From: Piotr Gasidło
• Re: Utilizing multiple cores for one query
  • From: Marko Kreen
• Re: database tuning
  • From: Richard Huxton
• Re: Vacuum full since 15 hours
  • From: Heikki Linnakangas
• Vacuum full since 15 hours
  • From: Hervé Piedvache
• Re: Combining two bitmap scans out performs a single regular index scan?
  • From: Mark Mielke
• Re: Combining two bitmap scans out performs a single regular index scan?
  • From: Tom Lane
• Combining two bitmap scans out performs a single regular index scan?
  • From: Mark Mielke
• Re: Cost-Based Vacuum Delay tuning
  • From: Alvaro Herrera
• Measuring table and index bloat
  • From: Greg Smith
• Re: TB-sized databases
  • From: Ron Mayer
• Re: database tuning
  • From: kelvan
• Re: TB-sized databases
  • From: Robert Treat
• Re: Cost-Based Vacuum Delay tuning
  • From: Erik Jones
• Re: Cost-Based Vacuum Delay tuning
  • From: Guillaume Cottenceau
• Re: Trouble with LEFT JOIN using VIEWS.
  • From: Tom Lane
• Re: Cost-Based Vacuum Delay tuning
  • From: Erik Jones
• Trouble with LEFT JOIN using VIEWS.
  • From: Piotr Gasidło
• Cost-Based Vacuum Delay tuning
  • From: Guillaume Cottenceau
• Re: database tuning
  • From: Simon Riggs
• Re: database tuning
  • From: Richard Huxton
• Re: TB-sized databases
  • From: Ron Mayer
• Re: TB-sized databases
  • From: Ron Mayer
• Re: TB-sized databases
  • From: Tom Lane
• Re: TB-sized databases
  • From: Tom Lane
• Re: TB-sized databases
  • From: Ron Mayer
• database tuning
  • From: kelvan
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Mark Cave-Ayland
• Re: TB-sized databases
  • From: Michael Stone
• Re: TB-sized databases
  • From: Tom Lane
• Re: TB-sized databases
  • From: Matthew
• Re: TB-sized databases
  • From: Tom Lane
• Re: TB-sized databases
  • From: Matthew
• Re: TB-sized databases
  • From: Tom Lane
• Re: TB-sized databases
  • From: Michael Stone
• Re: TB-sized databases
  • From: Simon Riggs
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Dave Page
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Mark Cave-Ayland
• Re: TB-sized databases
  • From: Decibel!
• Re: autovacuum: recommended?
  • From: Decibel!
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Scott Marlowe
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Merlin Moncure
• Re: TB-sized databases
  • From: Robert Treat
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Bill Moran
• Re: Optimizer Not using the Right plan
  • From: galy lee
• Re: Bad query plans for queries on partitioned table
  • From: Julian Mehnle
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Usama Dar
• Re: Bad query plans for queries on partitioned table
  • From: Gregory Stark
• Re: Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: ismo . tuononen
• Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)
  • From: Robert Bernabe
• Re: RAID arrays and performance
  • From: Greg Smith
• Re: Bad query plans for queries on partitioned table
  • From: Julian Mehnle
• Re: RAID arrays and performance
  • From: Mark Mielke
• Re: Bad query plans for queries on partitioned table
  • From: Gregory Stark
• Re: RAID arrays and performance
  • From: James Mansion
• Re: RAID arrays and performance
  • From: Mark Mielke
• Re: Bad query plans for queries on partitioned table
  • From: Julian Mehnle
• Re: Bad query plans for queries on partitioned table
  • From: Gregory Stark
• Re: RAID arrays and performance
  • From: James Mansion
• Re: Bad query plans for queries on partitioned table
  • From: Julian Mehnle
• Bad query plans for queries on partitioned table
  • From: Julian Mehnle
• Re: RAID arrays and performance
  • From: Gregory Stark
• Re: Optimizer Not using the Right plan
  • From: Pallav Kalva
• Re: RAID arrays and performance
  • From: Matthew
• Re: Optimizer Not using the Right plan
  • From: Tom Lane
• Re: RAID arrays and performance
  • From: Mark Mielke
• Re: RAID arrays and performance
  • From: Matthew
• Re: RAID arrays and performance
  • From: Mark Mielke
• Re: RAID arrays and performance
  • From: Mark Mielke
• Optimizer Not using the Right plan
  • From: Pallav Kalva
• Re: RAID arrays and performance
  • From: Matthew
• Re: RAID arrays and performance
  • From: James Mansion
• Re: RAID arrays and performance
  • From: James Mansion
• Re: RAID arrays and performance
  • From: Mark Mielke
• Re: RAID arrays and performance
  • From: Gregory Stark
• Re: RAID arrays and performance
  • From: Matthew
• Re: RAID arrays and performance
  • From: Matthew
• Re: RAID arrays and performance
  • From: Gregory Stark
• Re: RAID arrays and performance
  • From: Mark Mielke
• Re: RAID arrays and performance
  • From: Matthew
• Re: RAID arrays and performance
  • From: Mark Mielke
• Re: Utilizing multiple cores for one query
  • From: Matthew
• Re: RAID arrays and performance
  • From: Matthew
• Re: RAID arrays and performance
  • From: Gregory Stark
• RAID arrays and performance
  • From: Matthew
• Re: Training Recommendations
  • From: Simon Riggs
• Re: Training Recommendations
  • From: Joshua D. Drake
• Re: Dealing with big tables
  • From: Merlin Moncure
• Re: Training Recommendations
  • From: Robert Treat
• Re: Training Recommendations
  • From: Paul Lindner
• Re: Dealing with big tables
  • From: Matthew
• Re: EXPLAIN ANALYZE time calculations
  • From: Tom Lane
• Re: EXPLAIN ANALYZE time calculations
  • From: Michael Glaesemann
• Re: EXPLAIN ANALYZE time calculations
  • From: Tom Lane
• EXPLAIN ANALYZE time calculations
  • From: Michael Glaesemann
• Re: PostgreSQL 8.2.5 slow performance on INSERT on Linux
  • From: Beyers Cronje
• Re: Dealing with big tables
  • From: Mark Kirkwood
• Re: PostgreSQL 8.2.5 slow performance on INSERT on Linux
  • From: Greg Smith
• Re: PostgreSQL 8.2.5 slow performance on INSERT on Linux
  • From: Pavel Stehule
• PostgreSQL 8.2.5 slow performance on INSERT on Linux
  • From: Beyers Cronje
• Re: Training Recommendations
  • From: Usama Munir Dar
• Re: Training Recommendations
  • From: Guido Neitzer
• Re: Training Recommendations
  • From: Merlin Moncure
• Re: Dealing with big tables
  • From: Mindaugas
• Re: Dealing with big tables
  • From: Gregory Stark
• Re: Dealing with big tables
  • From: Guillaume Smet
• Re: Dealing with big tables
  • From: Mindaugas
• Re: Dealing with big tables
  • From: Sami Dalouche
• Dealing with big tables
  • From: Mindaugas
• Re: Utilizing multiple cores for one query
  • From: Jean-David Beyer
• Re: Utilizing multiple cores for one query
  • From: Jonah H. Harris
• Re: Utilizing multiple cores for one query
  • From: henk de wit
• Re: Utilizing multiple cores for one query
  • From: Jonah H. Harris
• Utilizing multiple cores for one query
  • From: henk de wit
• Re: Appending "LIMIT" to query drastically decreases performance
  • From: cluster
• Re: TB-sized databases
  • From: Luke Lonergan
• Re: Appending "LIMIT" to query drastically decreases performance
  • From: Bill Moran
• Re: GiST indexing tuples
  • From: Matthew
• Re: Appending "LIMIT" to query drastically decreases performance
  • From: Matthew
• Appending "LIMIT" to query drastically decreases performance
  • From: cluster
• Re: TB-sized databases
  • From: Csaba Nagy
• Re: TB-sized databases
  • From: Trevor Talbot
• Re: Training Recommendations
  • From: Robert Treat
• Re: TB-sized databases
  • From: Simon Riggs
• Re: TB-sized databases
  • From: Russell Smith
• Re: Configuring a Large RAM PostgreSQL Server
  • From: Josh Berkus
• Re: TB-sized databases
  • From: Mark Kirkwood
• Re: clear pg_stats
  • From: Magnus Hagander
• Re: clear pg_stats
  • From: Heikki Linnakangas
• clear pg_stats
  • From: Campbell, Lance
• Re: GiST indexing tuples
  • From: Steinar H. Gunderson
• Re: GiST indexing tuples
  • From: Matthew T. O'Connor
• Re: Configuring a Large RAM PostgreSQL Server
  • From: Alvaro Herrera
• Re: Configuring a Large RAM PostgreSQL Server
  • From: Alex Hochberger
• Re: Configuring a Large RAM PostgreSQL Server
  • From: Richard Huxton
• Configuring a Large RAM PostgreSQL Server
  • From: Alex Hochberger
• Re: TB-sized databases
  • From: Csaba Nagy
• Re: TB-sized databases
  • From: Stephen Frost
• Re: 7.4 Checkpoint Question
  • From: Brad Nicholson
• Re: TB-sized databases
  • From: Simon Riggs
• Re: 7.4 Checkpoint Question
  • From: Simon Riggs
• Re: 7.4 Checkpoint Question
  • From: Andrew Sullivan
• Re: TB-sized databases
  • From: Tom Lane
• Re: Query only slow on first run
  • From: Tom Lane
• 7.4 Checkpoint Question
  • From: Brad Nicholson
• Re: TB-sized databases
  • From: Gregory Stark
• Re: Query only slow on first run
  • From: cluster
• Re: Query only slow on first run
  • From: Scott Marlowe
• Re: Query only slow on first run
  • From: Tom Lane
• Re: Query only slow on first run
  • From: Jean-David Beyer
• Re: Query only slow on first run
  • From: cluster
• Re: TB-sized databases
  • From: david
• Re: Query only slow on first run
  • From: Steinar H. Gunderson
• Re: Query only slow on first run
  • From: cluster
• Re: TB-sized databases
  • From: Matthew
• Re: TB-sized databases
  • From: Simon Riggs
• Re: TB-sized databases
  • From: Simon Riggs
• Re: Query only slow on first run
  • From: Tom Lane
• Re: Training Recommendations
  • From: Usama Munir Dar
• Re: Windows XP selects are very slow
  • From: Usama Munir Dar
• Re: GiST indexing tuples
  • From: Matthew
• Re: Query only slow on first run
  • From: Dave Dutcher
• Re: GiST indexing tuples
  • From: Tom Lane
• Optimizer regression 8.2.1 -> 8.2.3 on TSEARCH2 queries with ORDER BY and LIMIT
  • From: Brendan McMahon
• Re: TB-sized databases
  • From: Alvaro Herrera
• Re: TB-sized databases
  • From: Pablo Alcaraz
• Re: Query only slow on first run
  • From: Craig James
• Re: TB-sized databases
  • From: Matthew
• Re: TB-sized databases
  • From: Pablo Alcaraz
• Re: TB-sized databases
  • From: Csaba Nagy
• Re: TB-sized databases
  • From: Bill Moran
• Re: TB-sized databases
  • From: david
• Re: TB-sized databases
  • From: Gregory Stark
• Re: TB-sized databases
  • From: Bill Moran
• Re: TB-sized databases
  • From: Csaba Nagy
• Re: GiST indexing tuples
  • From: Gregory Stark
• Re: TB-sized databases
  • From: Bill Moran
• Re: GiST indexing tuples
  • From: Matthew
• Re: TB-sized databases
  • From: Matthew
• Re: Windows XP selects are very slow
  • From: Richard Huxton
• Re: Query only slow on first run
  • From: tmp
• Windows XP selects are very slow
  • From: Shadkam Islam
• Re: Query only slow on first run
  • From: Steinar H. Gunderson
• Re: Query only slow on first run
  • From: Tom Lane
• Re: Query only slow on first run
  • From: Dave Dutcher
• Re: Query only slow on first run
  • From: Steinar H. Gunderson
• Re: Query only slow on first run
  • From: cluster
• Re: TB-sized databases
  • From: Pablo Alcaraz
• Re: TB-sized databases
  • From: Simon Riggs
• Re: TB-sized databases
  • From: Peter Koczan
• Re: Query only slow on first run
  • From: Dave Dutcher
• Re: Query only slow on first run
  • From: Bill Moran
• Re: Query only slow on first run
  • From: cluster
• Re: GiST indexing tuples
  • From: Steinar H. Gunderson
• GiST indexing tuples
  • From: Matthew
• Re: Query only slow on first run
  • From: Tom Lane
• Re: Query only slow on first run
  • From: Kevin Kempter
• Re: Query only slow on first run
  • From: Andrew Sullivan
• Query only slow on first run
  • From: cluster
• Re: 8.1 planner problem ?
  • From: Heikki Linnakangas
• 8.1 planner problem ?
  • From: Gianluca Alberici
• Re: PostgreSQL performance on various distribution stock kernels
  • From: Greg Smith
• Re: PostgreSQL performance on various distribution stock kernels
  • From: Damon Hart
• Re: PostgreSQL performance on various distribution stock kernels
  • From: Damon Hart
• Re: PostgreSQL performance on various distribution stock kernels
  • From: Scott Marlowe
• Re: PostgreSQL performance on various distribution stock kernels
  • From: Tom Lane
• Re: PostgreSQL performance on various distribution stock kernels
  • From: Scott Marlowe
• Re: PostgreSQL performance on various distribution stock kernels
  • From: Alexander Staubo
• PostgreSQL performance on various distribution stock kernels
  • From: Damon Hart
• Re: Base de Datos Transaccional
  • From: Pablo Alcaraz
• Re: Base de Datos Transaccional
  • From: Peter T. Breuer
• Base de Datos Transaccional
  • From: Fabio Arias
• Re: TB-sized databases
  • From: Stephen Cook
• Re: TB-sized databases
  • From: Pablo Alcaraz
• Re: TB-sized databases
  • From: Oleg Bartunov
• Re: TB-sized databases
  • From: Joshua D. Drake
• TB-sized databases
  • From: Peter Koczan
• Re: doubt with pg_dump and high concurrent used databases
  • From: Peter Childs
• Re: Problems with PostGreSQL and Windows 2003
  • From: Heikki Linnakangas
• Re: doubt with pg_dump and high concurrent used databases
  • From: Pablo Alcaraz
• Re: doubt with pg_dump and high concurrent used databases
  • From: Tom Lane
• Re: doubt with pg_dump and high concurrent used databases
  • From: Peter Childs
• Re: doubt with pg_dump and high concurrent used databases
  • From: Erik Jones
• Re: doubt with pg_dump and high concurrent used databases
  • From: Heikki Linnakangas
• doubt with pg_dump and high concurrent used databases
  • From: Pablo Alcaraz
• Re: Problems with PostGreSQL and Windows 2003
  • From: claudia . amorim
• Re: Problems with PostGreSQL and Windows 2003
  • From: Scott Marlowe
• Re: Problems with PostGreSQL and Windows 2003
  • From: claudia . amorim
• Re: Problems with PostGreSQL and Windows 2003
  • From: Scott Marlowe
• Re: Problems with PostGreSQL and Windows 2003
  • From: claudia . amorim
• Re: Performance problem with UNION ALL view and domains
  • From: Dean Rasheed
• Re: Problems with PostGreSQL and Windows 2003
  • From: claudia . amorim
• Re: Problems with PostGreSQL and Windows 2003
  • From: Heikki Linnakangas
• Problems with PostGreSQL and Windows 2003
  • From: claudia . amorim
• Re: Performance problem with UNION ALL view and domains
  • From: Tom Lane
• Re: Performance problem with UNION ALL view and domains
  • From: Jeff Larsen
• Performance problem with UNION ALL view and domains
  • From: Dean Rasheed
• Re: tuning for TPC-C benchmark
  • From: Heikki Linnakangas
• Re: tuning for TPC-C benchmark
  • From: Jonah H. Harris
• Re: tuning for TPC-C benchmark
  • From: Kevin Grittner
• Re: tuning for TPC-C benchmark
  • From: Jonah H. Harris
• Re: tuning for TPC-C benchmark
  • From: Bill Moran
• tuning for TPC-C benchmark
  • From: giuseppe-r@xxxxxxxxxx
• Postgres ignoring index when using left outer join.
  • From: Matthew Schumacher
• Re: autovacuum: recommended?
  • From: Greg Smith
• Re: autovacuum: recommended?
  • From: Joshua D. Drake
• Re: autovacuum: recommended?
  • From: Jean-David Beyer
• Re: autovacuum: recommended?
  • From: Tom Lane
• Re: autovacuum: recommended?
  • From: Bill Moran
• Re: autovacuum: recommended?
  • From: Jean-David Beyer
• Re: autovacuum: recommended?
  • From: tv
• Re: autovacuum: recommended?
  • From: Decibel!
• Re: autovacuum: recommended?
  • From: Decibel!
• Re: autovacuum: recommended?
  • From: Decibel!
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Ow Mun Heng
• RE: Performance problem (outer join + view + non-strict functions)‏
  • From: Dean Rasheed
• Re: autovacuum: recommended?
  • From: gabor
• Re: autovacuum: recommended?
  • From: Tobias Brox
• Re: Performance problem (outer join + view + non-strict functions)‏
  • From: Tom Lane
• Re: work_mem and shared_buffers
  • From: Scott Marlowe
• Re: work_mem and shared_buffers
  • From: Simon Riggs
• Performance problem (outer join + view + non-strict functions)‏
  • From: Dean Rasheed
• Re: Curious about dead rows.
  • From: Kevin Grittner
• Re: Curious about dead rows.
  • From: Merlin Moncure
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Jonah H. Harris
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Josh Trutwin
• Re: Clustered/covering indexes (or lack thereof :-)
  • From: Bill Moran
• Re: Clustered/covering indexes (or lack thereof :-)
  • From: Jeff Davis
• Re: Clustered/covering indexes (or lack thereof :-)
  • From: Heikki Linnakangas
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Ivan Voras
• Clustered/covering indexes (or lack thereof :-)
  • From: adrobj
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Jonah H. Harris
• Re: Curious about dead rows.
  • From: Brad Nicholson
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Dave Dutcher
• Re: autovacuum: recommended?
  • From: tv
• Re: autovacuum: recommended?
  • From: Csaba Nagy
• Re: autovacuum: recommended?
  • From: Tobias Brox
• Re: autovacuum: recommended?
  • From: hubert depesz lubaczewski
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Ow Mun Heng
• autovacuum: recommended?
  • From: Gábor Farkas
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Bruce Momjian
• Re: dell versus hp
  • From: Vivek Khera
• Re: Curious about dead rows.
  • From: Erik Jones
• Re: dell versus hp
  • From: Jeff Trout
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Craig James
• Re: dell versus hp
  • From: Jeff Frost
• Re: dell versus hp
  • From: Merlin Moncure
• Re: Curious about dead rows.
  • From: Tom Lane
• Re: dell versus hp
  • From: Alan Hodgson
• Re: dell versus hp
  • From: Jeff Frost
• Re: dell versus hp
  • From: Alan Hodgson
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Russell Smith
• Re: Curious about dead rows.
  • From: Alvaro Herrera
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Mario Weilguni
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Andrew Sullivan
• Re: Curious about dead rows.
  • From: Andrew Sullivan
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Andrew Sullivan
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Alvaro Herrera
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Merlin Moncure
• Re: dell versus hp
  • From: Merlin Moncure
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Merlin Moncure
• Re: Curious about dead rows.
  • From: Ansgar -59cobalt- Wiechers
• Re: Curious about dead rows.
  • From: Alvaro Herrera
• Re: Curious about dead rows.
  • From: Trevor Talbot
• Re: Curious about dead rows.
  • From: Alvaro Herrera
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Andrew Sullivan
• Re: Curious about dead rows.
  • From: Andrew Sullivan
• Re: dell versus hp
  • From: Jeff Frost
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: dell versus hp
  • From: Alan Hodgson
• Re: Curious about dead rows.
  • From: Andrew Sullivan
• Re: ERROR: "invalid memory alloc request size" or "unexpected end of data" on large table
  • From: Stephane Bailliez
• random_page_cost etc. per tablespace?
  • From: Jens-Wolfhard Schicke
• Re: Need to run CLUSTER to keep performance
  • From: Rafael Martinez
• Re: Need to run CLUSTER to keep performance
  • From: Rafael Martinez
• Re: ERROR: "invalid memory alloc request size" or "unexpected end of data" on large table
  • From: Tom Lane
• ERROR: "invalid memory alloc request size" or "unexpected end of data" on large table
  • From: Stephane Bailliez
• Re: difference between a unique constraint and a unique index ???
  • From: Dave Cramer
• Re: Need to run CLUSTER to keep performance
  • From: Heikki Linnakangas
• Re: Need to run CLUSTER to keep performance
  • From: Scott Marlowe
• Re: Need to run CLUSTER to keep performance
  • From: Heikki Linnakangas
• Re: difference between a unique constraint and a unique index ???
  • From: Tom Lane
• Re: Need to run CLUSTER to keep performance
  • From: Bill Moran
• Re: Need to run CLUSTER to keep performance
  • From: Scott Marlowe
• Re: Curious about dead rows.
  • From: Andrew Sullivan
• Re: Need to run CLUSTER to keep performance
  • From: Heikki Linnakangas
• Re: Need to run CLUSTER to keep performance
  • From: Rafael Martinez
• Re: Need to run CLUSTER to keep performance
  • From: Rafael Martinez
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Erik Jones
• Re: difference between a unique constraint and a unique index ???
  • From: Dave Cramer
• Re: difference between a unique constraint and a unique index ???
  • From: Alvaro Herrera
• difference between a unique constraint and a unique index ???
  • From: Dave Cramer
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Shane Ambler
• Re: work_mem and shared_buffers
  • From: Cédric Villemain
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Steinar H. Gunderson
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Joshua D. Drake
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Dimitri
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Scott Marlowe
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Joshua D. Drake
• Re: Curious about dead rows.
  • From: Jean-David Beyer
• Re: Curious about dead rows.
  • From: Tom Lane
• Curious about dead rows.
  • From: Jean-David Beyer
• Re: Join performance
  • From: Russell Smith
• Re: Can I Determine if AutoVacuum Does Anything?
  • From: Alvaro Herrera
• Can I Determine if AutoVacuum Does Anything?
  • From: David Crane
• Re: [HACKERS] Estimation problem with a LIKE clause containing a /
  • From: Guillaume Smet
• Re: work_mem and shared_buffers
  • From: Scott Marlowe
• Re: work_mem and shared_buffers
  • From: Erik Jones
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Ron Mayer
• Re: work_mem and shared_buffers
  • From: Scott Marlowe
• Re: work_mem and shared_buffers
  • From: Campbell, Lance
• Re: work_mem and shared_buffers
  • From: Scott Marlowe
• Re: dell versus hp
  • From: Vivek Khera
• Re: work_mem and shared_buffers
  • From: Campbell, Lance
• Re: work_mem and shared_buffers
  • From: Bill Moran
• Re: work_mem and shared_buffers
  • From: Campbell, Lance
• Re: dell versus hp
  • From: Greg Smith
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Bill Moran
• Re: work_mem and shared_buffers
  • From: Heikki Linnakangas
• work_mem and shared_buffers
  • From: Campbell, Lance
• Re: dell versus hp
  • From: Scott Marlowe
• Re: dell versus hp
  • From: Claus Guttesen
• Re: [HACKERS] Estimation problem with a LIKE clause containing a /
  • From: Guillaume Smet
• Re: [HACKERS] Estimation problem with a LIKE clause containing a /
  • From: Tom Lane
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Greg Smith
• Re: dell versus hp
  • From: Jurgen Haan
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Scott Marlowe
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Erik Jones