Postgres Performance Date Index

• Thread Index

• Re: simple case using index on windows but not on linux
  • From: Richard Huxton
• Re: PostgreSQL Caching
  • From: Dave Dutcher
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Markus Schaber
• Re: slow queue-like empty table
  • From: Tobias Brox
• Re: simple case using index on windows but not on linux
  • From: Richard Huxton
• Re: simple case using index on windows but not on linux
  • From: Richard Huxton
• Re: simple case using index on windows but not on linux
  • From: simon godden
• Re: simple case using index on windows but not on linux
  • From: simon godden
• Re: simple case using index on windows but not on linux
  • From: Heikki Linnakangas
• Unsubscribe
  • From: Luc Delgado
• simple case using index on windows but not on linux
  • From: simon godden
• Re: PostgreSQL Caching
  • From: Adnan DURSUN
• Re: PostgreSQL Caching
  • From: Tomeh, Husam
• Re: Forcing the use of particular execution plans
  • From: Jim C. Nasby
• Re: Forcing the use of particular execution plans
  • From: Ron Mayer
• Re: PostgreSQL Caching
  • From: Adnan DURSUN
• Re: BUG #2658: Query not using index
  • From: Tom Lane
• Re: PostgreSQL Caching
  • From: Tomeh, Husam
• Re: BUG #2658: Query not using index
  • From: Mark Lewis
• PostgreSQL Caching
  • From: Adnan DURSUN
• Re: BUG #2658: Query not using index
  • From: Graham Davis
• Re: BUG #2658: Query not using index
  • From: Mark Lewis
• Re: BUG #2658: Query not using index
  • From: Graham Davis
• Re: BUG #2658: Query not using index
  • From: Mark Lewis
• Re: BUG #2658: Query not using index
  • From: Graham Davis
• Re: BUG #2658: Query not using index
  • From: Tom Lane
• Re: BUG #2658: Query not using index
  • From: Bruno Wolff III
• Re: BUG #2658: Query not using index
  • From: Graham Davis
• Re: BUG #2658: Query not using index
  • From: Chris Browne
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Merlin Moncure
• Re: BUG #2658: Query not using index
  • From: Graham Davis
• Re: BUG #2658: Query not using index
  • From: Graham Davis
• Re: BUG #2658: Query not using index
  • From: Chris Browne
• Re: BUG #2658: Query not using index
  • From: Graham Davis
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Unsubscribe
  • From: Carlo Stonebanks
• Re: Unsubscribe
  • From: felix
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Alex Stapleton
• Re: Poor performance on very simple query ?
  • From: Darcy Buskermolen
• Re: Poor performance on very simple query ?
  • From: Darcy Buskermolen
• Re: Performance Optimization for Dummies 2 - the SQL
  • From: Merlin Moncure
• Re: Unsubscribe
  • From: Geoffrey
• Re: Poor performance on very simple query ?
  • From: Tom Lane
• Re: Poor performance on very simple query ?
  • From: Guillaume Cottenceau
• Re: Poor performance on very simple query ?
  • From: Arnaud Lesauvage
• Re: Poor performance on very simple query ?
  • From: Tobias Brox
• Re: Poor performance on very simple query ?
  • From: Arnaud Lesauvage
• Re: Poor performance on very simple query ?
  • From: Tobias Brox
• Re: Poor performance on very simple query ?
  • From: Tobias Brox
• Re: Poor performance on very simple query ?
  • From: Alexander Staubo
• Re: Poor performance on very simple query ?
  • From: Arnaud Lesauvage
• Re: Poor performance on very simple query ?
  • From: Steinar H. Gunderson
• Poor performance on very simple query ?
  • From: Arnaud Lesauvage
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Performance Optimization for Dummies 2 - the SQL
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Markus Schaber
• Re: Performace Optimization for Dummies
  • From: Markus Schaber
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: Forcing the use of particular execution plans
  • From: Tim Truman
• Re: Forcing the use of particular execution plans
  • From: Tom Lane
• Re: Forcing the use of particular execution plans
  • From: Tim Truman
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: selecting data from information_schema.columns
  • From: Jim Nasby
• Re: selecting data from information_schema.columns
  • From: Steve Martin
• Re: Unsubscribe
  • From: Markus Schaber
• Re: selecting data from information_schema.columns performance.
  • From: Jim C. Nasby
• Re: Table not getting vaccumed.
  • From: Jim C. Nasby
• Unsubscribe
  • From: uwcssa
• Re: How much memory in 32 bits Architecture to Shared Buffers is Possible
  • From: Marcelo Costa
• Re: How much memory in 32 bits Architecture to Shared Buffers
  • From: Joshua D. Drake
• Re: archive wal's failure and load increase.
  • From: Simon Riggs
• Re: Optimizing queries
  • From: Simon Riggs
• Re: any hope for my big query?
  • From: Shaun Thomas
• How much memory in 32 bits Architecture to Shared Buffers is Possible
  • From: Marcelo Costa
• Re: PostgreSQL runs a query much slower than BDE and
  • From: Simon Riggs
• Re: selecting data from information_schema.columns performance.
  • From: Tom Lane
• selecting data from information_schema.columns performance.
  • From: Steve Martin
• Re: Table not getting vaccumed.
  • From: Tom Lane
• Re: how to optimize postgres 8.1
  • From: Markus Schaber
• Table not getting vaccumed.
  • From: Nimesh Satam
• Re: Postgres locking up?
  • From: Robert Becker Cope
• Re: cont. how to optimize postgres 8.1
  • From: Tom Lane
• cont. how to optimize postgres 8.1
  • From: gurkan
• Re: [NOVICE] Postgres locking up?
  • From: Tom Lane
• Re: Postgres locking up?
  • From: Andrew Sullivan
• Postgres locking up?
  • From: Brian Hurt
