Postgres Performance Date Index

• Thread Index

• 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
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Sebastian Hennebrueder
• Re: PostgreSQL vs MySQL, and FreeBSD
  • From: Jonah H. Harris
• PostgreSQL vs MySQL, and FreeBSD
  • From: Ivan Voras
• Re: dell versus hp
  • From: Florian Weimer
• Re: [HACKERS] Estimation problem with a LIKE clause containing a /
  • From: Gregory Stark
• Re: [HACKERS] Estimation problem with a LIKE clause containing a /
  • From: Guillaume Smet
• Re: Help understanding stat numbers
  • From: Tom Lane
• Help understanding stat numbers
  • From: Chris Hoover
• Re: Hardware for PostgreSQL
  • From: Robert Treat
• Re: How to avoid hashjoin and mergejoin
  • From: Carlo Stonebanks
• Re: [HACKERS] Estimation problem with a LIKE clause containing a /
  • From: Tom Lane
• Re: Join performance
  • From: Tom Lane
• Re: Estimation problem with a LIKE clause containing a /
  • From: Tom Lane
• Re: Join performance
  • From: Tom Lane
• Re: Join performance
  • From: Tom Lane
• Re: Join performance
  • From: Tom Lane
• Re: Join performance
  • From: Tom Lane
• Re: dell versus hp
  • From: Scott Marlowe
• Re: Estimation problem with a LIKE clause containing a /
  • From: Gregory Stark
• Re: Join performance
  • From: Steinar H. Gunderson
• Join performance
  • From: Pepe Barbe
• Re: dell versus hp
  • From: Vivek Khera
• Re: dell versus hp
  • From: Alan Hodgson
• Re: dell versus hp
  • From: Kevin Grittner
• Re: dell versus hp
  • From: Dimitri Fontaine
• Re: dell versus hp
  • From: Scott Marlowe
• Re: Estimation problem with a LIKE clause containing a /
  • From: Tom Lane
• Re: dell versus hp
  • From: Vivek Khera
• Re: Need to run CLUSTER to keep performance
  • From: Chris Browne
• Re: hp ciss on freebsd
  • From: Vivek Khera
• Re: dell versus hp
  • From: Vivek Khera
• Re: Need to run CLUSTER to keep performance
  • From: Tom Lane
• Re: Estimation problem with a LIKE clause containing a /
  • From: Guillaume Smet
• Re: Need to run CLUSTER to keep performance
  • From: Rafael Martinez
• Re: Need to run CLUSTER to keep performance
  • From: Bill Moran
• Re: Need to run CLUSTER to keep performance
  • From: Heikki Linnakangas
• Re: Need to run CLUSTER to keep performance
  • From: Rafael Martinez
• Re: Estimation problem with a LIKE clause containing a /
  • From: Tom Lane
• Re: Need to run CLUSTER to keep performance
  • From: Alvaro Herrera
• Re: Need to run CLUSTER to keep performance
  • From: Rafael Martinez
• Re: Need to run CLUSTER to keep performance
  • From: Tomáš Vondra
• Re: Need to run CLUSTER to keep performance
  • From: Heikki Linnakangas
• Need to run CLUSTER to keep performance
  • From: Rafael Martinez
• Re: Estimation problem with a LIKE clause containing a /
  • From: Guillaume Smet
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Mark Kirkwood
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Gregory Stark
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Luke Lonergan
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Mark Kirkwood
• Re: Estimation problem with a LIKE clause containing a /
  • From: Guillaume Smet
• Re: Estimation problem with a LIKE clause containing a /
  • From: Guillaume Smet
• Re: Estimation problem with a LIKE clause containing a /
  • From: Tom Lane
• Re: Estimation problem with a LIKE clause containing a /
  • From: Tom Lane
• Re: Estimation problem with a LIKE clause containing a /
  • From: Guillaume Smet
• Re: Estimation problem with a LIKE clause containing a /
  • From: Tom Lane
• Re: index stat
  • From: Kevin Grittner
