Postgres Performance Date Index

• Thread Index

• Re: Inner join vs where-clause subquery
  • From: Jeremy Haile
• Re: Inner join vs where-clause subquery
  • From: Jeremy Haile
• Re: Inner join vs where-clause subquery
  • From: Richard Huxton
• Re: Inner join vs where-clause subquery
  • From: Jeremy Haile
• Re: Inner join vs where-clause subquery
  • From: Richard Huxton
• Re: Inner join vs where-clause subquery
  • From: Jeremy Haile
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: Inner join vs where-clause subquery
  • From: Richard Huxton
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Inner join vs where-clause subquery
  • From: Jeremy Haile
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Tom Lane
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Simon Riggs
• Re: Advice on selecting good values for work_mem?
  • From: Bill Moran
• Re: Advice on selecting good values for work_mem?
  • From: Bill Moran
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: opportunity to benchmark a quad core Xeon
  • From: Jeff Frost
• Re: Query plan changing when queried data does not
  • From: Tom Lane
• Query plan changing when queried data does not
  • From: Harry Hehl
• Re: transaction ID wrap limit
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• transaction ID wrap limit
  • From: Sabin Coanda
• Re: Optimizing timestamp queries? Inefficient Overlaps?
  • From: Tom Lane
• Optimizing timestamp queries? Inefficient Overlaps?
  • From: Adam Rich
• Re: Scaling concerns
  • From: Tom Lane
• Re: Scaling concerns
  • From: tsuraan
• Re: Scaling concerns
  • From: Greg Smith
• Re: Scaling concerns
  • From: tsuraan
• Re: Scaling concerns
  • From: tsuraan
• Re: Scaling concerns
  • From: Bill Moran
• Re: File Systems Compared
  • From: Bruno Wolff III
• Re: Scaling concerns
  • From: Luke Lonergan
• Re: Scaling concerns
  • From: Andreas Kostyrka
• Re: Scaling concerns
  • From: Dimitri Fontaine
• Re: partition text/varchar check problem
  • From: Tom Lane
• Re: partition text/varchar check problem
  • From: jamcito
• Re: partition text/varchar check problem
  • From: Ireneusz Pluta
• Re: partition text/varchar check problem -- solved
  • From: jamcito
• Re: Scaling concerns
  • From: tsuraan
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: Scaling concerns
  • From: Steinar H. Gunderson
• Scaling concerns
  • From: tsuraan
• Re: New to PostgreSQL, performance considerations
  • From: Steinar H. Gunderson
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: partition text/varchar check problem
  • From: Tom Lane
• partition text/varchar check problem
  • From: jamcito
• Re: New to PostgreSQL, performance considerations
  • From: Cosimo Streppone
• Re: opportunity to benchmark a quad core Xeon
  • From: Arjen van der Meijden
• opportunity to benchmark a quad core Xeon
  • From: Jeff Frost
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Alexander Staubo
• Re: File Systems Compared
  • From: Bruno Wolff III
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Ron
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: File Systems Compared
  • From: Bruno Wolff III
• Re: File Systems Compared
  • From: Bruno Wolff III
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Gregory Stark
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Merlin Moncure
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Martijn van Oosterhout
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Greg Smith
• Re: New to PostgreSQL, performance considerations
  • From: Merlin Moncure
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Florian Weimer
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Martijn van Oosterhout
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Martijn van Oosterhout
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Simon Riggs
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Dimitri Fontaine
• Re: [HACKERS] EXPLAIN ANALYZE on 8.2
  • From: Martijn van Oosterhout
• Re: EXPLAIN ANALYZE on 8.2
  • From: Simon Riggs
• Re: New to PostgreSQL, performance considerations
  • From: Steinar H. Gunderson
• Re: New to PostgreSQL, performance considerations
  • From: Alexander Staubo
• Re: New to PostgreSQL, performance considerations
  • From: Greg Smith
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: New to PostgreSQL, performance considerations
  • From: Alexander Staubo
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: EXPLAIN ANALYZE on 8.2
  • From: Tom Lane
• Re: EXPLAIN ANALYZE on 8.2
  • From: Mark Kirkwood
• Re: EXPLAIN ANALYZE on 8.2
  • From: Kelly Burkhart
• Re: New to PostgreSQL, performance considerations
  • From: Alexander Staubo
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: File Systems Compared
  • From: Ron Mayer
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: strange query behavior
  • From: Tim Jones
• Re: New to PostgreSQL, performance considerations
  • From: Alexander Staubo
• Re: strange query behavior
  • From: Tom Lane
• Re: strange query behavior
  • From: Tom Lane
• Re: File Systems Compared
  • From: Bruno Wolff III
• unsubscribe
  • From: Rohit Prakash Khare
• Re: Slow update with simple query
  • From: Tom Lane
• Re: EXPLAIN ANALYZE on 8.2
  • From: Tom Lane
• Re: Slow update with simple query
  • From: Mark Lewis
• Re: EXPLAIN ANALYZE on 8.2
  • From: Evgeny Gridasov