• Re: how to optimize postgres 8.1
  • From: Tom Lane
• how to optimize postgres 8.1
  • From: gurkan
• Re: archive wal's failure and load increase.
  • From: Tom Lane
• Re: any hope for my big query?
  • From: Jim C. Nasby
• Re: archive wal's failure and load increase.
  • From: Simon Riggs
• Re: Performace Optimization for Dummies
  • From: Merlin Moncure
• Re: archive wal's failure and load increase.
  • From: Tom Lane
• Re: Performace Optimization for Dummies
  • From: Bill Moran
• Re: Performace Optimization for Dummies
  • From: Markus Schaber
• Re: Performace Optimization for Dummies
  • From: Markus Schaber
• Re: any hope for my big query?
  • From: Simon Riggs
• Re: archive wal's failure and load increase.
  • From: Simon Riggs
• Re: Performace Optimization for Dummies
  • From: Simon Riggs
• Re: any hope for my big query?
  • From: Edoardo Ceccarelli
• Re: Performace Optimization for Dummies
  • From: Heikki Linnakangas
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Tom Lane
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Matthew Nuzum
• Re: any hope for my big query?
  • From: Jim C. Nasby
• Re: Performace Optimization for Dummies
  • From: Jim C. Nasby
• any hope for my big query?
  • From: Ben
• Re: archive wal's failure and load increase.
  • From: Tom Lane
• Re: Performace Optimization for Dummies
  • From: Steve Atkins
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Merlin Moncure
• Re: slow queue-like empty table
  • From: Andrew Sullivan
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• archive wal's failure and load increase.
  • From: Cedric Boudin
• Re: Performace Optimization for Dummies
  • From: Merlin Moncure
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Matthew Nuzum
• RES: Performace Optimization for Dummies
  • From: Leandro Guimarães dos Santos
• [no subject]
  • From: Jim C. Nasby
• Re: Performace Optimization for Dummies
  • From: Jim C. Nasby
• Re: Performace Optimization for Dummies
  • From: Jim C. Nasby
• Re: Performace Optimization for Dummies
  • From: Jim C. Nasby
• Re: Performace Optimization for Dummies
  • From: Dave Dutcher
• Re: Performace Optimization for Dummies
  • From: Steve Atkins
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Problems with inconsistant query performance.
  • From: Bill Moran
• Re: Performace Optimization for Dummies
  • From: Merlin Moncure
• Re: Performace Optimization for Dummies
  • From: Joshua D. Drake
• Performace Optimization for Dummies
  • From: Carlo Stonebanks
• Re: Problems with inconsistant query performance.
  • From: Jim C. Nasby
• Re: Problems with inconsistant query performance.
  • From: Bill Moran
• Re: Problems with inconsistant query performance.
  • From: Matthew Schumacher
• Re: Problems with inconsistant query performance.
  • From: Marcin Mank
• Re: slow i/o
  • From: Jignesh K. Shah
• Re: slow queue-like empty table
  • From: Csaba Nagy
• Re: autovacuum on a -mostly- r/o table
  • From: Edoardo Ceccarelli
• Re: slow queue-like empty table
  • From: Tobias Brox
• slow queue-like empty table
  • From: Tobias Brox
• Re: Problems with inconsistant query performance.
  • From: Jim C. Nasby
• Re: Problems with inconsistant query performance.
  • From: Matthew Schumacher
• Re: Problems with inconsistant query performance.
  • From: Jim C. Nasby
• Re: Problems with inconsistant query performance.
  • From: Matthew Schumacher
• Re: Problems with inconsistant query performance.
  • From: Jim C. Nasby
• Re: autovacuum on a -mostly- r/o table
  • From: Bill Moran
• Re: Forcing the use of particular execution plans
  • From: Jim C. Nasby
• Re: Merge Join vs Nested Loop
  • From: Tobias Brox
• Problems with inconsistant query performance.
  • From: Matthew Schumacher
• Re: [ADMIN] autovacuum on a -mostly- r/o table
  • From: Matthew T. O'Connor
• Re: autovacuum on a -mostly- r/o table
  • From: Rod Taylor
• Re: autovacuum on a -mostly- r/o table
  • From: Tobias Brox
• Re: autovacuum on a -mostly- r/o table
  • From: Edoardo Ceccarelli
• Re: autovacuum on a -mostly- r/o table
  • From: Edoardo Ceccarelli
• Re: autovacuum on a -mostly- r/o table
  • From: Bill Moran
• Re: autovacuum on a -mostly- r/o table
  • From: Csaba Nagy
• Re: autovacuum on a -mostly- r/o table
  • From: Tobias Brox
• Re: autovacuum on a -mostly- r/o table
  • From: Alan Hodgson
• autovacuum on a -mostly- r/o table
  • From: Edoardo Ceccarelli
• Re: Forcing the use of particular execution plans
  • From: Dave Dutcher
• Re: Merge Join vs Nested Loop
  • From: Tobias Brox
• Re: Merge Join vs Nested Loop
  • From: Scott Marlowe
• Re: Merge Join vs Nested Loop
  • From: Tobias Brox
• Re: Merge Join vs Nested Loop
  • From: Scott Marlowe
• Re: Merge Join vs Nested Loop
  • From: Tobias Brox
• Re: Merge Join vs Nested Loop
  • From: Scott Marlowe
• Re: Forcing the use of particular execution plans
  • From: Jochem van Dieten
• Re: Merge Join vs Nested Loop
  • From: Tobias Brox
• Forcing the use of particular execution plans
  • From: Tim Truman
• Re: PostgreSQL and sql-bench
  • From: Jim Nasby
• Re: Confusion and Questions about blocks read
  • From: Jim Nasby
• Re: Decreasing BLKSZ
  • From: Jim Nasby
• Re: IN not handled very well?
  • From: Jim Nasby