• Re: Estimation problem with a LIKE clause containing a /
  • From: Guillaume Smet
• Re: Estimation problem with a LIKE clause containing a /
  • From: Alexander Staubo
• Estimation problem with a LIKE clause containing a /
  • From: Guillaume Smet
• Subpar Execution Plan
  • From: Jens-Wolfhard Schicke
• Re: dell versus hp
  • From: Greg Smith
• Re: dell versus hp
  • From: Dimitri Fontaine
• Re: dell versus hp
  • From: Tore Halset
• Re: dell versus hp
  • From: Tore Halset
• Re: dell versus hp
  • From: Stephen Frost
• Re: dell versus hp
  • From: Dimitri Fontaine
• Re: dell versus hp
  • From: Claus Guttesen
• dell versus hp
  • From: Tore Halset
• Re: Is ANALYZE transactional?
  • From: Tom Lane
• Is ANALYZE transactional?
  • From: Craig James
• Re: Database connections and stored procs (functions)
  • From: Merlin Moncure
• Re: Which index methodology is better?-
  • From: Heikki Linnakangas
• Re: Which index methodology is better?-
  • From: Tom Lane
• Which index methodology is better?-
  • From: Chris Hoover
• Re: Migrating to 8.3 - checkpoints and background writer
  • From: Erik Jones
• Training Recommendations
  • From: Campbell, Lance
• index stat
  • From: Campbell, Lance
• Re: hp ciss on freebsd
  • From: Greg Smith
• Re: hp ciss on freebsd
  • From: Jeff Trout
• Database connections and stored procs (functions)
  • From: Radhika S
• hp ciss on freebsd
  • From: Claus Guttesen
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Gregory Stark
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Mark Kirkwood
• Re: Migrating to 8.3 - checkpoints and background writer
  • From: Greg Smith
• Re: Migrating to 8.3 - checkpoints and background writer
  • From: Steinar H. Gunderson
• Migrating to 8.3 - checkpoints and background writer
  • From: Greg Smith
• Re: Postgresql.conf Settings
  • From: Heikki Linnakangas
• Re: Postgresql.conf Settings
  • From: smiley2211
• Re: Postgresql.conf Settings
  • From: Scott Marlowe
• Re: Unfortunate expansion of composite types in union
  • From: Jens-Wolfhard Schicke
• Postgresql.conf Settings
  • From: smiley2211
• Re: Union within View vs.Union of Views
  • From: Jeff Larsen
• Re: Union within View vs.Union of Views
  • From: Jeff Larsen
• Re: "MixedCase sensitive quoted" names
  • From: Tom Lane
• Re: Union within View vs.Union of Views
  • From: Tom Lane
• "MixedCase sensitive quoted" names
  • From: Whatever Deep
• Re: Union within View vs.Union of Views
  • From: Heikki Linnakangas
• Re: Union within View vs.Union of Views
  • From: Mark Mielke
• Union within View vs.Union of Views
  • From: Jeff Larsen
• Re: [Fwd: Re: Outer joins and Seq scans]
  • From: Alvaro Herrera
• Re: Hardware for PostgreSQL (RAID configurations)
  • From: Mark F
• [no subject]
  • From: Mark F
• Re: Hardware for PostgreSQL
  • From: Jurgen Haan
• Re: select max(field) from table much faster with a group by clause?
  • From: Palle Girgensohn
• Re: Unfortunate expansion of composite types in union
  • From: Pavel Stehule
• Unfortunate expansion of composite types in union
  • From: Jens-Wolfhard Schicke
• Re: select max(field) from table much faster with a group by clause?
  • From: hubert depesz lubaczewski
• Re: How to avoid hashjoin and mergejoin
  • From: Carlo Stonebanks
• Re: hardware for PostgreSQL
  • From: Scott Marlowe
• hardware for PostgreSQL
  • From: Mark Floyd
• Re: Hardware for PostgreSQL
  • From: Ow Mun Heng
• Re: How to avoid hashjoin and mergejoin
  • From: Tom Lane