• Re: Slow update with simple query
  • From: Arnaud Lesauvage
• Re: Slow update with simple query
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Matthew O'Connor
• Re: EXPLAIN ANALYZE on 8.2
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Greg Smith
• Re: Slow update with simple query
  • From: Arnaud Lesauvage
• Re: Slow update with simple query
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Greg Smith
• EXPLAIN ANALYZE on 8.2
  • From: Evgeny Gridasov
• Re: strange query behavior
  • From: Tim Jones
• Re: Slow update with simple query
  • From: Arnaud Lesauvage
• Re: New to PostgreSQL, performance considerations
  • From: Gregory S. Williamson
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: File Systems Compared
  • From: Jim Nasby
• Re: New to PostgreSQL, performance considerations
  • From: Michael Glaesemann
• Re: New to PostgreSQL, performance considerations
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Joshua D. Drake
• Re: New to PostgreSQL, performance considerations
  • From: Josh Berkus
• Re: New to PostgreSQL, performance considerations
  • From: Rajesh Kumar Mallah
• Re: New to PostgreSQL, performance considerations
  • From: Bruce Momjian
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: strange query behavior
  • From: Tom Lane
• Re: Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: Optimizing a query
  • From: Tomeh, Husam
• Re: strange query behavior
  • From: Tim Jones
• Re: strange query behavior
  • From: Tim Jones
• Re: strange query behavior
  • From: Tom Lane
• Re: Optimizing a query
  • From: James Cloos
• Re: strange query behavior
  • From: Tim Jones
• Re: strange query behavior
  • From: Tom Lane
• Re: Optimizing a query
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Guido Neitzer
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: strange query behavior
  • From: Tim Jones
• Re: Optimizing a query
  • From: Tomeh, Husam
• Optimizing a query
  • From: James Cloos
• Re: strange query behavior
  • From: Tom Lane
• Re: strange query behavior
  • From: Ragnar
• strange query behavior
  • From: Tim Jones
• Re: New to PostgreSQL, performance considerations
  • From: Bucky Jordan
• Re: Slow update with simple query
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: Slow update with simple query
  • From: Mark Lewis
• Re: Insertion to temp table deteriorating over time
  • From: Tom Lane
• Re: Insertion to temp table deteriorating over time
  • From: Rajesh Kumar Mallah
• Re: Slow update with simple query
  • From: Arnaud Lesauvage
• Re: Slow update with simple query
  • From: Tom Lane
• Insertion to temp table deteriorating over time
  • From: Steven Flatt
• Re: Slow update with simple query
  • From: asif ali
• Re: New to PostgreSQL, performance considerations
  • From: Cosimo Streppone
• Re: Slow update with simple query
  • From: Arnaud Lesauvage
• Re: Slow update with simple query
  • From: Ragnar
• Re: Slow update with simple query
  • From: Arnaud Lesauvage
• Re: Slow update with simple query
  • From: Jens Schipkowski
• Re: Slow update with simple query
  • From: Arnaud Lesauvage
• Re: Slow update with simple query
  • From: Jens Schipkowski
• Re: Slow update with simple query
  • From: Arnaud Lesauvage
• Re: Slow update with simple query
  • From: Ragnar
• Slow update with simple query
  • From: Arnaud Lesauvage
• Re: New to PostgreSQL, performance considerations
  • From: Sven Geisler
• Re: New to PostgreSQL, performance considerations
  • From: Christopher Browne
• Re: New to PostgreSQL, performance considerations
  • From: Greg Smith
• Re: New to PostgreSQL, performance considerations
  • From: Bucky Jordan
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: New to PostgreSQL, performance considerations
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: Low throughput of binary inserts from windows to linux
  • From: David Boreham
• Re: New to PostgreSQL, performance considerations
  • From: Greg Smith
• Re: Low throughput of binary inserts from windows to linux
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Alvaro Herrera
• Re: New to PostgreSQL, performance considerations
  • From: Greg Smith
• Re: New to PostgreSQL, performance considerations
  • From: David Boreham
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Bill Moran
• Re: New to PostgreSQL, performance considerations
  • From: Florian Weimer
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: New to PostgreSQL, performance considerations
  • From: Alexander Staubo
• Re: New to PostgreSQL, performance considerations
  • From: Brad Nicholson
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Steinar H. Gunderson
• Re: New to PostgreSQL, performance considerations
  • From: Cosimo Streppone
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Alexander Staubo
• Re: New to PostgreSQL, performance considerations
  • From: Guido Neitzer
• Re: Low throughput of binary inserts from windows to linux
  • From: Axel Waggershauser
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: really quick multiple inserts can use COPY?
  • From: nicky
• Re: really quick multiple inserts can use COPY?
  • From: Jens Schipkowski
• Re: Low throughput of binary inserts from windows to linux
  • From: Florian Weimer
• Re: New to PostgreSQL, performance considerations
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Greg Smith
• Re: New to PostgreSQL, performance considerations
  • From: Christopher Browne
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: Low throughput of binary inserts from windows to linux
  • From: Tom Lane
