Postgres Performance Date Index

• Thread Index

• pgmemcache
  • From: C Storm
• Re: bad performance on Solaris 10
  • From: Josh Berkus
• Re: bad performance on Solaris 10
  • From: Mark Kirkwood
• Re: bad performance on Solaris 10
  • From: Luke Lonergan
• Re: freebsd/softupdates for data dir
  • From: Mark Kirkwood
• freebsd/softupdates for data dir
  • From: Miguel
• Re: bad performance on Solaris 10
  • From: Josh Berkus
• bad performance on Solaris 10
  • From: Chris Mair
• Re: The order of fields around the "=" in the WHERE conditions
  • From: Tom Lane
• Re: The order of fields around the "=" in the WHERE conditions
  • From: Tom Lane
• The order of fields around the "=" in the WHERE conditions
  • From: Mike Quinn
• Re: optimizing db for small table with tons of updates
  • From: Kenji Morishige
• Re: optimizing db for small table with tons of updates
  • From: Tom Lane
• Re: optimizing db for small table with tons of updates
  • From: Kenji Morishige
• Re: optimizing db for small table with tons of updates
  • From: Alvaro Herrera
• Re: optimizing db for small table with tons of updates
  • From: Kenji Morishige
• Re: optimizing db for small table with tons of updates
  • From: Tom Lane
• Re: optimizing db for small table with tons of updates
  • From: Rajesh Kumar Mallah
• Re: optimizing db for small table with tons of updates
  • From: Josh Berkus
• optimizing db for small table with tons of updates
  • From: Kenji Morishige
• Re: Measuring the execution time of functions within functions...
  • From: Jerry Sievers
• Re: Measuring the execution time of functions within functions...
  • From: Alvaro Herrera
• Measuring the execution time of functions within functions...
  • From: Mario Splivalo
• Re: Trigger vs Rule
  • From: Ключников А.С.
• Re: Trigger vs Rule
  • From: Niklas Johansson
• Re: Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Re: Query using SeqScan instead of IndexScan
  • From: Josh Berkus
• Re: Trigger vs Rule
  • From: Niklas Johansson
• Re: index not used again
  • From: Stephan Szabo
• Re: index not used again
  • From: Jan Kesten
• Re: Logging SQL queries to optimize them ?
  • From: Qingqing Zhou
• Re: Large Binary Objects Middleware
  • From: Qingqing Zhou
• Re: statistics buffer is full
  • From: Qingqing Zhou
• Trigger vs Rule
  • From: Ключников А.С.
• Re: Query using SeqScan instead of IndexScan
  • From: Tom Lane
• Re: Query using SeqScan instead of IndexScan
  • From: Mark Kirkwood
• Re: Query using SeqScan instead of IndexScan
  • From: Alvaro Herrera
• Re: Query using SeqScan instead of IndexScan
  • From: chris smith
• Re: Query using SeqScan instead of IndexScan
  • From: chris smith
• Re: [Solved] Slow performance on Windows .NET and OleDb
  • From: Merlin Moncure
• Re: Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Re: Query using SeqScan instead of IndexScan
  • From: Jim C. Nasby
• Re: [Solved] Slow performance on Windows .NET and OleDb
  • From: Antoine
• Re: Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Re: Query using SeqScan instead of IndexScan
  • From: chris smith
• Re: Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Re: [Solved] Slow performance on Windows .NET and OleDb
  • From: Magnus Hagander
• Re: [Solved] Slow performance on Windows .NET and OleDb
  • From: Antoine
• Re: un-'vacuum analyse'
  • From: Tom Lane
• un-'vacuum analyse'
  • From: Frederic Back
• Re: Query using SeqScan instead of IndexScan
  • From: Jim C. Nasby
• Re: Indexes with descending date columns
  • From: Jim C. Nasby
• Re: simple join uses indexes, very slow
  • From: Jim C. Nasby
• Re: index not used again
  • From: Stephan Szabo
• index not used again
  • From: Jan Kesten