• Re: How to avoid hashjoin and mergejoin
  • From: Scott Marlowe
• How to avoid hashjoin and mergejoin
  • From: Carlo Stonebanks
• Re: Hardware for PostgreSQL
  • From: Steve Crawford
• Re: Hardware for PostgreSQL
  • From: Steve Crawford
• Re: select max(field) from table much faster with a group by clause?
  • From: Gregory Stark
• Re: select max(field) from table much faster with a group by clause?
  • From: Tom Lane
• Re: select max(field) from table much faster with a group by clause?
  • From: Scott Marlowe
• Re: select max(field) from table much faster with a group by clause?
  • From: Palle Girgensohn
• Re: select max(field) from table much faster with a group by clause?
  • From: Tom Lane
• Re: select max(field) from table much faster with a group by clause?
  • From: Palle Girgensohn
• Re: [Fwd: Re: Outer joins and Seq scans]
  • From: Sami Dalouche
• Re: select max(field) from table much faster with a group by clause?
  • From: Palle Girgensohn
• Re: select max(field) from table much faster with a group by clause?
  • From: Tom Lane
• Re: [Fwd: Re: Outer joins and Seq scans]
  • From: Tom Lane
• select max(field) from table much faster with a group by clause?
  • From: Palle Girgensohn
• Re: Hardware for PostgreSQL
  • From: Adam Tauno Williams
• Re: hardware and For PostgreSQL
  • From: Joe Uhl
• Re: Hardware for PostgreSQL
  • From: Magnus Hagander
• Re: Hardware for PostgreSQL
  • From: Ow Mun Heng
• Re: hardware and For PostgreSQL
  • From: Magnus Hagander
• Re: Hardware for PostgreSQL
  • From: Magnus Hagander
• Re: Hardware for PostgreSQL
  • From: Magnus Hagander
• Re: Hardware for PostgreSQL
  • From: Ow Mun Heng
• Re: Hardware for PostgreSQL
  • From: Ericson Smith
• Re: hardware and For PostgreSQL
  • From: Paul Lambert
• Re: [Fwd: Re: Outer joins and Seq scans]
  • From: Tom Lane
• Re: hardware and For PostgreSQL
  • From: Joshua D. Drake
• [Fwd: Re: Outer joins and Seq scans]
  • From: Sami Dalouche
• Re: hardware and For PostgreSQL
  • From: Ron St-Pierre
• Re: Hardware for PostgreSQL
  • From: Tomas Vondra
• Re: Hardware for PostgreSQL
  • From: Kevin Grittner
• Re: tables with 300+ partitions
  • From: Pablo Alcaraz
• Re: hardware and For PostgreSQL
  • From: Joe Uhl
• Re: Hardware for PostgreSQL
  • From: Arjen van der Meijden
• Re: Hardware for PostgreSQL
  • From: Magnus Hagander
• Re: tables with 300+ partitions
  • From: Scott Marlowe
• Re: hardware and For PostgreSQL
  • From: Ben
• Hardware for PostgreSQL
  • From: Ketema
• Re: tables with 300+ partitions
  • From: Tomáš Vondra
• Re: tables with 300+ partitions
  • From: Steven Flatt
• Re: hardware and For PostgreSQL
  • From: Scott Marlowe
• hardware and For PostgreSQL
  • From: Ketema Harris
• Re: tables with 300+ partitions
  • From: Pablo Alcaraz
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Luke Lonergan
• Re: Two fast queries get slow when combined
  • From: cluster
• Re: Two fast queries get slow when combined
  • From: cluster
• Re: Optimizing PostgreSQL for Windows
  • From: Christian Rengstl
• Re: Two fast queries get slow when combined
  • From: Tom Lane
• Re: Two fast queries get slow when combined
  • From: Heikki Linnakangas
• Two fast queries get slow when combined
  • From: cluster
• Re: tables with 300+ partitions
  • From: Steven Flatt
• Re: tables with 300+ partitions
  • From: Heikki Linnakangas