• Re: Low throughput of binary inserts from windows to linux
  • From: Axel Waggershauser
• Re: New to PostgreSQL, performance considerations
  • From: Luke Lonergan
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Mark Kirkwood
• Re: New to PostgreSQL, performance considerations
  • From: Craig A. James
• Re: Looking for hw suggestions for high concurrency
  • From: Luke Lonergan
• Re: Looking for hw suggestions for high concurrency
  • From: Merlin Moncure
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Luke Lonergan
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: New to PostgreSQL, performance considerations
  • From: Merlin Moncure
• Re: really quick multiple inserts can use COPY?
  • From: imad
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: Looking for hw suggestions for high concurrency
  • From: Luke Lonergan
• Re: New to PostgreSQL, performance considerations
  • From: Luke Lonergan
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: File Systems Compared
  • From: Bruno Wolff III
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Ron
• Re: really quick multiple inserts can use COPY?
  • From: Guillaume Cottenceau
• Re: really quick multiple inserts can use COPY?
  • From: Tom Lane
• Re: really quick multiple inserts can use COPY?
  • From: Rajesh Kumar Mallah
• Re: really quick multiple inserts can use COPY?
  • From: Andreas Kretschmer
• really quick multiple inserts can use COPY?
  • From: Jens Schipkowski
• Looking for hw suggestions for high concurrency OLTP app
  • From: Cosimo Streppone
• Re: Low throughput of binary inserts from windows to
  • From: Kevin Grittner
• Re: Postgresql - Threshold value.
  • From: Tom Lane
• Re: New to PostgreSQL, performance considerations
  • From: Chris Browne
• Re: Low throughput of binary inserts from windows to linux
  • From: Tom Lane
• Re: Postgresql - Threshold value.
  • From: Rajesh Kumar Mallah
• Re: Low throughput of binary inserts from windows to linux
  • From: Axel Waggershauser
• Re: Low throughput of binary inserts from windows to linux
  • From: Thomas H.
• Re: Low throughput of binary inserts from windows to linux
  • From: Axel Waggershauser
• Re: New to PostgreSQL, performance considerations
  • From: Merlin Moncure
• Re: Postgresql - Threshold value.
  • From: Ravindran G - TLS, Chennai.
• Re: Postgresql - Threshold value.
  • From: A. Kretschmer
• Re: Postgresql - Threshold value.
  • From: Ravindran G - TLS, Chennai.
• Re: New to PostgreSQL, performance considerations
  • From: Steinar H. Gunderson
• Re: New to PostgreSQL, performance considerations
  • From: Steinar H. Gunderson
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Steinar H. Gunderson
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Christopher Browne
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Steinar H. Gunderson
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Dave Cramer
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can
  • From: Ragnar
• Re: Postgresql - Threshold value.
  • From: Kaloyan Iliev
• Re: New to PostgreSQL, performance considerations
  • From: Alexander Staubo
• Re: Postgresql - Threshold value.
  • From: Rajesh Kumar Mallah
• Re: New to PostgreSQL, performance considerations
  • From: Alexander Staubo
• Postgresql - Threshold value.
  • From: Ravindran G - TLS, Chennai.
• Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can
  • From: Andreas Kostyrka
• Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can
  • From: Chris
• Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can
  • From: Mark Kirkwood
• Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can
  • From: Tom Lane
• Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can
  • From: Chris
• Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can
  • From: Joshua D. Drake
• Re: New to PostgreSQL, performance considerations
  • From: Tatsuo Ishii
• Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can helpe
  • From: Chris
• Re: New to PostgreSQL, performance considerations
  • From: Alexander Staubo
• Re: New to PostgreSQL, performance considerations
  • From: Dave Cramer
• Re: New to PostgreSQL, performance considerations
  • From: Michael Stone
• Re: New to PostgreSQL, performance considerations
  • From: Michael Glaesemann
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Gene
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: New to PostgreSQL, performance considerations
  • From: Shane Ambler
• New to PostgreSQL, performance considerations
  • From: Daniel van Ham Colchete
• Re: Low throughput of binary inserts from windows to linux
  • From: Tom Lane
• Re: Low throughput of binary inserts from windows to linux
  • From: Axel Waggershauser
• Re: How to determine if my setting for shared_buffers is too high?
  • From: Jim C. Nasby
• Re: One table is very slow, but replicated table (same data) is fine
  • From: Chris Browne
• Re: Areca 1260 Performance
  • From: Ron
• Re: Disk storage and san questions (was File Systems Compared)
  • From: Bucky Jordan
• Re: File Systems Compared
  • From: Merlin Moncure
• Re: Advice on selecting good values for work_mem?
  • From: Stephen Frost
• Re: How to determine if my setting for shared_buffers is too high?
  • From: Tom Lane
• Re: Advice on selecting good values for work_mem?
  • From: Tom Lane
• How to determine if my setting for shared_buffers is too high?
  • From: Bill Moran