• Re: Update on high concurrency OLTP application and Postgres
  • From: Jim Nasby
• Re: slow i/o
  • From: Junaili Lie
• Re: Decreasing BLKSZ
  • From: Markus Schaber
• Re: Decreasing BLKSZ
  • From: Bucky Jordan
• Re: Merge Join vs Nested Loop
  • From: Tom Lane
• Re: Decreasing BLKSZ
  • From: Marc Morin
• Re: Decreasing BLKSZ
  • From: Bucky Jordan
• Merge Join vs Nested Loop
  • From: Tobias Brox
• Re: Decreasing BLKSZ
  • From: Marc Morin
• Re: Decreasing BLKSZ
  • From: Mark Lewis
• Re: Decreasing BLKSZ
  • From: Tom Lane
• Re: Decreasing BLKSZ
  • From: Marc Morin
• Re: Decreasing BLKSZ
  • From: Markus Schaber
• Decreasing BLKSZ
  • From: Marc Morin
• Re: PostgreSQL and sql-bench
  • From: yoav x
• Re: Large tables (was: RAID 0 not as fast as
  • From: Luke Lonergan
• Re: Multi-processor question
  • From: Markus Schaber
• Multi-processor question
  • From: Kjell Tore Fossbakk
• Re: IN not handled very well?
  • From: Ben
• Re: IN not handled very well?
  • From: Tom Lane
• IN not handled very well?
  • From: Ben
• Re: Large tables (was: RAID 0 not as fast as
  • From: Ron Mayer
• Re: Opteron vs. Xeon "benchmark"
  • From: Dave Cramer
• Re: Update on high concurrency OLTP application and Postgres
  • From: Cosimo Streppone
• Re: Opteron vs. Xeon "benchmark"
  • From: Guido Neitzer
• Re: Opteron vs. Xeon "benchmark"
  • From: Dave Cramer
• Re: Opteron vs. Xeon "benchmark"
  • From: Guido Neitzer
• Re: Confusion and Questions about blocks read
  • From: Markus Schaber
• Re: recommended benchmarks
  • From: Denis Lussier
• Re: Why is it choosing a different plan?
  • From: Anthony Presley
• Re: Why is it choosing a different plan?
  • From: Anthony Presley
• Why is it choosing a different plan?
  • From: Anthony Presley
• Re: Opteron vs. Xeon "benchmark"
  • From: mark
• Re: Opteron vs. Xeon "benchmark"
  • From: Arjen van der Meijden
• Re: Confusion and Questions about blocks read
  • From: Alex Turner
• Re: recommended benchmarks
  • From: Bucky Jordan
• Re: Opteron vs. Xeon "benchmark"
  • From: Vivek Khera
• Re: recommended benchmarks
  • From: Brad Nicholson
• recommended benchmarks
  • From: Charles Sprickman
• Re: Confusion and Questions about blocks read
  • From: Alex Turner
• Re: Confusion and Questions about blocks read
  • From: Tom Lane
• Confusion and Questions about blocks read
  • From: Alex Turner
• Re: Large tables (was: RAID 0 not as fast as
  • From: Jim C. Nasby
• Re: Large tables (was: RAID 0 not as fast as
  • From: Jim C. Nasby
• Re: Opteron vs. Xeon "benchmark"
  • From: nicky
• Re: Large tables (was: RAID 0 not as fast as
  • From: Markus Schaber
• Re: Opteron vs. Xeon "benchmark"
  • From: Arjen van der Meijden
• Opteron vs. Xeon "benchmark"
  • From: Hannes Dorbath
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: Large tables (was: RAID 0 not as fast as
  • From: Luke Lonergan
• Re: Large tables (was: RAID 0 not as fast as
  • From: mark
• Re: Large tables (was: RAID 0 not as fast as
  • From: Bruce Momjian
• Re: Large tables (was: RAID 0 not as fast as
  • From: Guy Thornley
• Re: Large tables (was: RAID 0 not as fast as
  • From: Luke Lonergan
• Re: PostgreSQL and sql-bench
  • From: Arjen van der Meijden
• Re: PostgreSQL and sql-bench
  • From: Jim C. Nasby
• Re: Large tables (was: RAID 0 not as fast as
  • From: Markus Schaber
• Re: Large tables (was: RAID 0 not as fast as
  • From: Bucky Jordan
• Re: Large tables (was: RAID 0 not as fast as
  • From: Markus Schaber
• Re: Large tables (was: RAID 0 not as fast as
  • From: Mark Lewis
• Re: Large tables (was: RAID 0 not as fast as
  • From: Bucky Jordan
• Re: PostgreSQL and sql-bench
  • From: Jeff Davis
• Re: PostgreSQL and sql-bench
  • From: Tom Lane
• Re: PostgreSQL and sql-bench
  • From: Guido Neitzer
• Re: PostgreSQL and sql-bench
  • From: Mark Lewis
• Re: PostgreSQL and sql-bench
  • From: Brad Nicholson
• PostgreSQL and sql-bench
  • From: yoav x
• Re: Large tables (was: RAID 0 not as fast as
  • From: Markus Schaber
• Re: Large tables (was: RAID 0 not as fast as
  • From: Luke Lonergan
• Re: running benchmark test on a 50GB database
  • From: Jim C. Nasby
• Re: Large tables (was: RAID 0 not as fast as
  • From: Ron
• Re: Large tables (was: RAID 0 not as fast as
  • From: Markus Schaber
• Re: Large tables (was: RAID 0 not as fast as
  • From: Luke Lonergan
• Re: running benchmark test on a 50GB database
  • From: Chris Mair
• Re: running benchmark test on a 50GB database
  • From: Dave Dutcher
• running benchmark test on a 50GB database
  • From: Nuno Alves
• Re: Update on high concurrency OLTP application and Postgres
  • From: Cosimo Streppone
• Re: Update on high concurrency OLTP application and Postgres 8 tuning
  • From: Andrew Sullivan
• Update on high concurrency OLTP application and Postgres 8 tuning
  • From: Cosimo Streppone
• Re: Large tables (was: RAID 0 not as fast as
  • From: Markus Schaber
• Re: Pipelined functions in Postgres
  • From: Jeff Davis
• Re: Pipelined functions in Postgres
  • From: Shoaib Mir
• Re: Pipelined functions in Postgres
  • From: Milen Kulev
• Re: Pipelined functions in Postgres
  • From: Milen Kulev
• Re: Pipelined functions in Postgres
  • From: Talha Khan
• Re: Pipelined functions in Postgres
  • From: Shoaib Mir
• Pipelined functions in Postgres
  • From: Milen Kulev
• Re: Optimizing DELETE
  • From: Ivan Voras
• Re: Optimizing DELETE
  • From: Mark Lewis
• Re: Optimizing DELETE
  • From: Rod Taylor
• Re: Optimizing DELETE
  • From: Csaba Nagy
• Re: Large tables (was: RAID 0 not as fast as expected)
  • From: Bucky Jordan
• Optimizing DELETE
  • From: Ivan Voras
• Re: High CPU Load
  • From: Markus Schaber
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: High CPU Load
  • From: Markus Schaber
• Re: Large tables (was: RAID 0 not as fast as
  • From: Luke Lonergan
• Re: Large tables (was: RAID 0 not as fast as expected)
  • From: mark
• Re: Large tables (was: RAID 0 not as fast as
  • From: Luke Lonergan
• Re: Large tables (was: RAID 0 not as fast as expected)
  • From: Alex Turner
• Re: LIKE query problem
  • From: Marc McIntyre
• Re: LIKE query problem
  • From: Tom Lane
• Re: Large tables (was: RAID 0 not as fast as
  • From: Luke Lonergan
• Re: Large tables (was: RAID 0 not as fast as expected)
  • From: Luke Lonergan
• Re: Vacuums on large busy databases
  • From: Francisco Reyes
• LIKE query problem
  • From: Marc McIntyre
• Re: Large tables (was: RAID 0 not as fast as expected)
  • From: Michael Stone
• Re: Large tables (was: RAID 0 not as fast as expected)
  • From: Alex Turner
• Re: Large tables (was: RAID 0 not as fast as expected)
  • From: Bucky Jordan
• Re: Vacuums on large busy databases
  • From: Jim C. Nasby
• Re: Large tables (was: RAID 0 not as fast as expected)
  • From: Alan Hodgson
• Re: Large tables (was: RAID 0 not as fast as expected)
  • From: Merlin Moncure
• Re: High CPU Load
  • From: Guillaume Smet
• Re: High CPU Load
  • From: Jérôme BENOIS
• Large tables (was: RAID 0 not as fast as expected)
  • From: Bucky Jordan
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: Poor performance on seq scan
  • From: Guido Neitzer
• Re: Poor performance on seq scan
  • From: Markus Schaber
• Re: Optimize SQL
  • From: Mikael Carneholm
• Re: Partition elimination problem -> Solved
  • From: Milen Kulev
• Re: Partition elimination problem
  • From: Milen Kulev
• Re: Partition elimination problem
  • From: Tom Lane
• Partition elimination problem
  • From: Milen Kulev
• Re: RAID 0 not as fast as expected
  • From: Joshua D. Drake
• Re: RAID 0 not as fast as expected
  • From: Steinar H. Gunderson
• Re: RAID 0 not as fast as expected
  • From: Luke Lonergan
• Re: RAID 0 not as fast as expected
  • From: Luke Lonergan
• Re: Performance of IN (...) vs. = ANY array[...]
  • From: Tom Lane
• Performance of IN (...) vs. = ANY array[...]
  • From: Benjamin Minshall
• Re: RAID 0 not as fast as expected
  • From: Bucky Jordan
• Re: Optimize SQL
  • From: Arjen van der Meijden
• Re: Why the difference in plans ??
  • From: Tom Lane
• Re: Why the difference in plans ??
  • From: Joost Kraaijeveld
• Re: Optimize SQL
  • From: Tom Lane
• Re: RAID 0 not as fast as expected
  • From: Luke Lonergan
• Optimize SQL
  • From: Pallav Kalva
• Re: Why the difference in plans ??
  • From: Tom Lane
• Re: RAID 0 not as fast as expected
  • From: Spiegelberg, Greg
• Re: High CPU Load
  • From: Guillaume Smet
• Lanzamiento www.PortalTPV.com
  • From: Portal TPV
• Re: Vacuums on large busy databases
  • From: Markus Schaber
• Re: High CPU Load
  • From: Markus Schaber
• Why the difference in plans ??
  • From: Joost Kraaijeveld
• Re: RAID 0 not as fast as expected
  • From: Joshua D. Drake
• Re: RAID 0 not as fast as expected
  • From: Joshua D. Drake
• Re: RAID 0 not as fast as expected
  • From: Luke Lonergan
• Re: Vacuums on large busy databases
  • From: Jeff Davis
• Re: Vacuums on large busy databases
  • From: Jeff Davis
• Re: Vacuums on large busy databases
  • From: Michael Stone
• Re: Vacuums on large busy databases
  • From: Jeff Davis
• Re: Vacuums on large busy databases
  • From: Jeff Davis
• Re: Vacuums on large busy databases
  • From: Jeff Davis
• Re: sql-bench
  • From: Steinar H. Gunderson
• Re: sql-bench
  • From: Grega Bremec
• Re: Vacuums on large busy databases
  • From: Michael Stone
• Re: Vacuums on large busy databases
  • From: Dave Cramer
• Re: Vacuums on large busy databases
  • From: Francisco Reyes
• Re: Vacuums on large busy databases
  • From: Francisco Reyes
• Re: Vacuums on large busy databases
  • From: Francisco Reyes
• Re: High CPU Load
  • From: Bucky Jordan
• Re: High CPU Load
  • From: Guillaume Smet
• Re: RAID 0 not as fast as expected
  • From: Scott Marlowe
• Re: Vacuums on large busy databases
  • From: Dave Cramer
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: Vacuums on large busy databases
  • From: Jeff Davis
• Re: RAID 0 not as fast as expected
  • From: Craig A. James
• Re: High CPU Load
  • From: Guillaume Smet
• Re: High CPU Load
  • From: Tom Lane
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: Vacuums on large busy databases
  • From: Michael Stone
• Re: Vacuums on large busy databases
  • From: Francisco Reyes
• Re: Performance problem with Sarge compared with
  • From: Bruce Momjian
• Re: RAID 0 not as fast as expected
  • From: Alan Hodgson
• Re: RAID 0 not as fast as expected
  • From: Joshua D. Drake
• Re: Vacuums on large busy databases
  • From: Dave Cramer
• RAID 0 not as fast as expected
  • From: Craig A. James
• Re: Vacuums on large busy databases
  • From: Francisco Reyes
• Re: Vacuums on large busy databases
  • From: Francisco Reyes
• Re: High CPU Load
  • From: Evgeny Gridasov
• Re: Vacuums on large busy databases
  • From: Dave Cramer
• Re: High CPU Load
  • From: Scott Marlowe
• Vacuums on large busy databases
  • From: Francisco Reyes
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: High CPU Load
  • From: Dave Dutcher
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: High CPU Load
  • From: Guillaume Smet
• Re: High CPU Load
  • From: Scott Marlowe
• Re: Performance With Joins on Large Tables
  • From: Joshua Marsh
• Re: High CPU Load
  • From: Scott Marlowe
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: High CPU Load
  • From: Tom Lane
• Re: High CPU Load
  • From: Jérôme BENOIS
• Re: High CPU Load
  • From: Guillaume Smet
• High CPU Load
  • From: Jérôme BENOIS
• Re: sql-bench
  • From: Dave Cramer
• Re: sql-bench
  • From: Markus Schaber
• Re: sql-bench
  • From: yoav x
• Re: sql-bench
  • From: Merlin Moncure
• Re: Performance With Joins on Large Tables
  • From: Tom Lane
• Unsubscribe
  • From: Jamal Ghaffour
• Re: Performance With Joins on Large Tables
  • From: Joshua Marsh
• Re: sql-bench
  • From: Tom Lane
• Re: Performance With Joins on Large Tables
  • From: Tom Lane
• Re: Poor performance on seq scan
  • From: Ivan Voras
• Re: Performance With Joins on Large Tables
  • From: Joshua Marsh
• Re: sql-bench
  • From: Scott Marlowe
• Re: Performance With Joins on Large Tables
  • From: Tom Lane
• Re: Unsubscribe
  • From: Geoffrey
• Re: sql-bench
  • From: Tom Lane
• Re: Poor performance on seq scan
  • From: Luke Lonergan
• Re: Performance With Joins on Large Tables
  • From: Joshua Marsh
• Re: Performance With Joins on Large Tables
  • From: Terje Elde
• Re: sql-bench
  • From: Merlin Moncure
• Re: Performance With Joins on Large Tables
  • From: Joshua Marsh
• Re: Query Progress (was: Performance With Joins on Large Tables)
  • From: Joshua Marsh
• Re: Performance With Joins on Large Tables
  • From: Marcin Mank
• Query Progress (was: Performance With Joins on Large Tables)
  • From: Bucky Jordan
• Unsubscribe
  • From: Christoph Nelles
• Re: Performance With Joins on Large Tables
  • From: Jeff Davis
• Re: Performance With Joins on Large Tables
  • From: Joshua Marsh
• Re: Performance With Joins on Large Tables
  • From: Jeff Davis
• Re: sql-bench
  • From: Tom Lane
• Re: Performance With Joins on Large Tables
  • From: Joshua Marsh
• Re: sql-bench
  • From: Mark Lewis
• Re: sql-bench
  • From: Dave Cramer
• Re: sql-bench
  • From: yoav x
• Re: sql-bench
  • From: Dave Cramer
• sql-bench
  • From: yoav x
• Re: Poor performance on seq scan
  • From: Dave Cramer
• Re: Poor performance on seq scan
  • From: Laszlo Nagy
• Re: Performance With Joins on Large Tables
  • From: Jim C. Nasby
• Re:
  • From: Jim C. Nasby
• Re: Bad plan for join to aggregate of join.
  • From: Mischa Sandberg
• Re: Poor performance on seq scan
  • From: Mark Kirkwood
• Re: Bad plan for join to aggregate of join.
  • From: Tom Lane
• Re: Poor performance on seq scan
  • From: Luke Lonergan
• Performance With Joins on Large Tables
  • From: Joshua Marsh
• Re: Poor performance on seq scan
  • From: Laszlo Nagy
• Re: Poor performance on seq scan
  • From: Craig A. James
• Bad plan for join to aggregate of join.
  • From: Mischa Sandberg
• Re: Poor performance on seq scan
  • From: Tom Lane
• [no subject]
  • From: jallgood
• Re: [Fwd: Re: Performance problem with Sarge compared
  • From: Alvaro Herrera
• Re: [Fwd: Re: Performance problem with Sarge compared
  • From: Dave Dutcher
• Re: tsearch2 question (was: Poor performance on seq
  • From: Luke Lonergan
• Re: [Fwd: Re: Performance problem with Sarge compared
  • From: Piñeiro
• Re: Poor performance on seq scan
  • From: Laszlo Nagy
• tsearch2 question (was: Poor performance on seq scan)
  • From: Laszlo Nagy
• Re: Poor performance on seq scan
  • From: Tom Lane
• Re: Poor performance on seq scan
  • From: Luke Lonergan
• Re: [Fwd: Re: Performance problem with Sarge compared
  • From: Scott Marlowe
• [Fwd: Re: Performance problem with Sarge compared with Woody]
  • From: Piñeiro
• Re: Performance problem with Sarge compared with Woody
  • From: Merlin Moncure
• Re: Reg - Autovacuum
  • From: Chris Mair
• Re: Performance problem with Sarge compared with Woody
  • From: Tom Lane
• Reg - Autovacuum
  • From: krishnaraj D
• Re: Poor performance on seq scan
  • From: Tom Lane
• Re: Performance problem with Sarge compared with Woody
  • From: Scott Marlowe
• Re: Performance problem with Sarge compared with Woody
  • From: Scott Marlowe
• Re: Poor performance on seq scan
  • From: Heikki Linnakangas
• Re: Poor performance on seq scan
  • From: Alvaro Herrera
• Re: Poor performance on seq scan
  • From: Heikki Linnakangas
• Re: Poor performance on seq scan
  • From: Guillaume Cottenceau
• Re: Poor performance on seq scan
  • From: Guillaume Cottenceau
• Re: Poor performance on seq scan
  • From: Laszlo Nagy
• Re: Poor performance on seq scan
  • From: Piotr Kołaczkowski
• Re: Poor performance on seq scan
  • From: Laszlo Nagy
• Re: Poor performance on seq scan
  • From: Luke Lonergan
• Re: Poor performance on seq scan
  • From: Heikki Linnakangas
• Poor performance on seq scan
  • From: Laszlo Nagy
• Re: Performance problem with Sarge compared with Woody
  • From: Piñeiro
• Re: Performance problem with Sarge compared with Woody
  • From: Merlin Moncure
• Re: Abysmal hash join
  • From: Gregory Stark
• Re: Configuring System for Speed
  • From: Luke Lonergan
• Re: Performance problem with Sarge compared with Woody
  • From: Scott Marlowe
• Re: Performance problem with Sarge compared with Woody
  • From: Jeff Davis
• Re: Performance problem with Sarge compared with Woody
  • From: Dave Dutcher
• Performance problem with Sarge compared with Woody
  • From: Piñeiro
• Re: Abysmal hash join
  • From: Florian Weimer
• Re: Configuring System for Speed
  • From: Brian Wipf
• Re: Abysmal hash join
  • From: Tom Lane
• Re: Abysmal hash join
  • From: Florian Weimer
• Re: Abysmal hash join
  • From: Tom Lane
• Re: Performance problem with joins
  • From: Tom Lane
• Abysmal hash join
  • From: Florian Weimer
• Re: Performance problem with joins
  • From: fardeen memon
• Re: Configuring System for Speed
  • From: Ron
• Re: Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with
  • From: Arjen van der Meijden
• Re: Performance in a 7 TB database.
  • From: Jeff Davis
• Re: Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with
  • From: Stefan Kaltenbrunner
• Re: Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with
  • From: Arjen van der Meijden
• Re: unsubscribe me
  • From: Guillaume Cottenceau
• unsubscribe me
  • From: Phadnis
• Re: Performance problem with joins
  • From: Tom Lane
• Re: Configuring System for Speed
  • From: alvis
• Re: Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with postgresql and some SAS raid-figures
  • From: Dave Cramer
• Performance problem with joins
  • From: fardeen memon
• Re: Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with
  • From: Arjen van der Meijden
• Re: Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with postgresql and some SAS raid-figures
  • From: Dave Cramer
• Performance in a 7 TB database.
  • From: Nuno Alexandre Alves
• Re: Configuring System for Speed
  • From: Luke Lonergan
• Configuring System for Speed
  • From: Brian Wipf
• Re: Xeon Woodcrest/Dempsey vs Opteron Socket F/940
  • From: Luke Lonergan
• Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with postgresql and some SAS raid-figures
  • From: Arjen van der Meijden
• Re: 64bit vs 32bit build on amd64
  • From: Jeff Davis
• Re: [HACKERS] Template0 age is increasing speedily.
  • From: Merlin Moncure
• Re: [PATCHES] Template0 age is increasing speedily.
  • From: Dave Dutcher
• Re: [PATCHES] Template0 age is increasing speedily.
  • From: Bill Moran
• Re: [PATCHES] Template0 age is increasing speedily.
  • From: Nimesh Satam
• Re: [PATCHES] Template0 age is increasing speedily.
  • From: Chris Mair
• Template0 age is increasing speedily.
  • From: Nimesh Satam
• Lists (In) performance
  • From: Marcus Vinicius
• Re: increasing shared buffers: how much should be removed
  • From: Dave Cramer
• Re: increasing shared buffers: how much should be removed
  • From: Merlin Moncure
• Re: Postgress memory leak with JBoss3.2.6 and large DB
  • From: Indika Maligaspe
• Re: database bloat,non removovable rows, slow query etc... [RESOLVED]
  • From: Tom Lane
• Re: database bloat,non removovable rows, slow query etc... [RESOLVED]
  • From: Gregory Stark
• Re: database bloat,non removovable rows, slow query etc... [RESOLVED]
  • From: Alvaro Herrera
• Re: database bloat,non removovable rows, slow query etc... [RESOLVED]
  • From: Gregory Stark
• 64bit vs 32bit build on amd64
  • From: Roman Krylov
• Re: how to partition disks
  • From: Francisco Reyes
• Re: increasing shared buffers: how much should be removed from OS filesystem cache?
  • From: Dave Cramer
• Re: increasing shared buffers: how much should be removed from OS filesystem cache?
  • From: Guillaume Cottenceau
• Re: increasing shared buffers: how much should be removed from OS filesystem cache?
  • From: Guillaume Cottenceau
• Re: [BUGS] Hanging queries on Windows 2003 SP1
  • From: Magnus Hagander
• Re: database bloat,non removovable rows, slow query etc...
  • From: Markus Schaber
• Re: Postgress memory leak with JBoss3.2.6 and large DB
  • From: Mark Kirkwood
• Re: database bloat,non removovable rows, slow query etc... [RESOLVED]
  • From: Tom Lane
• Re: database bloat,non removovable rows, slow query etc... [RESOLVED]
  • From: Dave Cramer
• Re: database bloat,non removovable rows, slow query etc... [RESOLVED]
  • From: Matteo Sgalaberni
• Re: increasing shared buffers: how much should be removed
  • From: Joshua D. Drake
• Re: increasing shared buffers: how much should be removed from OS filesystem cache?
  • From: Dave Cramer
• Re: increasing shared buffers: how much should be removed from OS filesystem cache?
  • From: Dave Cramer
• Re: database bloat,non removovable rows, slow query
  • From: Scott Marlowe
• Re: increasing shared buffers: how much should be removed from OS filesystem cache?
  • From: Merlin Moncure
• Re: database bloat,non removovable rows, slow query etc...
  • From: Tom Lane
• Re: database bloat,non removovable rows, slow query etc...
  • From: Matteo Sgalaberni
• increasing shared buffers: how much should be removed from OS filesystem cache?
  • From: Guillaume Cottenceau
• Re: database bloat,non removovable rows, slow query etc...
  • From: Markus Schaber
• Re: database bloat,non removovable rows, slow query etc...
  • From: Patrick Hatcher
• Re: database bloat,non removovable rows, slow query etc...
  • From: Tom Lane
• database bloat,non removovable rows, slow query etc...
  • From: Matteo Sgalaberni
• Re: performance problems.
  • From: Vivek Khera
• Re: performance problems.
  • From: Tom Lane
• Re: performance problems.
  • From: Dave Cramer
• Re: High concurrency OLTP database performance tuning
  • From: Casey Duncan
• Re: performance problems.
  • From: Vivek Khera
• Re: High concurrency OLTP database performance tuning
  • From: Dave Cramer
• Re: Postgress memory leak with JBoss3.2.6 and large DB
  • From: Dave Cramer
• Re: performance problems.
  • From: Vivek Khera
• Re: Postgress memory leak with JBoss3.2.6 and large DB
  • From: Tom Lane
• Re: High concurrency OLTP database performance tuning
  • From: Merlin Moncure
• Re: High concurrency OLTP database performance tuning
  • From: Michael Loftis
• Postgress memory leak with JBoss3.2.6 and large DB
  • From: Indika Maligaspe
• Re: High concurrency OLTP database performance tuning
  • From: Guillaume Smet
• High concurrency OLTP database performance tuning
  • From: Cosimo Streppone
• Re: performance problems.
  • From: Dave Cramer
• Re: performance problems.
  • From: Mark Kirkwood
• Re: performance problems.
  • From: Matthew Sullivan
• Re: slow i/o
  • From: Junaili Lie
• Re: performance problems.
  • From: Alex Hayward
• Re: slow i/o
  • From: Jignesh K. Shah
• Re: PostgreSQL performance issues
  • From: Alan Hodgson
• Re: performance problems.
  • From: Jim C. Nasby
• Re: PostgreSQL performance issues
  • From: Merlin Moncure
• Re: PostgreSQL performance issues
  • From: Willo van der Merwe
• Re: performance problems.
  • From: Vivek Khera
• Re: PostgreSQL performance issues
  • From: Dave Dutcher
• Re: PostgreSQL performance issues
  • From: Willo van der Merwe
• Re: PostgreSQL performance issues
  • From: Dave Cramer
• Re: PostgreSQL performance issues
  • From: Willo van der Merwe
• Re: PostgreSQL performance issues
  • From: Willo van der Merwe
• Re: PostgreSQL performance issues
  • From: Alex Hayward
• Re: PostgreSQL performance issues
  • From: Luke Lonergan
• Re: PostgreSQL performance issues
  • From: Willo van der Merwe
• Re: PostgreSQL performance issues
  • From: Willo van der Merwe
• Re: PostgreSQL performance issues
  • From: Luke Lonergan
• performance problems.
  • From: Matthew Sullivan
• Re: PostgreSQL performance issues
  • From: Willo van der Merwe
• Re: PostgreSQL performance issues
  • From: Merlin Moncure
• Re: PostgreSQL performance issues
  • From: Codelogic
• Re: PostgreSQL performance issues
  • From: Rusty Conover
• Re: slow i/o
  • From: Junaili Lie
• Re: PostgreSQL performance issues
  • From: A. Kretschmer
• Re: PostgreSQL performance issues
  • From: PFC
• Re: slow i/o
  • From: Jignesh K. Shah
• Re: PostgreSQL performance issues
  • From: Willo van der Merwe
• Re: slow i/o
  • From: Jignesh K. Shah
• Re: PostgreSQL performance issues
  • From: Joshua D. Drake
• Re: PostgreSQL performance issues
  • From: A. Kretschmer
• PostgreSQL performance issues
  • From: Willo van der Merwe
• Re: Internal Operations on LIMIT & OFFSET clause
  • From: A. Kretschmer
• Internal Operations on LIMIT & OFFSET clause
  • From: Vanitha Jaya
• Re: Identifying bloated tables
  • From: Peter Childs
• slow i/o
  • From: Junaili Lie
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Merlin Moncure
• Re: perf pb solved only after pg_dump and restore
  • From: Scott Marlowe
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Christopher Browne
• Re: Benchmarks
  • From: Scott Marlowe
• Re: Identifying bloated tables
  • From: Michal Taborsky - Internet Mall
• Re: Identifying bloated tables
  • From: Markus Schaber
• Re: Identifying bloated tables
  • From: Alvaro Herrera
• Re: Identifying bloated tables
  • From: Michal Taborsky - Internet Mall
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Tom Lane
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Joshua D. Drake
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Scott Marlowe
• Re: Identifying bloated tables
  • From: Brad Nicholson
• Identifying bloated tables
  • From: Michal Taborsky - Internet Mall
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Christopher Browne
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Alvaro Herrera
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: A. Kretschmer
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Christopher Browne
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Ravindran G - TLS, Chennai.
• Re: perf pb solved only after pg_dump and restore
  • From: Guillaume Cottenceau
• Re: perf pb solved only after pg_dump and restore
  • From: Markus Schaber
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Alvaro Herrera
• Re: perf pb solved only after pg_dump and restore
  • From: Markus Schaber
• Re: perf pb solved only after pg_dump and restore
  • From: Guillaume Cottenceau
• Re: perf pb solved only after pg_dump and restore
  • From: Guillaume Cottenceau
• Re: perf pb solved only after pg_dump and restore
  • From: Markus Schaber
• Re: perf pb solved only after pg_dump and restore
  • From: Guillaume Smet
• Re: perf pb solved only after pg_dump and restore
  • From: Guillaume Cottenceau
• Re: perf pb solved only after pg_dump and restore
  • From: Markus Schaber
• perf pb solved only after pg_dump and restore
  • From: Guillaume Cottenceau
• Re: Postgre SQL 7.1 cygwin performance issue.
  • From: Ravindran G - TLS, Chennai.
• Re: Related to Inserting into the database from XML file
  • From: soni de
• Re: Benchmarks
  • From: Merlin Moncure
• Re: [8.1.4] Help optimizing query
  • From: George Pavlov
• Re: stats reset during pg_restore?
  • From: Alvaro Herrera
• Re: stats reset during pg_restore?
  • From: George Pavlov
• Re: Related to Inserting into the database from XML file
  • From: George Pavlov
• Re: stats reset during pg_restore?
  • From: Alvaro Herrera
• [8.1.4] Help optimizing query
  • From: Hayes
• stats reset during pg_restore?
  • From: George Pavlov
• Re: Changing max_connections without restart ?
  • From: Tom Lane
• Changing max_connections without restart ?
  • From: Jean Arnaud
• Re: Related to Inserting into the database from XML file
  • From: Jeff Davis
• Related to Inserting into the database from XML file
  • From: soni de
• Re: select max(column) from parent table very slow
  • From: Joshua D. Drake
• Re: select max(column) from parent table very slow
  • From: Alvaro Herrera
• Re: select max(column) from parent table very slow
  • From: Joshua D. Drake
• Re: select max(column) from parent table very slow
  • From: Tom Lane
• Re: select max(column) from parent table very slow
  • From: Joshua D. Drake
• select max(column) from parent table very slow
  • From: Sriram Dandapani
• adtx
  • From: Merlin Moncure
• Re: PowerEdge 2950 questions
  • From: Merlin Moncure
• Re: PowerEdge 2950 questions
  • From: Scott Marlowe
• Re: PowerEdge 2950 questions
  • From: Merlin Moncure
• Re: PowerEdge 2950 questions
  • From: Bucky Jordan
• Re: PowerEdge 2950 questions
  • From: Scott Marlowe
• Re: PowerEdge 2950 questions
  • From: Mark Lewis
• Re: PowerEdge 2950 questions
  • From: Claus Guttesen
• Re: PowerEdge 2950 questions
  • From: Merlin Moncure
• Re: PowerEdge 2950 questions
  • From: Jeff Davis
• Re: Which benchmark to use for testing FS?
  • From: Jeff Davis
• Re: Is this way of testing a bad idea?
  • From: Bucky Jordan
• Re: Is this way of testing a bad idea?
  • From: Mark Lewis
• Re: PowerEdge 2950 questions
  • From: Merlin Moncure
• Re: Is this way of testing a bad idea?
  • From: Tom Lane
• Is this way of testing a bad idea?
  • From: Fredrik Israelsson
• Re: Query tuning
  • From: Subbiah, Stalin
• Re: Forcing index usage without 'enable_hashjoin = FALSE'
  • From: Dan Langille
• Re: Forcing index usage without 'enable_hashjoin = FALSE'
  • From: Tom Lane
• Re: Forcing index usage without 'enable_hashjoin = FALSE'
  • From: Dan Langille
• Re: Which benchmark to use for testing FS?
  • From: Michael Stone
• Re: Query tuning
  • From: Dave Dutcher
• Which benchmark to use for testing FS?
  • From: Jeff Davis
• Re: Query tuning
  • From: Subbiah, Stalin
• Re: VACUUM FULL needed sometimes to prevent transaction
  • From: Heikki Linnakangas
• Re: VACUUM FULL needed sometimes to prevent transaction
  • From: Markus Schaber
• Re: Forcing index usage without 'enable_hashjoin = FALSE'
  • From: Chris
• Re: Query tuning
  • From: Chris
• Re: Query tuning
  • From: Subbiah, Stalin
• Re: Moving a tablespace
  • From: Tom Lane
• Re: Query tuning
  • From: Chris
• Re: Moving a tablespace
  • From: Michael Fuhr
• Moving a tablespace
  • From: Craig A. James
• Query tuning
  • From: Subbiah, Stalin
• Re: PowerEdge 2950 questions
  • From: Jeff Davis
• Re: VACUUM FULL needed sometimes to prevent transaction
  • From: Jeff Davis
• Re: PowerEdge 2950 questions
  • From: Bucky Jordan
• PowerEdge 2950 questions
  • From: Jeff Davis
• Re: query planner: automatic rescribe of LIKE to BETWEEN ?
  • From: Tom Lane