Postgres Performance Date Index

• Thread Index

• Re: how to improve the performance of creating index
  • From: Heikki Linnakangas
• Re: how to improve the performance of creating index
  • From: Chris Browne
• Re: how to improve the performance of creating index
  • From: Heikki Linnakangas
• how to improve the performance of creating index
  • From: Yinan Li
• Re: How to improve speed of 3 table join &group (HUGE tables)
  • From: ismo . tuononen
• Re: Incorrect estimates on columns
  • From: Chris Kratz
• Re: How to improve speed of 3 table join &group (HUGE tables)
  • From: John Major
• Re: How to improve speed of 3 table join &group (HUGE tables)
  • From: John Major
• Re: How to improve speed of 3 table join &group (HUGE tables)
  • From: Heikki Linnakangas
• Re: How to improve speed of 3 table join &group (HUGE tables)
  • From: Nis Jørgensen
• How to improve speed of 3 table join &group (HUGE tables)
  • From: John Major
• Re: Incorrect estimates on columns
  • From: Nis Jørgensen
• Re: Vacuum goes worse
  • From: Stéphane Schildknecht
• Re: Vacuum goes worse
  • From: Stéphane Schildknecht
• Re: two queryes in a single tablescan
  • From: 李彦 Ian Li
• Re: Shared Buffer setting in postgresql.conf
  • From: Ow Mun Heng
• Re: Incorrect estimates on columns
  • From: Tom Lane
• Re: Huge amount of memory consumed during transaction
  • From: Tom Lane
• Re: Huge amount of memory consumed during transaction
  • From: Alvaro Herrera
• Re: Incorrect estimates on columns
  • From: Chris Kratz
• Re: Incorrect estimates on columns
  • From: Tom Lane
• Re: Vacuum goes worse
  • From: Scott Marlowe
• Incorrect estimates on columns
  • From: Chris Kratz
• Re: Vacuum goes worse
  • From: Alvaro Herrera
• Re: Vacuum goes worse
  • From: Tom Lane
• Re: Vacuum goes worse
  • From: Tom Lane
• Re: Vacuum goes worse
  • From: Stefano Dal Pra
• Re: Vacuum goes worse
  • From: Alvaro Herrera
• Re: two queryes in a single tablescan
  • From: Heikki Linnakangas
• Re: two queryes in a single tablescan
  • From: Stefano Dal Pra
• Re: two queryes in a single tablescan
  • From: Steinar H. Gunderson
• Re: two queryes in a single tablescan
  • From: Heikki Linnakangas
• two queryes in a single tablescan
  • From: Stefano Dal Pra
• Re: Vacuum goes worse
  • From: Stéphane Schildknecht
• Re: using a stored proc that returns a result set in a complex SQL stmt
  • From: Marcin Stępnicki
• Re: Vacuum goes worse
  • From: Joshua D. Drake
• Re: Vacuum goes worse
  • From: Tom Lane
• Re: Vacuum goes worse
  • From: Brian Herlihy
• Re: Vacuum goes worse
  • From: Tom Lane
• Re: Autovacuum running out of memory
  • From: 李彦 Ian Li
• Re: Vacuum goes worse
  • From: Scott Marlowe
• Re: Autovacuum running out of memory
  • From: Tom Lane
• Re: Vacuum goes worse
  • From: Tom Lane
• Re: Vacuum goes worse
  • From: Stéphane Schildknecht
• Re: using a stored proc that returns a result set in a complex SQL stmt
  • From: Heikki Linnakangas
• using a stored proc that returns a result set in a complex SQL stmt
  • From: chrisj
• Re: Autovacuum running out of memory
  • From: Tom Lane
• Re: Autovacuum running out of memory
  • From: Rodrigo Gonzalez
• Re: Autovacuum running out of memory
  • From: Jason Lustig
• Re: Autovacuum running out of memory
  • From: Mark Lewis
• Re: Vacuum goes worse
  • From: Tom Lane
• Re: Autovacuum running out of memory
  • From: Richard Huxton
• Re: Autovacuum running out of memory
  • From: Scott Marlowe
• Re: Autovacuum running out of memory
  • From: Jason Lustig
• Re: Autovacuum running out of memory
  • From: Scott Marlowe
• Re: Autovacuum running out of memory
  • From: Richard Huxton
• Re: Autovacuum running out of memory
  • From: Jason Lustig
• Re: Autovacuum running out of memory
  • From: Richard Huxton
• Re: Autovacuum running out of memory
  • From: Jason Lustig
• Re: Autovacuum running out of memory
  • From: Richard Huxton
• Autovacuum running out of memory
  • From: Jason Lustig
• Re: Vacuum goes worse
  • From: Stéphane Schildknecht
• Re: Vacuum goes worse
  • From: Heikki Linnakangas
• Vacuum goes worse
  • From: Stéphane Schildknecht
• Re: How to speed up min/max(id) in 50M rows table?
  • From: henk de wit
• Re: How to speed up min/max(id) in 50M rows table?
  • From: henk de wit
• Re: How to speed up min/max(id) in 50M rows table?
  • From: Tom Lane
• Re: How to speed up min/max(id) in 50M rows table?
  • From: henk de wit
• Re: How to speed up min/max(id) in 50M rows table?
  • From: Tom Lane
• Re: Huge amount of memory consumed during transaction
  • From: Erik Jones
• Re: How to speed up min/max(id) in 50M rows table?
  • From: Alan Hodgson
• Re: How to speed up min/max(id) in 50M rows table?
  • From: Tom Lane
• Re: Huge amount of memory consumed during transaction
  • From: henk de wit