• Advice on selecting good values for work_mem?
  • From: Bill Moran
• Re: Areca 1260 Performance
  • From: Gene
• Re: Areca 1260 Performance
  • From: Shane Ambler
• Re: 8.2rc1 (much) slower than 8.2dev?
  • From: Tom Lane
• SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can helpe me.
  • From: Marcos Borges
• Re: Areca 1260 Performance
  • From: Ron
• Re: Core 2 or Opteron
  • From: Arjen van der Meijden
• Re: Core 2 or Opteron
  • From: Mindaugas
• Re: Core 2 or Opteron
  • From: Claus Guttesen
• Re: Core 2 or Opteron
  • From: Arjen van der Meijden
• Core 2 or Opteron
  • From: Mindaugas
• Re: 8.2rc1 (much) slower than 8.2dev?
  • From: Arjen van der Meijden
• Re: Areca 1260 Performance
  • From: Brian Wipf
• Re: VACUUM FULL does not works.......
  • From: Rajesh Kumar Mallah
• Re: File Systems Compared
  • From: Greg Smith
• Re: Configuration settings for 32GB RAM server
  • From: Jim C. Nasby
• Re: 8.2rc1 (much) slower than 8.2dev?
  • From: Jim C. Nasby
• Re: Areca 1260 Performance
  • From: Ron
• Re: VACUUM FULL does not works.......
  • From: asif ali
• Re: Areca 1260 Performance
  • From: Brian Wipf