• Re: Decide between Postgresql and Mysql (help of
  • From: Guido Neitzer
• Re: Decide between Postgresql and Mysql (help of
  • From: Philippe Marzin
• Re: Decide between Postgresql and Mysql (help of
  • From: Chris Browne
• Re: Decide between Postgresql and Mysql (help of
  • From: Steinar H. Gunderson
• Re: Decide between Postgresql and Mysql (help of
  • From: PFC
• Re: CREATE INDEX rather sluggish
  • From: Gavin Hamill
• Re: CREATE INDEX rather sluggish
  • From: Gavin Hamill
• Re: Decide between Postgresql and Mysql (help of
  • From: Scott Marlowe
• Re: Decide between Postgresql and Mysql (help of
  • From: Chris Browne
• Re: Index scan startup time
  • From: Simon Riggs
• Re: CREATE INDEX rather sluggish
  • From: Simon Riggs
• Re: Index scan startup time
  • From: Tom Lane
• Re: CREATE INDEX rather sluggish
  • From: Tom Lane
• Re: Index scan startup time
  • From: Peter Eisentraut
• Re: [Solved] Slow performance on Windows .NET and OleDb
  • From: Dave Dutcher
• Re: Index scan startup time
  • From: Tom Lane
• Automatic tuning of postgresql.conf parameters?
  • From: Mattias Kregert
• Re: Index scan startup time
  • From: Michael Stone
• Re: Index scan startup time
  • From: Steinar H. Gunderson
• Re: Index scan startup time
  • From: Peter Eisentraut
• Re: Index scan startup time
  • From: Steinar H. Gunderson
• Re: Index scan startup time
  • From: Michael Stone
• Re: Index scan startup time
  • From: Markus Schaber
• Re: Index scan startup time
  • From: Steinar H. Gunderson
• Re: Index scan startup time
  • From: Peter Eisentraut
• Re: Index scan startup time
  • From: Peter Eisentraut
• Re: Index scan startup time
  • From: Michael Stone
• Re: Index scan startup time
  • From: Steinar H. Gunderson
• Index scan startup time
  • From: Peter Eisentraut
• Re: Decide between Postgresql and Mysql (help of
  • From: Markus Schaber
• CREATE INDEX rather sluggish
  • From: Gavin Hamill
• [Solved] Slow performance on Windows .NET and OleDb
  • From: Greg Quinn
• Re: Query using SeqScan instead of IndexScan
  • From: Josh Berkus
• Re: Database possible corruption , unsolvable mystery
  • From: Josh Berkus
• Re: Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Query using SeqScan instead of IndexScan
  • From: Brendan Duddridge
• Re: Decide between Postgresql and Mysql (help of
  • From: Gorshkov
• Re: Decide between Postgresql and Mysql (help of
  • From: Craig A. James
• Re: Decide between Postgresql and Mysql (help of
  • From: Gorshkov
• Re: Decide between Postgresql and Mysql (help of
  • From: Craig A. James
• Re: Slow performance on Windows .NET and OleDb
  • From: Christopher Kings-Lynne
• Re: Decide between Postgresql and Mysql (help of
  • From: Gorshkov
• Re: Database possible corruption , unsolvable mystery
  • From: Eric Lauzon
• Re: Database possible corruption , unsolvable mystery
  • From: stef
• Re: Database possible corruption , unsolvable mystery
  • From: Eric Lauzon
• Re: Database possible corruption , unsolvable mystery
  • From: Mark Lewis
• Re: Database possible corruption , unsolvable mystery
  • From: Richard Huxton
• Database possible corruption , unsolvable mystery
  • From: Eric Lauzon
• Re: Decide between Postgresql and Mysql (help of
  • From: Vivek Khera
• Re: Decide between Postgresql and Mysql (help of
  • From: Vivek Khera
• Re: Decide between Postgresql and Mysql (help of comunity)
  • From: Vivek Khera
• Re: simple join uses indexes, very slow
  • From: george young
• Re: Slow performance on Windows .NET and OleDb
  • From: Merlin Moncure
• Re: Decide between Postgresql and Mysql (help of
  • From: Merlin Moncure
• statistics buffer is full
  • From: Gábriel Ákos
• Re: Slow performance on Windows .NET and OleDb
  • From: PFC
• Re: Slow performance on Windows .NET and OleDb
  • From: Markus Schaber
• Re: Slow performance on Windows .NET and OleDb
  • From: Greg Quinn
• Re: Indexes with descending date columns
  • From: Theo Kramer
• Re: Slow performance on Windows .NET and OleDb
  • From: Chris
• Re: Slow performance on Windows .NET and OleDb
  • From: Ruben Rubio Rey
• Re: Slow performance on Windows .NET and OleDb
  • From: Greg Quinn
• Re: Slow performance on Windows .NET and OleDb
  • From: Greg Quinn
• Re: simple join uses indexes, very slow
  • From: stef
• Re: simple join uses indexes, very slow
  • From: Chris
• Re: MVCC intro and benefits docs?
  • From: Qingqing Zhou
• Re: simple join uses indexes, very slow
  • From: Dave Dutcher
• Re: MVCC intro and benefits docs?
  • From: Jim C. Nasby
• Re: Decide between Postgresql and Mysql (help of
  • From: Jim C. Nasby
• Re: Decide between Postgresql and Mysql (help of
  • From: Jim C. Nasby
• Re: Decide between Postgresql and Mysql (help of
  • From: PFC
• Re: Decide between Postgresql and Mysql (help of
  • From: PFC
• Re: simple join uses indexes, very slow
  • From: george young
• Re: Decide between Postgresql and Mysql (help of
  • From: Chris Travers
• Re: Decide between Postgresql and Mysql (help of
  • From: Scott Marlowe
• Re: Decide between Postgresql and Mysql (help of
  • From: PFC
• Re: Decide between Postgresql and Mysql (help of
  • From: Marcos
• MVCC intro and benefits docs?
  • From: Antoine
• Re: Decide between Postgresql and Mysql (help of
  • From: Scott Marlowe
• Re: Decide between Postgresql and Mysql (help of comunity)
  • From: Madison Kelly
• Decide between Postgresql and Mysql (help of comunity)
  • From: Marcos
• Re: simple join uses indexes, very slow
  • From: Simon Riggs
• Re: Slow performance on Windows .NET and OleDb
  • From: Joshua D. Drake
• Re: Massive Inserts Strategies
  • From: Jim C. Nasby
• Re: simple join uses indexes, very slow
  • From: Steinar H. Gunderson
• Re: Slow performance on Windows .NET and OleDb
  • From: Jim C. Nasby
• Re: simple join uses indexes, very slow
  • From: Jim C. Nasby
• Re: count(*) performance
  • From: Jim C. Nasby
• Re: simple join uses indexes, very slow
  • From: Dave Dutcher
• Re: simple join uses indexes, very slow
  • From: Steinar H. Gunderson
• Re: Massive Inserts Strategies
  • From: Markus Schaber
• Re: simple join uses indexes, very slow
  • From: Dave Dutcher
• Re: Massive Inserts Strategies
  • From: ashah
• Re: simple join uses indexes, very slow
  • From: Markus Schaber
• Re: simple join uses indexes, very slow
  • From: george young
• Re: Slow performance on Windows .NET and OleDb
  • From: Merlin Moncure
• Slow performance on Windows .NET and OleDb
  • From: Greg Quinn
• Re: count(*) performance
  • From: Markus Schaber
• Re: simple join uses indexes, very slow
  • From: Simon Riggs
• Re: count(*) performance
  • From: Mikael Carneholm
• Re: count(*) performance
  • From: Tom Lane
• Re: count(*) performance
  • From: Matthew T. O'Connor
• Re: count(*) performance
  • From: Mikael Carneholm
• Large Binary Objects Middleware
  • From: Rodrigo Madera
• Re: count(*) performance
  • From: Guido Neitzer
• Re: count(*) performance
  • From: Alvaro Herrera
• Re: count(*) performance
  • From: Matthew T. O'Connor
• Re: count(*) performance
  • From: Brendan Duddridge
• simple join uses indexes, very slow
  • From: george young
• Re: count(*) performance
  • From: Gábriel Ákos
• Re: count(*) performance
  • From: Luke Lonergan
• Re: count(*) performance
  • From: Gábriel Ákos
• Re: count(*) performance
  • From: Gábriel Ákos
• Re: count(*) performance
  • From: Luke Lonergan
• Re: Query parallelism
  • From: Jim C. Nasby
• Query parallelism
  • From: luchot
• Re: count(*) performance
  • From: Jim C. Nasby
• count(*) performance
  • From: Gábriel Ákos
• Re: [GENERAL] experiences needed - how does Itanium2/1.5GHz(4MB) compare to AMD and Intel CPUs as far as Postgresql is concerned
  • From: Jim C. Nasby
• Re: Array performance
  • From: Ruben Rubio Rey
• Re: Query plan from hell
  • From: Guido Neitzer
• Re: limitation using LIKE on ANY(array)
  • From: K C Lau
• Query plan from hell
  • From: PFC
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Chris Browne
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Jim C. Nasby
• Re: Performance problems with multiple layers of functions
  • From: Tom Lane
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Michael Stone
• Re: Performance problems with multiple layers of functions
  • From: Svenne Krap
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Chris Browne
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Chris Browne
• Re: WAL logging of SELECT ... INTO command
  • From: Kris Jurka
• Re: Postmaster using only 4-5% CPU
  • From: Scott Marlowe
• Re: limitation using LIKE on ANY(array)
  • From: Tom Lane
• Re: Performance problems with multiple layers of functions
  • From: Tom Lane
• Re: Array performance
  • From: Tom Lane
• limitation using LIKE on ANY(array)
  • From: K C Lau
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Luke Lonergan
• Re: Problem with query, server totally unresponsive
  • From: Jim C. Nasby
• Re: Problem with query, server totally unresponsive
  • From: Dave Dutcher
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: WAL logging of SELECT ... INTO command
  • From: Alvaro Herrera
• Re: Array performance
  • From: Michael Fuhr
• Re: Array performance
  • From: Jim C. Nasby
• Re: Array performance
  • From: Ruben Rubio Rey
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: Performance problems with multiple layers of functions
  • From: Jim C. Nasby
• Re: Array performance
  • From: Jim C. Nasby
• Performance problems with multiple layers of functions
  • From: Svenne Krap
• Array performance
  • From: Ruben Rubio Rey
• Re: WAL logging of SELECT ... INTO command
  • From: Alvaro Herrera
• Re: Problem with query, server totally unresponsive
  • From: Jim C. Nasby
• Re: Indexes with descending date columns
  • From: Jim C. Nasby
• Re: Postmaster using only 4-5% CPU
  • From: Jim C. Nasby
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Jim C. Nasby
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: Indexes with descending date columns
  • From: Tom Lane
• Re: Indexes with descending date columns
  • From: Theo Kramer
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Christopher Browne
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Scott Marlowe
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Joshua D. Drake
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Scott Marlowe
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core
  • From: Frank Wiles
• Problem with query, forget previous message
  • From: Bendik Rognlien Johansen
• Re: Scaling up PostgreSQL in Multiple CPU / Dual Core Powered Servers
  • From: Christopher Browne
• Re: Indexes with descending date columns
  • From: Alvaro Herrera
• Problem with query, server totally unresponsive
  • From: Bendik Rognlien Johansen
• Re: Indexes with descending date columns
  • From: Theo Kramer
• Re: Postmaster using only 4-5% CPU
  • From: Edoardo Serra
• Scaling up PostgreSQL in Multiple CPU / Dual Core Powered Servers
  • From: Jojo Paderes
• Re: WAL logging of SELECT ... INTO command
  • From: Qingqing Zhou
• Re: WAL logging of SELECT ... INTO command
  • From: Kris Jurka
• Re: Intel C/C++ Compiler Tests
  • From: Luke Lonergan
• Re: planner with index scan cost way off actual cost,
  • From: Guillaume Cottenceau
• Re: WAL logging of SELECT ... INTO command
  • From: Csaba Nagy
• Re: planner with index scan cost way off actual cost,
  • From: Scott Marlowe
• Re: Massive Inserts Strategies
  • From: Jim C. Nasby
• Re: Massive Inserts Strategies
  • From: PFC
• Massive Inserts Strategies
  • From: ashah
• Re: WAL logging of SELECT ... INTO command
  • From: Tom Lane
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: WAL logging of SELECT ... INTO command
  • From: Tom Lane
• Re: Migration study, step 1: bulk write performanceoptimization
  • From: Tom Lane
• Intel C/C++ Compiler Tests
  • From: Spiegelberg, Greg
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performanceoptimization
  • From: Mikael Carneholm
• Re: WAL logging of SELECT ... INTO command
  • From: Simon Riggs
• Re: Migration study, step 1: bulk write performanceoptimization
  • From: Jim C. Nasby
• Re: WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: Poor performance o
  • From: Jim C. Nasby
• Re: Sequence Scan vs. Index scan
  • From: Alejandro D. Burne
• Re: Sequence Scan vs. Index scan
  • From: Steinar H. Gunderson
• Re: Sequence Scan vs. Index scan
  • From: Alejandro D. Burne
• Re: Migration study, step 1: bulk write
  • From: Simon Riggs
• Re: Query Feromance
  • From: Marco Furetto
• Re: Migration study, step 1: bulk write performanceoptimization
  • From: Mikael Carneholm
• Re: planner with index scan cost way off actual cost,
  • From: Guillaume Cottenceau
• Re: Poor performance o
  • From: Tom Lane
• motherboard recommendations
  • From: Jeff Frost
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Vivek Khera
• Re: Poor performance o
  • From: Craig A. James
• Re: Poor performance o
  • From: Tom Lane
• Poor performance o
  • From: Craig A. James
• Re: Migration study, step 1: bulk write performance
  • From: Scott Marlowe
• Re: Migration study, step 1: bulk write performance
  • From: Tom Lane
• Re: Migration study, step 1: bulk write performance
  • From: Alvaro Herrera
• Re: Migration study, step 1: bulk write performance
  • From: Scott Marlowe
• Re: Migration study, step 1: bulk write performance
  • From: Ron
• Re: planner with index scan cost way off actual cost,
  • From: Simon Riggs
• Re: Migration study, step 1: bulk write performance
  • From: Simon Riggs
• Re: WAL logging of SELECT ... INTO command
  • From: Simon Riggs
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Vivek Khera
• Re: qsort again (was Re: Strange Create Index behaviour)
  • From: Tom Lane
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jeff Frost
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Mark Kirkwood
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: PFC
• Re: Sequence Scan vs. Index scan
  • From: Reimer
• Re: Sequence Scan vs. Index scan
  • From: Mikael Carneholm
• Re: Sequence Scan vs. Index scan
  • From: Steinar H. Gunderson
• Sequence Scan vs. Index scan
  • From: Fernando Lujan
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jim C. Nasby
• Re: planner with index scan cost way off actual cost,
  • From: Jim C. Nasby
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Jim C. Nasby
• Re: Postmaster using only 4-5% CPU
  • From: Scott Marlowe
• Re: update == delete + insert?
  • From: Jim C. Nasby
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Adam Witney
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Vivek Khera
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Vivek Khera
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Luke Lonergan
• Re: Postmaster using only 4-5% CPU
  • From: Guillaume Cottenceau
• Re: update == delete + insert?
  • From: Merlin Moncure
• Re: Postmaster using only 4-5% CPU
  • From: Markus Bertheau
• Re: Perfomance test figures
  • From: Merlin Moncure
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Cottenceau
• Re: planner with index scan cost way off actual cost,
  • From: Guillaume Cottenceau
• Postmaster using only 4-5% CPU
  • From: Edoardo Serra
• Re: Migration study, step 1: bulk write performance
  • From: Michael Stone
• Re: Migration study, step 1: bulk write performance
  • From: Jim C. Nasby
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Steinar H. Gunderson
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Alex Hayward
• WAL logging of SELECT ... INTO command
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Steinar H. Gunderson
• Re: Migration study, step 1: bulk write performance
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Csaba Nagy
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Steinar H. Gunderson
• Re: Migration study, step 1: bulk write performance
  • From: Csaba Nagy
• Re: planner with index scan cost way off actual cost,
  • From: Jim C. Nasby
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jim C. Nasby
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Jim C. Nasby
• Re: Perfomance test figures
  • From: Jim C. Nasby
• Re: Auto performance tuning?
  • From: Jim C. Nasby
• Re: Migration study, step 1: bulk write performance
  • From: Jim C. Nasby
• Re: update == delete + insert?
  • From: Jim C. Nasby
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Mark Kirkwood
• Re: Query Feromance
  • From: Thomas Pundt
• Re: planner with index scan cost way off actual cost,
  • From: Mark Kirkwood
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Jim C. Nasby
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jim C. Nasby
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Cottenceau
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jim C. Nasby
• Re: data doesnt get saved in the database / idle in transaction
  • From: Jim C. Nasby
• Re: partial indexes and inference
  • From: Jim C. Nasby
• Re: partitioning
  • From: Jim C. Nasby
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Jim C. Nasby
• Re: Query Feromance
  • From: Marco Furetto
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Jim C. Nasby
• Re: Query Feromance
  • From: Thomas Pundt
• Re: Query Feromance
  • From: Marco Furetto
• Perfomance test figures
  • From: Amit Soni
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Mark Kirkwood
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Mark Kirkwood
• Re: update == delete + insert?
  • From: Jaime Casanova
• Re: Migration study, step 1: bulk write performance optimization
  • From: Tom Lane
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: PFC
• Re: update == delete + insert?
  • From: Tom Lane
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Miguel
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Vivek Khera
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Miguel
• Re: update == delete + insert?
  • From: Jim Buttafuoco
• update == delete + insert?
  • From: Craig A. James
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Vivek Khera
• Re: 1 TB of memory
  • From: Vivek Khera
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Miguel
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Luke Lonergan
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Miguel
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Luke Lonergan
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Miguel
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Luke Lonergan
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec
  • From: Miguel
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Alex Hayward
• Re: 1 TB of memory
  • From: Merlin Moncure
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Vivek Khera
• Auto performance tuning?
  • From: Orion Henry
• Re: 1 TB of memory
  • From: Vivek Khera
• Re: 1 TB of memory
  • From: Vivek Khera
• Re: Migration study, step 1: bulk write performance optimization
  • From: Dave Cramer
• Re: Query Feromance
  • From: Reimer
• Re: Migration study, step 1: bulk write performance optimization
  • From: PFC
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Scott Marlowe
• Re: Migration study, step 1: bulk write performance
  • From: Csaba Nagy
• Re: Migration study, step 1: bulk write performance optimization
  • From: Craig A. James
• Query Feromance
  • From: Marco Furetto
• Migration study, step 1: bulk write performance optimization
  • From: Mikael Carneholm
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Jim C. Nasby
• Re: data doesnt get saved in the database / idle in transaction
  • From: Qingqing Zhou
• data doesnt get saved in the database / idle in transaction
  • From: Ksenia Marasanova
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Cottenceau
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Cottenceau
• partial indexes and inference
  • From: Tim Allen
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Dave Page
• Re: database model tshirt sizes
  • From: NbForYou
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Luke Lonergan
• Re: n00b autovacuum question
  • From: Antoine
• Re: n00b autovacuum question
  • From: Andreas Pflug
• Re: database model tshirt sizes
  • From: me
• Re: database model tshirt sizes
  • From: Patrick Hatcher
• partitioning
  • From: Antoine
• Re: n00b autovacuum question
  • From: Antoine
• Re: Help optimizing a slow index scan
  • From: Oleg Bartunov
• Re: planner with index scan cost way off actual cost,
  • From: Mark Kirkwood
• Re: n00b autovacuum question
  • From: Andreas Pflug
• Re: n00b autovacuum question
  • From: Matthew T. O'Connor
• database model tshirt sizes
  • From: NbForYou
• Re: Help optimizing a slow index scan
  • From: Bruno Wolff III
• n00b autovacuum question
  • From: Antoine
• Re: planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Smet
• Re: Help optimizing a slow index scan
  • From: Oleg Bartunov
• Re: Help optimizing a slow index scan
  • From: Michael Fuhr
• Re: Help optimizing a slow index scan
  • From: Tom Lane
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Kenji Morishige
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Mark Kirkwood
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Claus Guttesen
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Scott Marlowe
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Tom Lane
• Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Claus Guttesen
• Re: Best OS & Configuration for Dual Xeon w/4GB &
  • From: Scott Marlowe
• Best OS & Configuration for Dual Xeon w/4GB & Adaptec RAID 2200S
  • From: Kenji Morishige
• Re: 1 TB of memory
  • From: Scott Marlowe
• Re: Help optimizing a slow index scan
  • From: Merlin Moncure
• Re: 1 TB of memory
  • From: Merlin Moncure
• Re: Help optimizing a slow index scan
  • From: Dan Harris
• Re: 1 TB of memory
  • From: Luke Lonergan
• Re: Help optimizing a slow index scan
  • From: Evgeny Gridasov
• Re: Background writer configuration
  • From: Evgeny Gridasov
• Re: Help optimizing a slow index scan
  • From: Merlin Moncure
• Re: Background writer configuration
  • From: 11
• Re: Help optimizing a slow index scan
  • From: Bruno Wolff III
• Re: 1 TB of memory
  • From: Jim C. Nasby
• Re: Background writer configuration
  • From: Steinar H. Gunderson
• Re: Background writer configuration
  • From: Steve Atkins
• Re: Help optimizing a slow index scan
  • From: Merlin Moncure
• Re: Help optimizing a slow index scan
  • From: Dan Harris
• Re: Help optimizing a slow index scan
  • From: Dan Harris
• Re: Background writer configuration
  • From: Kevin Grittner
• Re: 1 TB of memory
  • From: Merlin Moncure
• Re: Background writer configuration
  • From: PFC
• Re: Background writer configuration
  • From: Evgeny Gridasov
• Re: 1 TB of memory
  • From: Merlin Moncure
• Re: 1 TB of memory
  • From: Alex Stapleton
• Re: 1 TB of memory
  • From: Rodrigo Madera
• Re: Background writer configuration
  • From: PFC
• Re: 1 TB of memory
  • From: Michael Stone
• Re: 1 TB of memory
  • From: Luke Lonergan
• Re: Background writer configuration
  • From: Evgeny Gridasov
• planner with index scan cost way off actual cost, advices to tweak cost constants?
  • From: Guillaume Cottenceau
• Re: Indexes with descending date columns
  • From: andrew
• Re: 1 TB of memory
  • From: Josh Berkus
• Re: 1 TB of memory
  • From: Luke Lonergan
• Re: 1 TB of memory
  • From: Luke Lonergan
• Re: Background writer configuration
  • From: Kevin Grittner
• Re: Help optimizing a slow index scan
  • From: Dan Harris
• Help optimizing a slow index scan
  • From: Dan Harris
• Re: 1 TB of memory
  • From: Matthew Nuzum
• Re: 1 TB of memory
  • From: Ron Peacetree
• Indexes with descending date columns
  • From: Theo Kramer
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: BETWEEN optimizer problems with single-value
  • From: Tom Lane
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: BETWEEN optimizer problems with single-value
  • From: Alvaro Herrera
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: 1 TB of memory
  • From: Joshua D. Drake
• 1 TB of memory
  • From: Jim Nasby
• Re: Background writer configuration
  • From: Evgeny Gridasov
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: PostgreSQL and Xeon MP
  • From: Sven Geisler
• Re: PostgreSQL and Xeon MP
  • From: Tom Lane
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: BETWEEN optimizer problems with single-value
  • From: Tom Lane
• Re: PostgreSQL and Xeon MP
  • From: Sven Geisler
• Re: PostgreSQL and Xeon MP
  • From: Tom Lane
• Re: PostgreSQL and Xeon MP
  • From: Kenneth Marshall
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: PostgreSQL and Xeon MP
  • From: Richard Huxton
• Re: PostgreSQL and Xeon MP
  • From: Sven Geisler
• Re: PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: PostgreSQL and Xeon MP
  • From: Richard Huxton
• PostgreSQL and Xeon MP
  • From: Guillaume Smet
• Re: BETWEEN optimizer problems with single-value
  • From: Tom Lane
• Re: Slow SELECTS after large update cycle
  • From: Jan de Visser
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: BETWEEN optimizer problems with single-value
  • From: Simon Riggs
• Re: [HACKERS] BETWEEN optimizer problems with single-value
  • From: Kevin Grittner
• Re: Slow SELECTS after large update cycle
  • From: Simon Riggs
• Re: Slow SELECTS after large update cycle
  • From: Chris
• Re: [HACKERS] BETWEEN optimizer problems with single-value range
  • From: Simon Riggs
• Re: BETWEEN optimizer problems with single-value range
  • From: Merlin Moncure
• Re: BETWEEN optimizer problems with single-value range
  • From: Andreas Kretschmer
• Re: Background writer configuration
  • From: Kevin Grittner
• Re: BETWEEN optimizer problems with single-value
  • From: Kevin Grittner
• Re: Background writer configuration
  • From: Joshua D. Drake
• Background writer configuration
  • From: Kevin Grittner
• Slow SELECTS after large update cycle
  • From: Jan de Visser
• Re: BETWEEN optimizer problems with single-value range
  • From: Merlin Moncure
• Re: BETWEEN optimizer problems with single-value
  • From: Tom Lane
• Re: BETWEEN optimizer problems with single-value
  • From: Kevin Grittner
• Re: VACUUM FULL hangs
  • From: Marcin Mańk
• Re: BETWEEN optimizer problems with single-value range
  • From: Andreas Kretschmer
• BETWEEN optimizer problems with single-value range
  • From: Kevin Grittner
• Re: VACUUM FULL hangs
  • From: Richard Huxton
• VACUUM FULL hangs
  • From: Marcin Mańk
• Re: x206-x225
  • From: Richard Huxton
• Re: Vacuum template databases, Urgent: Production probl
  • From: Vivek Khera
• Re: x206-x225
  • From: Jim C. Nasby
• Re: x206-x225
  • From: Richard Huxton
• Re: Vacuum template databases, Urgent: Production probl
  • From: Jim C. Nasby
• Re: Vacuum template databases, Urgent: Production probl
  • From: mcelroy, tim
• Re: Vacuum template databases, Urgent: Production probl
  • From: Jim C. Nasby
• Re: Vacuum template databases, Urgent: Production problem
  • From: Jim C. Nasby
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Jim C. Nasby
• Re: x206-x225
  • From: Jim C. Nasby
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Jim C. Nasby
• Re: Process Time X200
  • From: Jim C. Nasby
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Merlin Moncure
• firebird X postgresql 8.1.2 windows, performance comparison
  • From: andremachado
• Re: Vacuum template databases, Urgent: Production probl
  • From: mcelroy, tim
• Re: Vacuum template databases, Urgent: Production problem
  • From: Tom Lane
• Vacuum template databases, Urgent: Production problem
  • From: Pallav Kalva
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Merlin Moncure
• Re: PG Statistics
  • From: mcelroy, tim
• Re: PG Statistics
  • From: mcelroy, tim
• firebird X postgresql 8.1.2 windows, performance comparison
  • From: andremachado
• Re: import performance
  • From: Chris
• Re: import performance
  • From: David Lang
• Re: import performance
  • From: Chris
• Re: import performance
  • From: Frank Wiles
• Re: import performance
  • From: Tom Lane
• Re: import performance
  • From: Chris
• Re: import performance
  • From: Frank Wiles
• Re: import performance
  • From: Chris
• Re: import performance
  • From: Gavin Sherry
• Re: import performance
  • From: Dave Dutcher
• Re: PG Statistics
  • From: Steve Poe
• Re: import performance
  • From: Gavin Sherry
• import performance
  • From: Chris
• Re: PG Statistics
  • From: Michael Fuhr
• PG Statistics
  • From: mcelroy, tim
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Scott Marlowe
• Re: No vacuum for insert-only database?
  • From: Josh Berkus
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Josh Berkus
• Re: No vacuum for insert-only database?
  • From: Bruno Wolff III
• firebird X postgresql 8.1.2 windows, performance comparison
  • From: andremachado
• Re: No vacuum for insert-only database?
  • From: Alvaro Herrera
• Re: No vacuum for insert-only database?
  • From: Craig A. James
• Re: No vacuum for insert-only database?
  • From: Alvaro Herrera
• No vacuum for insert-only database?
  • From: Craig A. James
• unsubscribe
  • From: Nick Howden
• Re: Query time
  • From: PFC
• Re: Query time
  • From: Ruben Rubio Rey
• Re: help needed asap....
  • From: Bruno Wolff III
• Re: help needed asap....
  • From: Matthew Nuzum
• help needed asap....
  • From: Phadnis
• Re: Postgres and Ingres R3 / SAN
  • From: Josh Berkus
• Re: x206-x225
  • From: David Lang
• Re: x206-x225
  • From: Joost Kraaijeveld
• Re: x206-x225
  • From: Tom Lane
• Re: x206-x225
  • From: Joost Kraaijeveld
• Re: x206-x225
  • From: PFC
• Re: x206-x225
  • From: Joost Kraaijeveld
• Re: x206-x225
  • From: David Lang
• Re: x206-x225
  • From: Joost Kraaijeveld
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Chris Travers
• firebird X postgresql 8.1.2 windows, performance comparison
  • From: Andre Felipe Machado
• Re: Trouble managing planner for timestamptz columns
  • From: Tom Lane
• Re: Trouble managing planner for timestamptz columns
  • From: Marc Morin
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: one-field index vs. multi-field index planner
  • From: Tom Lane
• Re: Hanging queries on dual CPU windows
  • From: Magnus Hagander
• Re: Trouble managing planner for timestamptz columns
  • From: Tom Lane
• Trouble managing planner for timestamptz columns
  • From: Marc Morin
• Re: one-field index vs. multi-field index planner
  • From: Evgeny Gridasov
• Re: one-field index vs. multi-field index planner estimates
  • From: Tom Lane
• Re: Process Time X200
  • From: Scott Marlowe
• one-field index vs. multi-field index planner estimates
  • From: Evgeny Gridasov
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Process Time X200
  • From: Matthew Nuzum
• Re: Query time
  • From: Jim C. Nasby
• Re: Using materialized views for commonly-queried subsets
  • From: Jim C. Nasby
• Re: pg_reset_stats + cache I/O %
  • From: Jim C. Nasby
• Re: Hanging queries on dual CPU windows
  • From: Magnus Hagander
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Hanging queries on dual CPU windows
  • From: Hakan Kocaman
• Re: x206-x225
  • From: Daniel Blaisdell
• Re: Query time
  • From: Richard Huxton
• Re: x206-x225
  • From: Richard Huxton
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Query time
  • From: Ruben Rubio Rey
• Re: Process Time X200
  • From: PFC
• Re: Query time
  • From: Michael Fuhr
• Re: Process Time X200
  • From: NbForYou
• Re: Query time
  • From: Ruben Rubio Rey
• Re: Process Time X200
  • From: Richard Huxton
• Query time
  • From: Ruben Rubio Rey
• FW: x206-x226
  • From: H.J. Sanders
• x206-x225
  • From: H.J. Sanders
• Re: Process Time X200
  • From: Ragnar
• Re: Process Time X200
  • From: Guido Neitzer
• Re: Hanging queries on dual CPU windows
  • From: Magnus Hagander
• Re: Process Time X200
  • From: NbForYou
• Re: Process Time X200
  • From: Michael Fuhr
• Process Time X200
  • From: NbForYou
• Using materialized views for commonly-queried subsets
  • From: Casey Allen Shobe
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: David Brown
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: pgCluster and postgres 8.1
  • From: Chris
• Re: Hanging queries on dual CPU windows
  • From: Magnus Hagander
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: Hanging queries on dual CPU windows
  • From: Tom Lane
• Re: Hanging queries on dual CPU windows
  • From: Jan de Visser
• Re: pg_reset_stats + cache I/O %
  • From: mcelroy, tim
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: PFC
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Carlos Henrique Reimer
• pgCluster and postgres 8.1
  • From: Javier Somoza
• Re: pg_reset_stats + cache I/O %
  • From: Jim C. Nasby
• embedded postgres and threading
  • From: Gorshkov
• Re: Postgres and Ingres R3 / SAN
  • From: Jim Nasby
• Re: Is good idea an array of 365 elements in a cell of a table, in order to perform searchs?
  • From: Jim C. Nasby
• Re: pg_reset_stats + cache I/O %
  • From: mcelroy, tim
• Re: pg_reset_stats + cache I/O %
  • From: Jim C. Nasby
• Re: Bad row estimates
  • From: Greg Stark
• Re: Bad row estimates
  • From: Alex Adriaanse
• Is good idea an array of 365 elements in a cell of a table, in order to perform searchs?
  • From: Ruben Rubio Rey
• Re: pg_reset_stats + cache I/O %
  • From: mcelroy, tim
• Re: Postgres on VPS - how much is enough?
  • From: Matthew Nuzum
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Andre Felipe Machado
• Re: Can anyone explain this pgbench results?
  • From: Jim C. Nasby
• Re: Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: Postgres on VPS - how much is enough?
  • From: Dave Page
• Re: Can anyone explain this pgbench results?
  • From: Jim C. Nasby
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Tom Lane
• Re: Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: pg_reset_stats + cache I/O %
  • From: Tom Lane
• Re: Postgres and Ingres R3 / SAN
  • From: Jim C. Nasby
• Re: Postgres and Ingres R3 / SAN
  • From: Mark Lewis
• Re: Can anyone explain this pgbench results?
  • From: Jim C. Nasby
• pg_reset_stats + cache I/O %
  • From: mcelroy, tim
• Re: Postgres and Ingres R3 / SAN
  • From: Jim C. Nasby
• Re: Postgres on VPS - how much is enough?
  • From: Jim C. Nasby
• Re: t1000/t2000 sun-servers
  • From: Jim C. Nasby
• Re: Planner enhancement suggestion.
  • From: Jim C. Nasby
• Re: Planner enhancement suggestion.
  • From: PFC
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Alvaro Herrera
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Scott Marlowe
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Alvaro Herrera
• Re: firebird X postgresql 8.1.2 windows, performance
  • From: Scott Marlowe
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Carlos Henrique Reimer
• Re: firebird X postgresql 8.1.2 windows, performance comparison
  • From: Joshua D. Drake
• firebird X postgresql 8.1.2 windows, performance comparison
  • From: andremachado
• Re: Help understanding indexes, explain, and optimizing
  • From: Tom Lane
• Re: Help understanding indexes, explain, and optimizing
  • From: Dave Dutcher
• Re: Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: Sequencial scan instead of using index
  • From: Mark Kirkwood
• Re: Can anyone explain this pgbench results?
  • From: Michael Fuhr
• Re: Help understanding indexes, explain, and optimizing
  • From: i.v.r.
• Re: Help understanding indexes, explain, and optimizing
  • From: Chris
• Re: Planner enhancement suggestion.
  • From: Jim C. Nasby
• Help understanding indexes, explain, and optimizing a query
  • From: i.v.r.
• Re: t1000/t2000 sun-servers
  • From: Jignesh K. Shah
• Re: t1000/t2000 sun-servers
  • From: Guido Neitzer
• Re: Sequencial scan instead of using index
  • From: Ragnar
• Re: Can anyone explain this pgbench results?
  • From: Michael Fuhr
• Re: t1000/t2000 sun-servers
  • From: Jignesh K. Shah
• Postgres and Ingres R3 / SAN
  • From: Jeremy Haile
• Re: Postgres on VPS - how much is enough?
  • From: Matthew Nuzum
• Sequencial scan instead of using index
  • From: Harry Hehl
• Re: Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: Can anyone explain this pgbench results?
  • From: Michael Fuhr
• Re: Postgres on VPS - how much is enough?
  • From: Marc G. Fournier
• Re: Postgres on VPS - how much is enough?
  • From: Nagita Karunaratne
• Can anyone explain this pgbench results?
  • From: Joost Kraaijeveld
• Re: Postgres on VPS - how much is enough?
  • From: Kevin
• Re: Postgres on VPS - how much is enough?
  • From: Matthew Nuzum
• Hanging queries and I/O exceptions
  • From: Jan de Visser
• Re: t1000/t2000 sun-servers
  • From: Neil Saunders
• Postgres on VPS - how much is enough?
  • From: Nagita Karunaratne
• t1000/t2000 sun-servers
  • From: Claus Guttesen
• Planner enhancement suggestion.
  • From: PFC
• Re: How to query and index for customer with lastname and city
  • From: Kevin Brown
• Re: Bad row estimates
  • From: Greg Stark
• Re: Bad row estimates
  • From: Tom Lane
• Re: Bad row estimates
  • From: Jim C. Nasby