• Re: How to speed up min/max(id) in 50M rows table?
  • From: henk de wit
• Re: Huge amount of memory consumed during transaction
  • From: Erik Jones
• Re: How to speed up min/max(id) in 50M rows table?
  • From: henk de wit
• Re: Huge amount of memory consumed during transaction
  • From: henk de wit
• Re: How to speed up min/max(id) in 50M rows table?
  • From: henk de wit
• Re: How to speed up min/max(id) in 50M rows table?
  • From: Kevin Grittner
• How to speed up min/max(id) in 50M rows table?
  • From: henk de wit
• Re: Huge amount of memory consumed during transaction
  • From: Tom Lane
• Re: Performance problems with prepared statements
  • From: Kevin Grittner
• Re: Performance problems with prepared statements
  • From: Theo Kramer
• Re: Performance problems with prepared statements
  • From: Merlin Moncure
• Re: Performance problems with prepared statements
  • From: Richard Huxton
• Re: Performance problems with prepared statements
  • From: Theo Kramer
• Re: Performance problems with prepared statements
  • From: Theo Kramer
• Re: Performance problems with prepared statements
  • From: Theo Kramer
• Re: Huge amount of memory consumed during transaction
  • From: Tom Lane
• Re: Huge amount of memory consumed during transaction
  • From: henk de wit
• Re: Huge amount of memory consumed during transaction
  • From: henk de wit
• Re: Performance problems with prepared statements
  • From: Merlin Moncure
• Re: Performance problems with prepared statements
  • From: Andrew - Supernews
• Re: Huge amount of memory consumed during transaction
  • From: Tom Lane
• Re: Performance problems with prepared statements
  • From: Merlin Moncure
• Re: Huge amount of memory consumed during transaction
  • From: Erik Jones
• Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
  • From: Benjamin Arai
• Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
  • From: Tom Lane
• Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
  • From: Benjamin Arai
• Re: Huge amount of memory consumed during transaction
  • From: Tom Lane
• Re: Huge amount of memory consumed during transaction
  • From: Scott Marlowe
• Re: Huge amount of memory consumed during transaction
  • From: Richard Huxton
• Huge amount of memory consumed during transaction
  • From: henk de wit
• Re: Performance problems with prepared statements
  • From: Theo Kramer
• Re: Performance problems with prepared statements
  • From: Richard Huxton
• Re: building a performance test suite
  • From: Dimitri Fontaine
• Re: Performance problems with prepared statements
  • From: Cédric Villemain
• Re: Query taking too long. Problem reading explain output.
  • From: Ow Mun Heng
• Re: building a performance test suite
  • From: Greg Smith
• Re: Shared Buffer setting in postgresql.conf
  • From: Scott Marlowe
• Re: Shared Buffer setting in postgresql.conf
  • From: Radhika S
• building a performance test suite
  • From: Kevin Kempter
• Re: hashjoin chosen over 1000x faster plan
  • From: Kevin Grittner
• Re: hashjoin chosen over 1000x faster plan
  • From: Tom Lane
• Re: hashjoin chosen over 1000x faster plan
  • From: Kevin Grittner
• Re: Shared Buffer setting in postgresql.conf
  • From: Scott Marlowe
• Re: hashjoin chosen over 1000x faster plan
  • From: Kevin Grittner
• Re: hashjoin chosen over 1000x faster plan
  • From: Tom Lane
• Re: Shared Buffer setting in postgresql.conf
  • From: Josh Trutwin
• Re: hashjoin chosen over 1000x faster plan
  • From: Kevin Grittner
• Re: Performance problems with prepared statements
  • From: Theo Kramer
• Re: Performance problems with prepared statements
  • From: Jonah H. Harris
• Re: hashjoin chosen over 1000x faster plan
  • From: Simon Riggs
• Re: hashjoin chosen over 1000x faster plan
  • From: Kevin Grittner
• Re: Performance problems with prepared statements
  • From: Theo Kramer
• Re: hashjoin chosen over 1000x faster plan
  • From: Simon Riggs
• Re: hashjoin chosen over 1000x faster plan
  • From: Simon Riggs
• Re: hashjoin chosen over 1000x faster plan
  • From: Kevin Grittner
• Re: hashjoin chosen over 1000x faster plan
  • From: Tom Lane
• Re: SQL Monitoring
  • From: Josh Trutwin
• Re: hashjoin chosen over 1000x faster plan
  • From: Simon Riggs
• Re: Shared Buffer setting in postgresql.conf
  • From: Scott Marlowe
• Re: Performance problems with prepared statements
  • From: Cédric Villemain
• Re: SQL Monitoring
  • From: Rodrigo De León
• Performance problems with prepared statements
  • From: Theo Kramer
• Re: hashjoin chosen over 1000x faster plan
  • From: Kevin Grittner
• Re: SQL Monitoring
  • From: Tomáš Vondra
• Re: hashjoin chosen over 1000x faster plan
  • From: Simon Riggs
• Re: Shared Buffer setting in postgresql.conf
  • From: Marcin Stępnicki
• Re: Postgres running Very slowly
  • From: Bill Moran
• Shared Buffer setting in postgresql.conf
  • From: Radhika S
• hashjoin chosen over 1000x faster plan
  • From: Kevin Grittner
• Postgres running Very slowly
  • From: Radhika S
• Re: SQL Monitoring
  • From: Gregory Stark
• Re: SQL Monitoring
  • From: Heikki Linnakangas
• Re: SQL Monitoring
  • From: Marcin Stępnicki
• SQL Monitoring
  • From: Campbell, Lance
• Re: Apache2 PostgreSQL http authentication
  • From: Magnus Hagander