• Re: Areca 1260 Performance (was: File Systems
  • From: Ron
• Re: Areca 1260 Performance (was: File Systems Compared)
  • From: Brian Wipf
• Re: VACUUM FULL does not works.......
  • From: Scott Marlowe
• Re: VACUUM FULL does not works.......
  • From: asif ali
• Re: File Systems Compared
  • From: Brian Wipf
• Re: File Systems Compared
  • From: Ron
• Disk storage and san questions (was File Systems Compared)
  • From: Matthew Schumacher
• Re: Problems with an update-from statement and pg-8.1.4
  • From: Erik Jones
• Re: File Systems Compared
  • From: Bruno Wolff III
• Re: Problems with an update-from statement and pg-8.1.4
  • From: Rafael Martinez
• Re: File Systems Compared
  • From: Brian Hurt
• Re: Problems with an update-from statement and pg-8.1.4
  • From: Erik Jones
• Re: File Systems Compared
  • From: Merlin Moncure
• Re: Problems with an update-from statement and pg-8.1.4
  • From: Rafael Martinez
• Re: VACUUM FULL does not works.......
  • From: Tom Lane
• Re: Problems with an update-from statement and pg-8.1.4
  • From: Ted Allen
• Re: Problems with an update-from statement and pg-8.1.4
  • From: Stephan Szabo
• Problems with an update-from statement and pg-8.1.4
  • From: Rafael Martinez
• Re: [offtopic] File Systems Compared
  • From: Brian Wipf
• Re: VACUUM FULL does not works.......
  • From: asif ali
• Re: File Systems Compared
  • From: Michael Stone
• Re: Locking in PostgreSQL?
  • From: Erik Jones
• [offtopic] Word wrapping
  • From: Steinar H. Gunderson
• Re: File Systems Compared
  • From: Arnaud Lesauvage
• Re: Locking in PostgreSQL?
  • From: Casey Duncan
• Re: VACUUM FULL does not works.......
  • From: Rajesh Kumar Mallah
• Re: File Systems Compared
  • From: Markus Schiltknecht
• Re: File Systems Compared
  • From: Luke Lonergan
• Re: VACUUM FULL does not works.......
  • From: Scott Marlowe
• Re: VACUUM FULL does not works.......
  • From: Jean-Max Reymond
• VACUUM FULL does not works.......
  • From: asif ali
• Re: File Systems Compared
  • From: Mark Lewis
• Re: File Systems Compared
  • From: Florian Weimer
• Re: File Systems Compared
  • From: Steinar H. Gunderson
• Re: File Systems Compared
  • From: Brian Hurt
• Re: File Systems Compared
  • From: Joshua D. Drake
• Re: File Systems Compared
  • From: Markus Schiltknecht
• Re: File Systems Compared
  • From: Luke Lonergan
• Re: Bad iostat numbers
  • From: Steve Atkins
• Re: File Systems Compared
  • From: Alexander Staubo
• Re: File Systems Compared
  • From: Brian Hurt
• File Systems Compared
  • From: Brian Wipf
• Re: [GENERAL] Locking in PostgreSQL?
  • From: Martijn van Oosterhout
• Re: [GENERAL] Locking in PostgreSQL?
  • From: Markus Schiltknecht
• Re: Locking in PostgreSQL?
  • From: Steinar H. Gunderson
• Re: Locking in PostgreSQL?
  • From: Dave Cramer
• Re: Locking in PostgreSQL?
  • From: Jens Schipkowski
• Re: Locking in PostgreSQL?
  • From: Dave Cramer
• Re: Hardware advice
  • From: Gregory S. Williamson
• Re: Hardware advice
  • From: Sven Geisler
• Re: Restart time
  • From: Jean Arnaud
• Locking in PostgreSQL?
  • From: Joost Kraaijeveld
• Re: Restart time
  • From: Rajesh Kumar Mallah
• Re: Bad iostat numbers
  • From: Greg Smith
• Re: Hardware advice
  • From: Alex Turner
• Re: max/min and index usage
  • From: Tobias Brox
• Re: max/min and index usage
  • From: Tom Lane
• Re: max/min and index usage
  • From: Tobias Brox
• max/min and index usage
  • From: Tobias Brox
• Re: shared_buffers > 284263 on OS X
  • From: Brian Wipf
• Re: shared_buffers > 284263 on OS X
  • From: Tom Lane
• Re: shared_buffers > 284263 on OS X
  • From: Brian Wipf
• Re: Hardware advice
  • From: Alexandru Coseru
• Re: Performance of ORDER BY
  • From: Glenn Sullivan
• Re: single transaction vs multiple transactions
  • From: Jens Schipkowski
• Re: Performance of ORDER BY
  • From: Stefan Kaltenbrunner
• Re: Restart time
  • From: Tom Lane
• Re: Restart time
  • From: Rajesh Kumar Mallah
• Re: Performance of ORDER BY
  • From: Tom Lane
• Re: Performance of ORDER BY
  • From: A. Kretschmer
• Re: Performance of ORDER BY
  • From: Steinar H. Gunderson
• Re: Restart time
  • From: Tom Lane
• Re: Performance of ORDER BY
  • From: Tom Lane
• Restart time
  • From: Jean Arnaud
• Re: Performance of ORDER BY
  • From: Luke Lonergan
• Performance of ORDER BY
  • From: Glenn Sullivan
• Re: single transaction vs multiple transactions
  • From: Tom Lane
• Re: single transaction vs multiple transactions
  • From: Sven Geisler
• Re: single transaction vs multiple transactions
  • From: Heikki Linnakangas
• Re: single transaction vs multiple transactions
  • From: Sven Geisler
• Re: single transaction vs multiple transactions
  • From: Heikki Linnakangas
• single transaction vs multiple transactions
  • From: Sven Geisler
• Re: Bad iostat numbers
  • From: Michael Stone
• Re: Bad iostat numbers
  • From: Craig A. James
• Re: Bad iostat numbers
  • From: Alex Turner
• Re: Bad iostat numbers
  • From: Michael Stone
• Re: Configuration settings for 32GB RAM server
  • From: Mark Lonsdale
• Re: Hardware advice
  • From: Sven Geisler
• Re: JOIN work somehow strange on simple query
  • From: Anton
• JOIN work somehow strange on simple query
  • From: Anton
• Re: Bad iostat numbers
  • From: Alex Turner
• Re: Is Vacuum/analyze destroying my performance?
  • From: Matthew T. O'Connor
• Re: How to move pg_xlog to another drive on
  • From: K C Lau
• Re: Bad iostat numbers
  • From: Greg Smith
• pgsql upgrade
  • From: Matt Chambers
• Re: Configuration settings for 32GB RAM server
  • From: Dave Cramer
• Re: How to move pg_xlog to another drive on Windows????
  • From: Anthony Presley
• Re: Configuration settings for 32GB RAM server
  • From: Scott Marlowe
• Re: How to move pg_xlog to another drive on Windows????
  • From: Merlin Moncure
• Re: Configuration settings for 32GB RAM server
  • From: Joshua Marsh
• Re: Configuration settings for 32GB RAM server
  • From: Vivek Khera
• Re: Bad iostat numbers
  • From: Scott Marlowe
• Re: Bad iostat numbers
  • From: Scott Marlowe
• Re: Bad iostat numbers
  • From: Michael Stone
• Re: Bad iostat numbers
  • From: Alex Turner
• How to move pg_xlog to another drive on Windows????
  • From: Joost Kraaijeveld
• Re: Bad iostat numbers
  • From: Michael Stone
• Re: Configuration settings for 32GB RAM server
  • From: Jeff Davis
• Re: Bad iostat numbers
  • From: Alex Turner
• Configuration settings for 32GB RAM server
  • From: Mark Lonsdale
• Re: Is Vacuum/analyze destroying my performance?
  • From: Carlo Stonebanks
• Re: 8.2rc1 (much) slower than 8.2dev?
  • From: Arjen van der Meijden
• Re: Bad iostat numbers
  • From: Scott Marlowe
• Re: Bad iostat numbers
  • From: Scott Marlowe
• Re: 8.2rc1 (much) slower than 8.2dev?
  • From: Tom Lane
• Re: Is Vacuum/analyze destroying my performance?
  • From: Matthew O'Connor
• 8.2rc1 (much) slower than 8.2dev?
  • From: Arjen van der Meijden
• Re: Bad iostat numbers
  • From: Alex Turner
• Re: Bad iostat numbers
  • From: Greg Smith
• Re: Is Vacuum/analyze destroying my performance?
  • From: Carlo Stonebanks
• Is Vacuum/analyze destroying my performance?
  • From: Carlo Stonebanks
• Re: Enabling constraint_exclusion does not avoid scanning all child partitions
  • From: Fayza Sultan
• Re: Enabling constraint_exclusion does not avoid scanning all child partitions
  • From: Tom Lane
• Enabling constraint_exclusion does not avoid scanning all child partitions
  • From: Fayza Sultan
• Re: Hardware advice
  • From: Alexandru Coseru
• Re: Hardware advice
  • From: Josh Berkus
• Re: Propagating outer join conditions
  • From: Tom Lane
• Hardware advice
  • From: Alexandru Coseru
• Re: Propagating outer join conditions
  • From: Aaron Birkland
• Re: Propagating outer join conditions
  • From: Jonathan Blitz
• Propagating outer join conditions
  • From: Aaron Birkland
• Re: Regex performance issue
  • From: Alexandru Coseru
• Re: Which query analiser tools are available?
  • From: Andreas Kretschmer
• Which query analiser tools are available?
  • From: Joost Kraaijeveld
• Re: Regex performance issue
  • From: Oleg Bartunov
• Re: Regex performance issue
  • From: Tom Lane
• Re: Regex performance issue
  • From: Scott Marlowe
• Re: Regex performance issue
  • From: Alexandru Coseru
• Re: Regex performance issue
  • From: Alexandru Coseru
• Re: Regex performance issue
  • From: Heikki Linnakangas
• Re: Regex performance issue
  • From: Alexandru Coseru
• Re: Regex performance issue
  • From: Heikki Linnakangas
• Re: Regex performance issue
  • From: Oleg Bartunov
• Re: Regex performance issue
  • From: Alexandru Coseru
• Re: Regex performance issue
  • From: Dave Dutcher
• Regex performance issue
  • From: Alexandru Coseru
• Re: Dump performance problems following server crash
  • From: Kim
• Re: Dump performance problems following server crash
  • From: Tom Lane
• Dump performance problems following server crash
  • From: Kim
• Re: Performance of Perc 5i
  • From: Bucky Jordan
• Performance of Perc 5i
  • From: Alex Turner
• Re: RES: Bad iostat numbers
  • From: David Boreham
• Re: NAMEDATALEN and performance
  • From: Tom Lane
• RES: Bad iostat numbers
  • From: Carlos H. Reimer
• RES: Bad iostat numbers
  • From: Carlos H. Reimer
• Re: Defining performance.
  • From: Heikki Linnakangas
• Re: NAMEDATALEN and performance
  • From: Alessandro Baretta
• Re: Defining performance.
  • From: Tobias Brox
• Re: Defining performance.
  • From: Chris
• Re: Bad iostat numbers
  • From: Mark Kirkwood
• Re: Bad iostat numbers
  • From: David Boreham
• Re: Bad iostat numbers
  • From: Mark Kirkwood
• Re: Defining performance.
  • From: Tobias Brox
• Re: Defining performance.
  • From: nospam
• Re: Defining performance.
  • From: Tobias Brox
• Re: Defining performance.
  • From: Jeff Davis
• Bad iostat numbers
  • From: Carlos H. Reimer
• Re: Defining performance.
  • From: Scott Marlowe
• Re: Defining performance.
  • From: Tom Lane
• Re: Defining performance.
  • From: Tobias Brox
• Defining performance.
  • From: Paul Lathrop
• Re: RES: Priority to a mission critical transaction
  • From: Josh Berkus
• Re: Fw: [GENERAL] Including unique users in huge data
  • From: Luke Lonergan
• Fw: [GENERAL] Including unique users in huge data warehouse in Postgresql...
  • From: Mark Jensen
• Re: RES: Priority to a mission critical transaction
  • From: Ron Mayer
• OT - how to size/match multiple databases/apps for a single server
  • From: Kevin Kempter
• Re: RES: Priority to a mission critical transaction
  • From: Brian Hurt
• Re: RES: Priority to a mission critical transaction
  • From: Ron Mayer
• Re: NAMEDATALEN and performance
  • From: Tom Lane
• Re: RES: Priority to a mission critical transaction
  • From: Brian Hurt
• Re: RES: Priority to a mission critical transaction
  • From: Mark Lewis
• Re: RES: Priority to a mission critical transaction
  • From: Brian Hurt
• NAMEDATALEN and performance
  • From: Alessandro Baretta
• Re: RES: Priority to a mission critical transaction
  • From: Ron Mayer
• Re: RES: Priority to a mission critical transaction
  • From: Mark Kirkwood
• Re: RES: Priority to a mission critical transaction
  • From: Mark Kirkwood
• Re: RES: Priority to a mission critical transaction
  • From: Ron Mayer
• Re: RES: Priority to a mission critical transaction
  • From: Bruce Momjian
• Re: RES: Priority to a mission critical transaction
  • From: Ron Mayer
• Re: RES: Priority to a mission critical transaction
  • From: Josh Berkus
• Re: RES: Priority to a mission critical transaction
  • From: Andreas Kostyrka
• Re: RES: Priority to a mission critical transaction
  • From: Tom Lane
• RES: Priority to a mission critical transaction
  • From: Carlos H. Reimer
• Re: Postgres scalability and performance on windows
  • From: J. Andrew Rogers
• Re: Postgres scalability and performance on windows
  • From: Tom Lane
• Re: Postgres scalability and performance on windows
  • From: Gopal
• Re: BUG #2784: Performance serious degrades over a period
  • From: Bill Moran
• Re: BUG #2784: Performance serious degrades over a period of a month
  • From: Bruno Wolff III
• Re: When to vacuum a table?
  • From: Kevin Grittner
• Re: Postgres server crash
  • From: Florian Weimer
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: AgentM
• Re: Postgres server crash
  • From: Michael Stone
• Re: shared_buffers > 284263 on OS X
  • From: Jim C. Nasby
• Re: Massive delete of rows, how to proceed?
  • From: Merlin Moncure
• Plattform comparison (lies, damn lies and benchmarks)
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Brian Wipf
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Brian Wipf
• Re: shared_buffers > 284263 on OS X
  • From: Tom Lane
• Re: shared_buffers > 284263 on OS X
  • From: Brendan Duddridge
• Re: When to vacuum a table?
  • From: Jim C. Nasby
• Re: Priority to a mission critical transaction
  • From: Jim C. Nasby
• Re: Postgres server crash
  • From: Jim C. Nasby
• Re: availability of SATA vendors
  • From: Jim C. Nasby
• Re: availability of SATA vendors
  • From: Jim C. Nasby
• Re: shared_buffers > 284263 on OS X
  • From: Jim C. Nasby
• Re: When to vacuum a table?
  • From: Joshua D. Drake
• Re: When to vacuum a table?
  • From: Tom Lane
• Re: When to vacuum a table?
  • From: Craig A. James
• Re: When to vacuum a table?
  • From: Andrew Sullivan
• Re: When to vacuum a table?
  • From: Rod Taylor
• Re: When to vacuum a table?
  • From: Marcelo Costa
• Re: When to vacuum a table?
  • From: Steinar H. Gunderson
• Re: When to vacuum a table?
  • From: Marcelo Costa
• When to vacuum a table?
  • From: Joost Kraaijeveld
• Re: Massive delete of rows, how to proceed?
  • From: andrew
• Massive delete of rows, how to proceed?
  • From: Peter Childs
• Re: Postgres scalability and performance on windows
  • From: Tom Lane
• Massive delete of rows, how to proceed?
  • From: Arnau
• Re: Postgres scalability and performance on windows
  • From: Frank Wiles
• Re: TPC-H Benchmark
  • From: Luke Lonergan
• TPC-H Benchmark
  • From: Felipe Rondon Rocha
• Re: Postgres scalability and performance on windows
  • From: Gopal
• Re: Postgres scalability and performance on windows
  • From: Guido Neitzer
• Re: Direct I/O issues
  • From: Bruce Momjian
• Re: Postgres scalability and performance on windows
  • From: Heikki Linnakangas
• Postgres scalability and performance on windows
  • From: Gopal
• Re: Priority to a mission critical transaction
  • From: Brad Nicholson
• Re: Direct I/O issues
  • From: Greg Smith
• Re: Direct I/O issues
  • From: Tom Lane
• Re: Lying drives [Was: Re: Which OS provides the
  • From: Bruce Momjian
• Re: PostgreSQL underestimates sorting
  • From: Simon Riggs
• Re: availability of SATA vendors
  • From: Arjen van der Meijden
• Re: Lying drives [Was: Re: Which OS provides the _fastest_
  • From: Greg Smith
• Direct I/O issues
  • From: Greg Smith
• Re: availability of SATA vendors
  • From: Luke Lonergan
• Re: availability of SATA vendors
  • From: Bucky Jordan
• Re: availability of SATA vendors
  • From: Scott Marlowe
• Re: PostgreSQL underestimates sorting
  • From: Frank Wiles
• Re: availability of SATA vendors
  • From: Joshua D. Drake
• Re: availability of SATA vendors
  • From: Arjen van der Meijden
• Re: availability of SATA vendors
  • From: Jeff Frost
• Re: availability of SATA vendors
  • From: Joshua D. Drake
• Re: PostgreSQL underestimates sorting
  • From: Markus Schaber
• Re: availability of SATA vendors
  • From: Jeff Frost
• Re: PostgreSQL underestimates sorting
  • From: Markus Schaber
• Re: availability of SATA vendors
  • From: Bucky Jordan
• Re: PostgreSQL underestimates sorting
  • From: Steinar H. Gunderson
• PostgreSQL underestimates sorting
  • From: Markus Schaber
• Re: availability of SATA vendors
  • From: Joshua D. Drake
• Re: availability of SATA vendors
  • From: Jeff Frost
• Re: availability of SATA vendors
  • From: Joshua D. Drake
• Priority to a mission critical transaction
  • From: Carlos H. Reimer
• Re: availability of SATA vendors
  • From: Jeff Frost
• Re: Slow Query
  • From: Joe Lester
• Slow Query
  • From: Joe Lester
• Re: BitMapScan performance degradation
  • From: Jérôme BENOIS
• Re: BitMapScan performance degradation
  • From: db
• Re: BitMapScan performance degradation
  • From: Tom Lane
• RES: Context switching
  • From: Carlos H. Reimer
• BitMapScan performance degradation
  • From: Jérôme BENOIS
• Re: Postgres server crash
  • From: Markus Schaber
• Re: Postgres server crash
  • From: Mattias Kregert
• Re: Postgres server crash
  • From: Craig A. James
• Re: Postgres server crash
  • From: Bruno Wolff III
• Re: Postgres server crash
  • From: Craig A. James
• Re: Postgres server crash
  • From: Michael Stone
• PostgreSQL with 64 bit was: Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: Postgres server crash
  • From: Craig A. James
• Re: Postgres server crash
  • From: Michael Stone
• Re: Postgres server crash
  • From: Richard Broersma Jr
• Re: Postgres server crash
  • From: Michael Stone
• Re: Postgres server crash
  • From: Ron Mayer
• Re: Postgres server crash
  • From: Ron Mayer
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: Postgres server crash
  • From: Tom Lane
• Re: Postgres server crash
  • From: Craig A. James
• Fwd: start up cost estimate
  • From: rakesh kumar
• Re: shared_buffers > 284263 on OS X
  • From: Brian Wipf
• Re: Postgres server crash
  • From: Richard Troy
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Guido Neitzer
• Re: shared_buffers > 284263 on OS X
  • From: Tom Lane
• Re: start up cost estimate
  • From: Tom Lane
• Re: shared_buffers > 284263 on OS X
  • From: Dave Cramer
• Re: start up cost estimate
  • From: Joshua Marsh
• Re: Optimicing Postgres for SunSolaris10 on V240
  • From: Marc Cousin
• start up cost estimate
  • From: rakesh kumar
• Re: availability of SATA vendors
  • From: Luke Lonergan
• Re: availability of SATA vendors
  • From: Steve Atkins
• Re: availability of SATA vendors
  • From: Ron
• Re: availability of SATA vendors
  • From: Arjen van der Meijden
• Re: Optimicing Postgres for SunSolaris10 on V240
  • From: Josh Berkus
• availability of SATA vendors
  • From: Jeff Frost
• Re: [BUGS] BUG #2737: hash indexing large tablefails,while
  • From: Julius.Stroffek
• Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works
  • From: Tom Lane
• Re: [BUGS] BUG #2737: hash indexing largetablefails,while btree of same index works
  • From: Simon Riggs
• Re: Keeping processes open for re-use
  • From: Richard Huxton
• Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works
  • From: Simon Riggs
• shared_buffers > 284263 on OS X
  • From: Brian Wipf
• Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works
  • From: Tom Lane
• Re: Context switch storm
  • From: Jim Nasby
• Re: Postgres server crash
  • From: Ben
• Re: Postgres server crash
  • From: Merlin Moncure
• Re: Postgres server crash
  • From: Richard Huxton
• Re: Postgres server crash
  • From: Tom Lane
• Re: Postgres server crash
  • From: Tom Lane
• Re: Keeping processes open for re-use
  • From: Jean-Max Reymond
• Re: Postgres server crash
  • From: Richard Huxton
• Re: Postgres server crash
  • From: Craig A. James
• Re: Postgres server crash
  • From: Richard Huxton
• Re: Postgres server crash
  • From: Craig A. James
• Re: Postgres server crash
  • From: Richard Huxton
• Re: Slow SELECT on three or more clients
  • From: AMIR FRANCO D. JOVEN
• Re: Postgres server crash
  • From: Russell Smith
• Postgres server crash
  • From: Craig A. James
• Re: Hundreds of database and FSM
  • From: Steinar H. Gunderson
• Re: Hundreds of database and FSM
  • From: Alvaro Herrera
• Hundreds of database and FSM
  • From: Craig A. James
• Re: Slow SELECT on three or more clients
  • From: Markus Schaber
• Re: Slow SELECT on three or more clients
  • From: Merlin Moncure
• Re: Slow SELECT on three or more clients
  • From: Gregory S. Williamson
• Re: Slow SELECT on three or more clients
  • From: Russell Smith
• Re: Slow SELECT on three or more clients
  • From: Andreas Kostyrka
• Slow SELECT on three or more clients
  • From: AMIR FRANCO D. JOVEN
• Re: Context switch storm
  • From: Simon Riggs
• Re: Context switch storm
  • From: Cosimo Streppone
• Re: Context switch storm
  • From: Merlin Moncure
• Re: Context switch storm
  • From: Bucky Jordan