• Re: Optimizing PostgreSQL for Windows
  • From: Guillaume Lelarge
• tables with 300+ partitions
  • From: Pablo Alcaraz
• Re: Improving Query
  • From: Ketema Harris
• Re: Optimizing PostgreSQL for Windows
  • From: Dave Dutcher
• Re: Improving Query
  • From: Tom Lane
• Re: Optimizing PostgreSQL for Windows
  • From: Marc Schablewski
• Re: Improving Query
  • From: Ketema Harris
• Re: Improving Query
  • From: Ketema Harris
• Re: Improving Query
  • From: Michael Glaesemann
• Optimizing PostgreSQL for Windows
  • From: Christian Rengstl
• Re: Improving Query
  • From: Richard Huxton
• Improving Query
  • From: Ketema
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Gregory Stark
• High Availability and Load Balancing
  • From: ruben
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Tom Lane
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Mark Kirkwood
• Re: Suggestions on an update query
  • From: Scott Marlowe
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Luke Lonergan
• Re: Suggestions on an update query
  • From: Campbell, Lance
• Re: Append Cost in query planners
  • From: Heikki Linnakangas
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Gregory Stark
• Re: Append Cost in query planners
  • From: Nimesh Satam
• Re: Outer joins and Seq scans
  • From: Cédric Villemain
• Re: Append Cost in query planners
  • From: Heikki Linnakangas
• Re: Outer joins and Seq scans
  • From: Richard Huxton
• Re: Append Cost in query planners
  • From: Nimesh Satam
• Re: Outer joins and Seq scans
  • From: Dimitri Fontaine
• Re: Outer joins and Seq scans
  • From: Tom Lane
• Re: Outer joins and Seq scans
  • From: Sami Dalouche
• Re: Outer joins and Seq scans
  • From: Tom Lane
• Outer joins and Seq scans
  • From: Sami Dalouche
• Re: Append Cost in query planners
  • From: Heikki Linnakangas
• Re: partitioned table and ORDER BY indexed_field DESCLIMIT 1
  • From: Simon Riggs
• Re: partitioned table and ORDER BY indexed_field DESCLIMIT 1
  • From: Tom Lane
• Re: Append Cost in query planners
  • From: Heikki Linnakangas
• Append Cost in query planners
  • From: Nimesh Satam
• Re: partitioned table and ORDER BY indexed_field DESCLIMIT 1
  • From: Simon Riggs
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Gregory Stark
• Re: Speed difference between select ... union select ... and select from partitioned_table
  • From: Pablo Alcaraz
• Re: partitioned table and ORDER BY indexed_field DESCLIMIT 1
  • From: Luke Lonergan
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Simon Riggs
• Re: Speed difference between select ... union select ... and select from partitioned_table
  • From: Simon Riggs
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Luke Lonergan
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Luke Lonergan
• Re: Speed difference between select ... union select ... and select from partitioned_table
  • From: Tom Lane
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Heikki Linnakangas
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Anton
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Tom Lane
• Re: Speed difference between select ... union select ... and select from partitioned_table
  • From: Pablo Alcaraz
• Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
  • From: Anton
• Re: Suggestions on an update query
  • From: Joshua D. Drake
• Re: Suggestions on an update query
  • From: Gregory Stark
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Jignesh K. Shah
• Re: Suggestions on an update query
  • From: Joshua D. Drake
• Re: Speed difference between select ... union select ... and select from partitioned_table
  • From: Gregory Stark
• Re: Speed difference between select ... union select ... and select from partitioned_table
  • From: Pablo Alcaraz
• Re: Suggestions on an update query
  • From: Gregory Stark
• Re: Speed difference between select ... union select ... and select from partitioned_table
  • From: Jeff Davis
• Speed difference between select ... union select ... and select from partitioned_table
  • From: Pablo Alcaraz
• Re: Suggestions on an update query
  • From: Campbell, Lance
• Suggestions on an update query
  • From: Campbell, Lance
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Tom Lane
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Jignesh K. Shah
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Jignesh K. Shah
• Re: Bunching "transactions"
  • From: Greg Smith