• Re: Apache2 PostgreSQL http authentication
  • From: Tino Wildenhain
• Re: postgresql on NFS.. recommended? not recommended?
  • From: Josh Tolley
• postgresql on NFS.. recommended? not recommended?
  • From: Gábor Farkas
• Re: Apache2 PostgreSQL http authentication
  • From: Magnus Hagander
• Re: Apache2 PostgreSQL http authentication
  • From: Jeffrey Brower
• Re: Apache2 PostgreSQL http authentication
  • From: Jeffrey Brower
• Re: Apache2 PostgreSQL http authentication
  • From: D'Arcy J.M. Cain
• Re: Apache2 PostgreSQL http authentication
  • From: Jeffrey Brower
• Re: Apache2 PostgreSQL http authentication
  • From: Jeffrey Brower
• Re: query plan worse after analyze
  • From: Richard Broersma Jr
• Re: Apache2 PostgreSQL http authentication
  • From: A.M.
• Apache2 PostgreSQL http authentication
  • From: Jeffrey Brower
• Re: query plan worse after analyze
  • From: Alvaro Herrera
• Re: query plan worse after analyze
  • From: Jeff Frost
• Re: query plan worse after analyze
  • From: Tom Lane
• Re: query plan worse after analyze
  • From: Jeff Frost
• Re: query plan worse after analyze
  • From: Rodrigo De León
• Re: query plan worse after analyze
  • From: Stephen Frost
• query plan worse after analyze
  • From: Jeff Frost
• Re: Problems with + 1 million record table
  • From: Shane Ambler
• Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
  • From: Benjamin Arai
• Re: Problems with + 1 million record table
  • From: Joshua D. Drake
• Re: Problems with + 1 million record table
  • From: Arjen van der Meijden
• Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
  • From: Oleg Bartunov
• Re: [GENERAL] Slow TSearch2 performance for table with 1 million documents.
  • From: Tom Lane
• Re: Problems with + 1 million record table
  • From: Scott Marlowe
• Problems with + 1 million record table
  • From: Cláudia Macedo Amorim
• Slow TSearch2 performance for table with 1 million documents.
  • From: Benjamin Arai
• Re: Partitioning in postgres - basic question
  • From: Chris
• Re: Query taking too long. Problem reading explain output.
  • From: Alvaro Herrera
• Re: quickly getting the top N rows
  • From: Ben
• Re: Query taking too long. Problem reading explain output.
  • From: Henrik
• Re: quickly getting the top N rows
  • From: Tom Lane
• Re: quickly getting the top N rows
  • From: Richard Huxton
• Re: quickly getting the top N rows
  • From: Scott Marlowe
• Re: quickly getting the top N rows
  • From: Ben
• Re: quickly getting the top N rows
  • From: Scott Marlowe
• Re: quickly getting the top N rows
  • From: Simon Riggs
• Re: quickly getting the top N rows
  • From: Ben
• Re: Tuning Help - What did I do wrong?
  • From: Josh Trutwin
• Re: Tuning Help - What did I do wrong?
  • From: Kevin Grittner
• Re: quickly getting the top N rows
  • From: Tom Lane
• Re: quickly getting the top N rows
  • From: Ben
• Re: quickly getting the top N rows
  • From: Andreas Kretschmer
• Re: quickly getting the top N rows
  • From: Bill Moran
• Re: quickly getting the top N rows
  • From: Mark Lewis
• quickly getting the top N rows
  • From: Ben
• Partitioning in postgres - basic question
  • From: Tore Lukashaugen
• Re: Tuning Help - What did I do wrong?
  • From: Scott Marlowe
• Re: Tuning Help - What did I do wrong?
  • From: Josh Trutwin
• Re: Tuning Help - What did I do wrong?
  • From: Scott Marlowe
• Re: Tuning Help - What did I do wrong?
  • From: Scott Marlowe
• Tuning Help - What did I do wrong?
  • From: Josh Trutwin
• Re: Query taking too long. Problem reading explain output.
  • From: Alvaro Herrera
• Re: can't shrink relation
  • From: Guillaume Cottenceau
• Re: can't shrink relation
  • From: Richard Huxton
• Re: Query taking too long. Problem reading explain output.
  • From: Henrik
• can't shrink relation
  • From: Sabin Coanda
• Re: can't shrink relation
  • From: Sabin Coanda
• Re: Query taking too long. Problem reading explain output.
  • From: Tom Lane
• Re: Query taking too long. Problem reading explain output.
  • From: Michael Fuhr
• Query taking too long. Problem reading explain output.
  • From: Henrik
• Re: Newbie question about degraded performance on delete statement. (SOLVED)
  • From: Giulio Cesare Solaroli
• Re: Newbie question about degraded performance on delete statement.
  • From: Giulio Cesare Solaroli
• Re: Difference between Vacuum and Vacuum full
  • From: Radhika S
• Re: Difference between Vacuum and Vacuum full
  • From: D'Arcy J.M. Cain
• Re: Difference between Vacuum and Vacuum full
  • From: Rodrigo De León
• Re: Difference between Vacuum and Vacuum full
  • From: Scott Marlowe
• Difference between Vacuum and Vacuum full
  • From: Radhika S
• Re: Newbie question about degraded performance on delete statement.
  • From: Greg Williamson
• Re: performance of like queries
  • From: Chris Browne
• Re: Linux mis-reporting memory
  • From: Decibel!
• Re: Newbie question about degraded performance on delete statement.
  • From: Dan Langille
• Newbie question about degraded performance on delete statement.
  • From: Giulio Cesare Solaroli
• Re: performance of like queries
  • From: Marcin Stępnicki
• Re: performance of like queries
  • From: Joshua D. Drake
• performance of like queries
  • From: Kevin Kempter
• Re: Linux mis-reporting memory
  • From: Adam Tauno Williams
• Re: Linux mis-reporting memory
  • From: Scott Marlowe
• Re: Linux mis-reporting memory
  • From: Decibel!
• Re: sequence query performance issues
  • From: Peter Koczan
• Re: Non-blocking vacuum full
  • From: Heikki Linnakangas
• Re: Non-blocking vacuum full
  • From: Ron Mayer
• Re: OOM Errors as a result of table inheritance and a bad plan(?)
  • From: Tom Lane
• Re: Non-blocking vacuum full
  • From: Heikki Linnakangas
• Non-blocking vacuum full
  • From: Peter Schuller
• OOM Errors as a result of table inheritance and a bad plan(?)
  • From: Arctic Toucan
• Re: sequence query performance issues
  • From: Peter Koczan
• Re: Postgres 7.4.2 hanging when vacuum full is run
  • From: Scott Marlowe
• Re: Postgres 7.4.2 hanging when vacuum full is run
  • From: Vivek Khera
• Re: sequence query performance issues
  • From: Richard Huxton
• Postgres 7.4.2 hanging when vacuum full is run
  • From: Radhika S
• Re: sequence query performance issues
  • From: Tom Lane
• Re: Tuning for warm standby
  • From: Merlin Moncure
• Re: Searching for the cause of a bad plan
  • From: Csaba Nagy
• Re: Searching for the cause of a bad plan
  • From: Csaba Nagy
• Re: sequence query performance issues
  • From: Richard Huxton
• sequence query performance issues
  • From: Peter Koczan
• Re: Searching for the cause of a bad plan
  • From: Ron Mayer
• Tuning for warm standby
  • From: Kevin Kempter
• Re: Searching for the cause of a bad plan
  • From: Simon Riggs
• Re: Searching for the cause of a bad plan
  • From: Csaba Nagy
• Re: Searching for the cause of a bad plan
  • From: Tom Lane
• Re: Difference in query plan when using = or > in where clause
  • From: Heikki Linnakangas
• Re: Searching for the cause of a bad plan
  • From: Csaba Nagy
• Re: REPOST: Nested loops row estimates always too high
  • From: Ow Mun Heng
• Difference in query plan when using = or > in where clause
  • From: Radhika S
• Re: Incorrect row estimates in plan?
  • From: pgdba
• Re: Incorrect row estimates in plan?
  • From: Tom Lane
• Re: Incorrect row estimates in plan?
  • From: pgdba
• Re: Searching for the cause of a bad plan
  • From: Tom Lane
• Re: Searching for the cause of a bad plan
  • From: Csaba Nagy
• Re: Incorrect row estimates in plan?
  • From: Tom Lane
• Incorrect row estimates in plan?
  • From: pgdba
• Re: Effects of cascading references in foreign keys
  • From: Bruce Momjian
• Re: REPOST: Nested loops row estimates always too high
  • From: Tom Lane
• Re: REPOST: Nested loops row estimates always too high
  • From: Ow Mun Heng
• Re: query io stats and finding a slow query
  • From: Bryan Murphy
• Re: query io stats and finding a slow query
  • From: Kamen Stanev
• Re: Attempting to disable count triggers on cleanup
  • From: Dave Cramer
• Re: Attempting to disable count triggers on cleanup
  • From: hubert depesz lubaczewski
• Attempting to disable count triggers on cleanup
  • From: Dave Cramer
• Re: REPOST: Nested loops row estimates always too high
  • From: Steinar H. Gunderson
• Re: REPOST: Nested loops row estimates always too high
  • From: Ow Mun Heng
• Re: REPOST: Nested loops row estimates always too high
  • From: Carlo Stonebanks
• Re: REPOST: Nested loops row estimates always too high
  • From: Ow Mun Heng
• Re: Acceptable level of over-estimation?
  • From: Gregory Stark
• Acceptable level of over-estimation?
  • From: Carlo Stonebanks
• Re: REPOST: Nested loops row estimates always too high
  • From: Carlo Stonebanks
• Re: Searching for the cause of a bad plan
  • From: Simon Riggs
• Re: TEXT or LONGTEXT?
  • From: Niklas Johansson
• Re: select count(*) performance (vacuum did not help)
  • From: Dave Dutcher
• Re: select count(*) performance (vacuum did not help)
  • From: Csaba Nagy
• Re: TEXT or LONGTEXT?
  • From: Alexander Staubo
• Re: select count(*) performance (vacuum did not help)
  • From: Bill Moran
• TEXT or LONGTEXT?
  • From: Fabiola Fernández
• Re: select count(*) performance (vacuum did not help)
  • From: Gábor Farkas
• Re: select count(*) performance (vacuum did not help)
  • From: Heikki Linnakangas
• Re: select count(*) performance (vacuum did not help)
  • From: Gábor Farkas
• Re: select count(*) performance (vacuum did not help)
  • From: Heikki Linnakangas
• Re: select count(*) performance (vacuum did not help)
  • From: Pavan Deolasee
• Re: Low CPU Usage
  • From: brauagustin-susc
• select count(*) performance (vacuum did not help)
  • From: Gábor Farkas
• Re: Searching for the cause of a bad plan
  • From: Csaba Nagy
• Re: Low CPU Usage
  • From: brauagustin-susc
• Re: Searching for the cause of a bad plan
  • From: Simon Riggs