• Re: Bunching "transactions"
  • From: Jean-David Beyer
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Jignesh K. Shah
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Jignesh K. Shah
• Re: 8.3beta1 testing on Solaris
  • From: Jignesh K. Shah
• Re: Bunching "transactions"
  • From: Jean-David Beyer
• Re: Finalizing commit taking very long
  • From: Giulio Cesare Solaroli
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Gregory Stark
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Tom Lane
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Josh Berkus
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Tom Lane
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Gregory Stark
• Re: 8.3beta1 testing on Solaris
  • From: Gregory Stark
• Re: Bunching "transactions"
  • From: Chris Browne
• Re: [HACKERS] 8.3beta1 testing on Solaris
  • From: Tom Lane
• PostgreSQL 8.3beta1 on Solaris testing case study
  • From: Jignesh K. Shah
• 8.3beta1 testing on Solaris
  • From: Jignesh K. Shah
• Re: Bunching "transactions"
  • From: Jean-David Beyer
• Re: Bunching "transactions"
  • From: Chris Browne
• Re: Bunching "transactions"
  • From: Tom Lane
• Re: Bunching "transactions"
  • From: Heikki Linnakangas
• Bunching "transactions"
  • From: Jean-David Beyer
• Re: Bunching "transactions"
  • From: Erik Jones
• Re: multiple apaches against single postgres database
  • From: Tatsuo Ishii
• Re: Finalizing commit taking very long
  • From: Giulio Cesare Solaroli
• Re: multiple apaches against single postgres database
  • From: Kevin Grittner
• Re: multiple apaches against single postgres database
  • From: Sven Geisler
• Re: Finalizing commit taking very long
  • From: Tom Lane
• Re: Finalizing commit taking very long
  • From: Giulio Cesare Solaroli
• Re: multiple apaches against single postgres database
  • From: Gregory Stark
• Re: 12 hour table vacuums
  • From: Jean-David Beyer
• Re: multiple apaches against single postgres database
  • From: Michal Taborsky - Internet Mall
• Re: Finalizing commit taking very long
  • From: Tom Lane
• multiple apaches against single postgres database
  • From: Honza Novak
• Finalizing commit taking very long
  • From: Giulio Cesare Solaroli
• Re: 12 hour table vacuums
  • From: Harald Fuchs
• Re: 12 hour table vacuums
  • From: Alvaro Herrera
• Re: 12 hour table vacuums
  • From: Alvaro Herrera
• Re: 12 hour table vacuums
  • From: Simon Riggs
• Re: 12 hour table vacuums
  • From: Joshua D. Drake
• Re: 12 hour table vacuums
  • From: Ron St-Pierre
• Re: 12 hour table vacuums
  • From: Ron St-Pierre
• Re: 12 hour table vacuums
  • From: Ron St-Pierre
• Re: 12 hour table vacuums
  • From: Bill Moran
• Re: 12 hour table vacuums
  • From: Gregory Stark
• Re: 12 hour table vacuums
  • From: Ron St-Pierre
• Re: 12 hour table vacuums
  • From: Csaba Nagy
• Re: 12 hour table vacuums
  • From: Alvaro Herrera
• Re: 12 hour table vacuums
  • From: Tom Lane
• Re: 12 hour table vacuums
  • From: Bill Moran
• 12 hour table vacuums
  • From: Ron St-Pierre
• Re: Seqscan
  • From: Nis Jørgensen
• Re: Seqscan
  • From: Adrian Demaestri
• Re: How to improve speed of 3 table join &group (HUGE tables)
  • From: Nis Jørgensen
• Re: need help with a query
  • From: Pavel Velikhov
• Re: Seqscan
  • From: Jeff Davis
• Seqscan
  • From: Adrian Demaestri
• Re: Memory Settings....
  • From: Kevin Grittner
• Re: Memory Settings....
  • From: Heikki Linnakangas
• Re: Memory Settings....
  • From: Ben