• [OT] Re: [Again] Postgres performance problem
  • From: Ow Mun Heng
• Re: REPOST: Nested loops row estimates always too high
  • From: Ow Mun Heng
• Re: Possible explanations for catastrophic performance deterioration?
  • From: Gregory Stark
• Re: Possible explanations for catastrophic performance deterioration?
  • From: Jonah H. Harris
• Re: Possible explanations for catastrophic performance deterioration?
  • From: Carlos Moreno
• Re: Possible explanations for catastrophic performance deterioration?
  • From: Alvaro Herrera
• Re: Possible explanations for catastrophic performance deterioration?
  • From: Carlos Moreno
• Re: Possible explanations for catastrophic performace deterioration?
  • From: Jonah H. Harris
• Re: Possible explanations for catastrophic performace deterioration?
  • From: Carlos Moreno
• Re: Possible explanations for catastrophic performace deterioration?
  • From: Alvaro Herrera
• Re: Possible explanations for catastrophic performace deterioration?
  • From: Carlos Moreno
• Re: Possible explanations for catastrophic performace deterioration?
  • From: Tom Lane
• zero value in statistics collector's result
  • From: Yinan Li
• Re: Possible explanations for catastrophic performace deterioration?
  • From: Jonah H. Harris
• Possible explanations for catastrophic performace deterioration?
  • From: Carlos Moreno
• Re: Query planner unaware of possibly best plan
  • From: Denes Daniel
• Re: Low CPU Usage
  • From: Greg Smith
• Re: Query planner unaware of possibly best plan
  • From: Tom Lane
• Re: Query planner unaware of possibly best plan
  • From: Denes Daniel
• Re: Searching for the cause of a bad plan
  • From: Tom Lane
• Re: Low CPU Usage
  • From: brauagustin-susc
• Re: Low CPU Usage
  • From: Craig James
• Re: Low CPU Usage
  • From: Kevin Grittner
• Re: Low CPU Usage
  • From: Dave Dutcher
• Re: Low CPU Usage
  • From: Luiz K. Matsumura
• Re: Query planner unaware of possibly best plan
  • From: Denes Daniel
• Re: Query planner unaware of possibly best plan
  • From: Alvaro Herrera
• Re: Low CPU Usage
  • From: brauagustin-susc
• Re: Query planner unaware of possibly best plan
  • From: Denes Daniel
• Re: Linux mis-reporting memory
  • From: Greg Smith
• Re: Low CPU Usage
  • From: Bill Moran
• Re: Low CPU Usage
  • From: brauagustin-susc
• Re: Searching for the cause of a bad plan
  • From: Simon Riggs
• Re: Low CPU Usage
  • From: Bill Moran
• Re: Low CPU Usage
  • From: brauagustin-susc
• Re: Searching for the cause of a bad plan
  • From: Tom Lane
• Re: Low CPU Usage
  • From: brauagustin-susc
• Re: Low CPU Usage
  • From: Kevin Grittner
• Re: Query planner unaware of possibly best plan
  • From: Simon Riggs
• Re: Searching for the cause of a bad plan
  • From: Simon Riggs
• Re: Low CPU Usage
  • From: brauagustin-susc
• Re: Searching for the cause of a bad plan
  • From: Simon Riggs
• Re: query io stats and finding a slow query
  • From: Kevin Grittner
• Re: Searching for the cause of a bad plan
  • From: Tom Lane
• Re: Searching for the cause of a bad plan
  • From: Csaba Nagy
• Query planner unaware of possibly best plan
  • From: Denes Daniel
• Re: Searching for the cause of a bad plan
  • From: Csaba Nagy
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: Dave Dutcher
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: Jeff Harris
• Re: Searching for the cause of a bad plan
  • From: Simon Riggs
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: Bill Moran
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: smiley2211
• Re: Searching for the cause of a bad plan
  • From: Csaba Nagy
• Re: Searching for the cause of a bad plan
  • From: Simon Riggs
• Re: Linux mis-reporting memory
  • From: Csaba Nagy
• Re: Searching for the cause of a bad plan
  • From: Csaba Nagy
• Re: Linux mis-reporting memory
  • From: Simon Riggs
• Re: Searching for the cause of a bad plan
  • From: Simon Riggs
• Re: Linux mis-reporting memory
  • From: Heikki Linnakangas
• Re: Linux mis-reporting memory
  • From: Csaba Nagy
• Searching for the cause of a bad plan
  • From: Csaba Nagy
• Re: Linux mis-reporting memory
  • From: Gregory Stark
• Re: Linux mis-reporting memory
  • From: Dimitri Fontaine
• Re: Linux mis-reporting memory
  • From: Csaba Nagy
• Re: Linux mis-reporting memory
  • From: Gregory Stark
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: db
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: smiley2211
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: Scott Marlowe
• Re: Linux mis-reporting memory
  • From: Adam Tauno Williams
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: smiley2211
• Re: Linux mis-reporting memory
  • From: Tom Lane
• Linux mis-reporting memory
  • From: Decibel!
• query io stats and finding a slow query
  • From: Kamen Stanev
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: Scott Marlowe
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: Scott Marlowe
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: smiley2211
• Re: Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: Carlos Moreno
• Re: Tablespaces and NFS
  • From: Carlos Moreno
• Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!
  • From: smiley2211
• Re: Tablespaces and NFS
  • From: Peter Koczan
• Re: Low CPU Usage
  • From: brauagustin-susc
• REPOST: Performance improves only after repeated VACUUM/ANALYZE
  • From: Carlo Stonebanks
• REPOST: Nested loops row estimates always too high
  • From: Carlo Stonebanks
• Re: Tablespaces and NFS
  • From: Carlos Moreno
• Re: Low CPU Usage
  • From: Jean-David Beyer
• Re: Low CPU Usage
  • From: brauagustin-susc
• Re: Tablespaces and NFS
  • From: Peter Koczan
• Re: Tablespaces and NFS
  • From: Craig James
• Re: Low CPU Usage
  • From: Scott Marlowe
• Re: Low CPU Usage
  • From: brauagustin-susc
• Re: Low CPU Usage
  • From: Scott Marlowe
• Re: Low CPU Usage
  • From: brauagustin-susc
• Re: Low CPU Usage
  • From: Mark Lewis
• Re: Low CPU Usage
  • From: Heikki Linnakangas
• Low CPU Usage
  • From: brauagustin-susc
• Tablespaces and NFS
  • From: Carlos Moreno
• Re: R: R: DELETE queries slow down
  • From: Gregory Williamson
• Re: R: R: DELETE queries slow down
  • From: Bill Moran
• R: R: DELETE queries slow down
  • From: Galantucci Giovanni
• Nested loops row estimates always too high
  • From: Carlo Stonebanks
• Performance improves only after repeated VACUUM/ANALYZE
  • From: Carlo Stonebanks
• Re: R: DELETE queries slow down
  • From: Bill Moran
• Re: Query works when kludged, but would prefer "best practice" solution
  • From: Dave Dutcher
• Re: Regarding COPY command from Postgres 8.2.0
  • From: Scott Marlowe
• Re: Regarding COPY command from Postgres 8.2.0
  • From: Evan Carroll
• Re: Query works when kludged, but would prefer "best practice" solution
  • From: Tom Lane
• Re: Index usage when bitwise operator is used
  • From: valgog
• R: DELETE queries slow down
  • From: Galantucci Giovanni
• Re: Query works when kludged, but would prefer "best practice" solution
  • From: Carlo Stonebanks
• Re: Regarding COPY command from Postgres 8.2.0
  • From: soni de
• Re: Query works when kludged, but would prefer "best practice" solution
  • From: Tom Lane
• Re: Query works when kludged, but would prefer "best practice" solution
  • From: Carlo Stonebanks
• Re: Query works when kludged, but would prefer "best practice" solution
  • From: Merlin Moncure
• Re: Query works when kludged, but would prefer "best practice" solution
  • From: Carlo Stonebanks
• Re: Query works when kludged, but would prefer "best practice" solution
  • From: Merlin Moncure
• Query works when kludged, but would prefer "best practice" solution
  • From: Carlo Stonebanks
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Markus Schiltknecht
• Re: Index usage when bitwise operator is used
  • From: W.Alphonse HAROUNY
• Re: Index usage when bitwise operator is used
  • From: Kevin Grittner
• Re: Index usage when bitwise operator is used
  • From: Tom Lane
• Re: [Again] Postgres performance problem
  • From: Decibel!
• Re: Index usage when bitwise operator is used
  • From: Kevin Grittner
• Re: [Again] Postgres performance problem
  • From: Decibel!
• Re: [Again] Postgres performance problem
  • From: Ruben Rubio
• Re: DELETE queries slow down
  • From: Gregory Stark
• Re: DELETE queries slow down
  • From: Heikki Linnakangas
• DELETE queries slow down
  • From: Galantucci Giovanni
• Re: Index usage when bitwise operator is used
  • From: valgog
• Re: Index usage when bitwise operator is used
  • From: valgog
• Re: Index usage when bitwise operator is used
  • From: Kevin Grittner
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Kevin Grittner
• Re: Index usage when bitwise operator is used
  • From: Valentine Gogichashvili
• Re: Index files
  • From: Alan Hodgson
• Re: Index files
  • From: Mark Lewis
• Re: Index files
  • From: Harsh Azad
• Re: Long Running Commits - Not Checkpoints
  • From: Greg Smith
• Re: [Again] Postgres performance problem
  • From: Adam Tauno Williams
• Re: Index files
  • From: Jean-David Beyer
• Re: Regarding COPY command from Postgres 8.2.0
  • From: Ansgar -59cobalt- Wiechers
• Re: Long Running Commits - Not Checkpoints
  • From: db
• Regarding COPY command from Postgres 8.2.0
  • From: soni de
• Re: Index files
  • From: Philippe Amelant
• Re: Long Running Commits - Not Checkpoints
  • From: Peter Childs
• Re: [Again] Postgres performance problem
  • From: Greg Smith
• Re: Long Running Commits - Not Checkpoints
  • From: Peter Childs
• Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
  • From: Ow Mun Heng
• Re: Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
  • From: El-Lotso
• Re: When/if to Reindex
  • From: Bruce Momjian
• Re: Index files
  • From: Tom Lane
• Re: Index files
  • From: Ow Mun Heng
• Re: Index files
  • From: Harsh Azad
• Re: Index files
  • From: Ow Mun Heng
• Index files
  • From: Harsh Azad
• Re: Long Running Commits - Not Checkpoints
  • From: Greg Smith
• Re: SAN vs Internal Disks
  • From: Michael Stone
• Re: Long Running Commits - Not Checkpoints
  • From: Brad Nicholson
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Gregory Stark
• Re: Long Running Commits - Not Checkpoints
  • From: Alvaro Herrera
• Re: Long Running Commits - Not Checkpoints
  • From: Brad Nicholson
• Re: [Again] Postgres performance problem
  • From: Scott Marlowe
• Re: Long Running Commits - Not Checkpoints
  • From: Brad Nicholson
• Re: Long Running Commits - Not Checkpoints
  • From: Greg Smith
• Re: [Again] Postgres performance problem
  • From: Erik Jones
• Re: Long Running Commits - Not Checkpoints
  • From: Brad Nicholson
• Re: [Again] Postgres performance problem
  • From: Gavin M. Roy
• Re: Long Running Commits - Not Checkpoints
  • From: Tom Lane
• Re: Clustered tables improves perfs ?
  • From: Chris Browne
• Re: Long Running Commits - Not Checkpoints
  • From: Brad Nicholson
• Re: [Again] Postgres performance problem
  • From: Scott Marlowe
• Long Running Commits - Not Checkpoints
  • From: Brad Nicholson
• Re: Clustered tables improves perfs ?
  • From: Alexander Staubo
• Clustered tables improves perfs ?
  • From: Patrice Castet
• Index usage when bitwise operator is used
  • From: W.Alphonse HAROUNY
• Re: [Again] Postgres performance problem
  • From: El-Lotso
• Re: [Again] Postgres performance problem
  • From: Greg Smith
• Re: pg_dump blocking create database?
  • From: Tom Lane
• Re: db performance/design question
  • From: Scott Marlowe
• db performance/design question
  • From: Matt Chambers
• Re: [Again] Postgres performance problem
  • From: Erik Jones
• pg_dump blocking create database?
  • From: Dan Harris
• Re: [Again] Postgres performance problem
  • From: Alvaro Herrera
• Re: [Again] Postgres performance problem
  • From: Scott Marlowe
• Re: [Again] Postgres performance problem
  • From: Frank Schoep
• Re: [Again] Postgres performance problem
  • From: Scott Marlowe
• Re: [Again] Postgres performance problem
  • From: Mikko Partio
• Re: [Again] Postgres performance problem
  • From: Brian Hurt
• Re: [Again] Postgres performance problem
  • From: Scott Marlowe
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Rafael Barrera Oro
• Re: Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
  • From: Tom Lane
• Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
  • From: Nis Jørgensen
• Re: Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
  • From: El-Lotso
• Re: [Again] Postgres performance problem
  • From: ruben
• Re: Hardware spec
  • From: Claus Guttesen
• Re: Hardware spec
  • From: Willo van der Merwe
• Re: SAN vs Internal Disks
  • From: Tobias Brox
• Re: SAN vs Internal Disks
  • From: Harsh Azad
• Re: Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
  • From: El-Lotso
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Jean-David Beyer
• Re: Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
  • From: El-Lotso
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Joshua D. Drake
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Greg Smith
• Re: SAN vs Internal Disks
  • From: david
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Decibel!
• Re: SAN vs Internal Disks
  • From: Decibel!
• Re: More Vacuum questions...
  • From: Decibel!
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Gregory Stark
• Re: Barcelona vs Tigerton
  • From: Decibel!
• Re: [Again] Postgres performance problem
  • From: Decibel!
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Mark Mielke
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Decibel!
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Decibel!
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Decibel!
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Decibel!
• Re: SAN vs Internal Disks
  • From: Michael Stone
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Decibel!
• Re: SAN vs Internal Disks
  • From: Decibel!
• Re: Hardware spec
  • From: Decibel!
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Decibel!
• Re: Barcelona vs Tigerton
  • From: Joshua D. Drake
• Re: Barcelona vs Tigerton
  • From: Guy Rouillier
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Jean-David Beyer
• Re: efficient pattern queries (using LIKE, ~)
  • From: Mario Weilguni
• efficient pattern queries (using LIKE, ~)
  • From: Fernan Aguero
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Mario Weilguni
• Re: Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
  • From: Tom Lane
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Gregory Stark
• Re: More Vacuum questions...
  • From: Heikki Linnakangas
• Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
  • From: El-Lotso
• 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
  • From: El-Lotso
• More Vacuum questions...
  • From: Kevin Kempter
• Re: Barcelona vs Tigerton
  • From: Greg Smith
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Steinar H. Gunderson
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Maila Fatticcioni
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Jean-David Beyer
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Heikki Linnakangas
• Re: Barcelona vs Tigerton
  • From: Luke Lonergan
• Barcelona vs Tigerton
  • From: Mindaugas
• Re: [Again] Postgres performance problem
  • From: Ruben Rubio
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Luke Lonergan
• Re: [Again] Postgres performance problem
  • From: db
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Gregory Stark
• [Again] Postgres performance problem
  • From: Ruben Rubio
• Re: What to vacuum after deleting lots of tables
  • From: Tom Lane
• What to vacuum after deleting lots of tables
  • From: Craig James
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Luke Lonergan
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Luke Lonergan
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Mark Mielke
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Mark Mielke
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Jeff Davis
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Scott Marlowe
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Gregory Stark
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Josh Berkus
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Mark Mielke
• Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Luke Lonergan
• random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1
  • From: Carlo Stonebanks
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Tom Lane
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Greg Smith
• Re: Slow Query
  • From: Shawn
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Joshua D. Drake
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Joshua D. Drake
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Bernd Helmle
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Gregory Stark
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Stefan Kaltenbrunner
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Joshua D. Drake
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Joshua D. Drake
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Gregory Stark
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Tom Lane
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Stefan Kaltenbrunner
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Joshua D. Drake
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Gregory Stark
• Re: optimize query with a maximum(date) extraction
  • From: Dimitri
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Simon Riggs
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Bernd Helmle
• Re: SAN vs Internal Disks
  • From: Joshua D. Drake
• Re: SAN vs Internal Disks
  • From: david
• Re: SAN vs Internal Disks
  • From: Vivek Khera
• Re: SAN vs Internal Disks
  • From: Greg Smith
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Simon Riggs
• Re: SAN vs Internal Disks
  • From: Joshua D. Drake
• Re: SAN vs Internal Disks
  • From: Brian Hurt
• Re: SAN vs Internal Disks
  • From: Alan Hodgson
• Re: SAN vs Internal Disks
  • From: Bryan Murphy
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Harald Armin Massa
• Re: SAN vs Internal Disks
  • From: Matthew Schumacher
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: postgres memory management issues?
  • From: Tom Lane
• Re: SAN vs Internal Disks
  • From: Michael Stone
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Merlin Moncure
• Re: SAN vs Internal Disks
  • From: Tobias Brox
• Re: utilising multi-cpu/core machines?
  • From: Sven Geisler
• Re: DRBD and Postgres: how to improve the perfomance?
  • From: Heikki Linnakangas
• Re: postgres memory management issues?
  • From: Michael Stone
• Re: SAN vs Internal Disks
  • From: Michael Stone
• DRBD and Postgres: how to improve the perfomance?
  • From: Maila Fatticcioni
• Re: postgres memory management issues?
  • From: Florian Weimer
• Re: postgres memory management issues?
  • From: Gregory Stark
• Re: postgres memory management issues?
  • From: Claus Guttesen
• Re: postgres memory management issues?
  • From: Richard Huxton
• postgres memory management issues?
  • From: Richard Yen
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Florian Weimer
• Re: SAN vs Internal Disks
  • From: Florian Weimer
• Re: SAN vs Internal Disks
  • From: Greg Smith
• Re: Performance on 8CPU's and 32GB of RAM
  • From: James Mansion
• Re: Reasonable amount of indices
  • From: Alvaro Herrera
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Carlo Stonebanks
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: How planner decides left-anchored LIKE can use index
  • From: Tom Lane
• How planner decides left-anchored LIKE can use index
  • From: Carlo Stonebanks
• Re: Reasonable amount of indices
  • From: Tom Lane
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Alvaro Herrera
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Carlo Stonebanks
• Re: SAN vs Internal Disks
  • From: Scott Marlowe
• Re: Performance on 8CPU's and 32GB of RAM
  • From: James Mansion
• Re: Performance on 8CPU's and 32GB of RAM
  • From: James Mansion
• Reasonable amount of indices
  • From: Patric
• Re: SAN vs Internal Disks
  • From: Arjen van der Meijden
• Re: SAN vs Internal Disks
  • From: Arjen van der Meijden
• Re: [ADMIN] ADO -PostgreSQL OLE DB Provider
  • From: Richard Broersma Jr
• Re: SAN vs Internal Disks
  • From: Joel Fradkin
• Re: SAN vs Internal Disks
  • From: Joe Uhl
• Re: Hardware spec
  • From: Willo van der Merwe
• Re: Hardware spec
  • From: Florian Weimer
• Re: SAN vs Internal Disks
  • From: Scott Marlowe
• Re: SAN vs Internal Disks
  • From: Mark Lewis
• Re: Hardware spec]
  • From: Jean-David Beyer
• Re: SAN vs Internal Disks
  • From: Harsh Azad
• Re: SAN vs Internal Disks
  • From: Scott Marlowe
• Re: SAN vs Internal Disks
  • From: Arjen van der Meijden
• Re: SAN vs Internal Disks
  • From: Joshua D. Drake
• Re: SAN vs Internal Disks
  • From: Harsh Azad
• Re: SAN vs Internal Disks
  • From: Mark Lewis
• Re: SAN vs Internal Disks
  • From: Harsh Azad
• Re: SAN vs Internal Disks
  • From: Scott Marlowe
• Re: Hardware spec
  • From: Florian Weimer
• Re: utilising multi-cpu/core machines?
  • From: Kevin Grittner
• SAN vs Internal Disks
  • From: Harsh Azad
• Re: Hardware spec
  • From: Willo van der Merwe
• Re: Hardware spec
  • From: Jean-David Beyer
• Re: Hardware spec
  • From: Willo van der Merwe
• Re: Hardware spec
  • From: Richard Huxton
• Hardware spec
  • From: Willo van der Merwe
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Ansgar -59cobalt- Wiechers
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Joshua D. Drake
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: utilising multi-cpu/core machines?
  • From: Trevor Talbot
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Ansgar -59cobalt- Wiechers
• Re: utilising multi-cpu/core machines?
  • From: Jonah H. Harris
• utilising multi-cpu/core machines?
  • From: Thomas Finneid
• RESEND:Postgres with Sun Cluster HA/Solaris 10
  • From: Subbiah Stalin-XCGF84
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Adam Tauno Williams
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Ansgar -59cobalt- Wiechers
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Trevor Talbot
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Ron Mayer
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Trevor Talbot
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Alvaro Herrera
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Carlo Stonebanks
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: optimize query with a maximum(date) extraction
  • From: Tom Lane
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Carlo Stonebanks
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Scott Marlowe
• Re: Performance on 8CPU's and 32GB of RAM
  • From: Carlo Stonebanks
• Re: optimize query with a maximum(date) extraction
  • From: Gregory Stark
• Re: optimize query with a maximum(date) extraction
  • From: Gregory Stark
• Re: optimize query with a maximum(date) extraction
  • From: Gregory Stark
• Re: optimize query with a maximum(date) extraction
  • From: hubert depesz lubaczewski
• Re : optimize query with a maximum(date) extraction
  • From: JS Ubei
• Re: optimize query with a maximum(date) extraction
  • From: Pavel Stehule
• Re: optimize query with a maximum(date) extraction
  • From: Peter Childs