Postgres Performance Date Index

• Thread Index

• Re: very very slow inserts into very large table
  • From: Craig Ringer
• Re: very very slow inserts into very large table
  • From: Claudio Freire
• Re: very very slow inserts into very large table
  • From: Mark Thornton
• Re: very very slow inserts into very large table
  • From: Claudio Freire
• Re: very very slow inserts into very large table
  • From: Mark Thornton
• Re: very very slow inserts into very large table
  • From: Jeff Janes
• Re: very very slow inserts into very large table
  • From: Jon Nelson
• Re: very very slow inserts into very large table
  • From: Samuel Gendler
• Re: query overhead
  • From: Craig Ringer
• Re: very very slow inserts into very large table
  • From: Mark Thornton
• very very slow inserts into very large table
  • From: Jon Nelson
• Re: PostgreSQL index issue
  • From: Albe Laurenz
• Proposed change for 9.3(?): Require full restart to change fsync parameter, not just pg_ctl reload
  • From: Craig Ringer
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: Craig Ringer
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: Sergey Konoplev
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: Robert Klemme
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: B Sreejith
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: John Jones
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: Craig Ringer
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: Craig Ringer
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Craig Ringer
• Re: query overhead
  • From: Craig Ringer
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: B Sreejith
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: B Sreejith
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: Robert Klemme
• Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material)
  • From: Claudio Freire
• Re: Any tool/script available which can be used to measure scalability of an application's database.
  • From: Sergey Konoplev
• Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material)
  • From: Tom Lane
• Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material)
  • From: Claudio Freire
• Is there a tool available to perform Data Model review, from a performance perspective?
  • From: B Sreejith
• Re: query overhead
  • From: Tom Lane
• Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material)
  • From: Claudio Freire
• Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material)
  • From: Eoghan Murray
• PostgreSQL index issue
  • From: codevally
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Stanislaw Pankevich
• query overhead
  • From: Andy Halsall
• Any tool/script available which can be used to measure scalability of an application's database.
  • From: Sreejith Balakrishnan
• Re: how could select id=xx so slow?
  • From: Yan Chunlu
• Re: how could select id=xx so slow?
  • From: Yan Chunlu
• Re: SSDs again, LSI Warpdrive 2 anyone?
  • From: jamonb
• slow prepare, lots of semop calls.
  • From: David Kerr
• Re: how could select id=xx so slow?
  • From: Yan Chunlu
• Re: DELETE vs TRUNCATE explanation
  • From: Jeff Janes
• Re: DELETE vs TRUNCATE explanation
  • From: Harold A. Giménez
• Re: DELETE vs TRUNCATE explanation
  • From: Jeff Janes
• Re: how could select id=xx so slow?
  • From: Jeff Janes
• Re: how could select id=xx so slow?
  • From: Ants Aasma
• Re: how could select id=xx so slow?
  • From: Craig Ringer
• Re: how could select id=xx so slow?
  • From: Yan Chunlu
• Re: DELETE vs TRUNCATE explanation
  • From: Craig Ringer
• Re: how could select id=xx so slow?
  • From: Craig Ringer
• Re: DELETE vs TRUNCATE explanation
  • From: Daniel Farina
• Re: how could select id=xx so slow?
  • From: Yan Chunlu
• Re: how could select id=xx so slow?
  • From: Craig Ringer
• Re: DELETE vs TRUNCATE explanation
  • From: Craig Ringer
• Re: DELETE vs TRUNCATE explanation
  • From: Craig Ringer
• Re: DELETE vs TRUNCATE explanation
  • From: Craig Ringer
• Re: how could select id=xx so slow?
  • From: Maciek Sakrejda
• Re: how could select id=xx so slow?
  • From: Yan Chunlu
• Re: how could select id=xx so slow?
  • From: Craig Ringer
• Re: DELETE vs TRUNCATE explanation
  • From: Daniel Farina
• Re: DELETE vs TRUNCATE explanation
  • From: Craig James
• Re: DELETE vs TRUNCATE explanation
  • From: Mark Thornton
• Re: DELETE vs TRUNCATE explanation
  • From: Andrew Dunstan
• Re: DELETE vs TRUNCATE explanation
  • From: Shaun Thomas
• Re: DELETE vs TRUNCATE explanation
  • From: Craig James
• Re: DELETE vs TRUNCATE explanation
  • From: Matthew Woodcraft
• Re: moving tables
  • From: Midge Brown
• Re: how could select id=xx so slow?
  • From: Yan Chunlu
• Re: DELETE vs TRUNCATE explanation
  • From: ktm@xxxxxxxx
• Re: DELETE vs TRUNCATE explanation
  • From: Tom Lane
• Re: how could select id=xx so slow?
  • From: Ants Aasma
• Re: how could select id=xx so slow?
  • From: Yan Chunlu
• Re: how could select id=xx so slow?
  • From: Albe Laurenz
• Re: Paged Query
  • From: Віталій Тимчишин
• Re: Paged Query
  • From: Віталій Тимчишин
• Re: how could select id=xx so slow?
  • From: Yan Chunlu
• Re: DELETE vs TRUNCATE explanation
  • From: Daniel Farina
• DELETE vs TRUNCATE explanation
  • From: Craig Ringer
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Reza Taheri
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Merlin Moncure
• Re: Massive I/O spikes during checkpoint
  • From: Andres Freund
• Re: Massive I/O spikes during checkpoint
  • From: Jeff Janes
• Re: Massive I/O spikes during checkpoint
  • From: Andres Freund
• Fw: Re: Custom function in where clause
  • From: Pena Kupen
• Re: Custom function in where clause
  • From: Pena Kupen
• Re: Custom function in where clause
  • From: Brendan Jurd
• Re: Custom function in where clause
  • From: Maxim Boguk
• Custom function in where clause
  • From: Pena Kupen
• Re: Create tables performance
  • From: Sylvain CAILLET
• Re: Massive I/O spikes during checkpoint
  • From: David Kerr
• Re: Massive I/O spikes during checkpoint
  • From: Maxim Boguk
• Re: Massive I/O spikes during checkpoint
  • From: David Kerr
• Re: Massive I/O spikes during checkpoint
  • From: David Kerr
• Re: Massive I/O spikes during checkpoint
  • From: Jeff Janes
• Re: Massive I/O spikes during checkpoint
  • From: Maxim Boguk
• Massive I/O spikes during checkpoint
  • From: David Kerr
• Re: how could select id=xx so slow?
  • From: Craig Ringer
• Re: how could select id=xx so slow?
  • From: Craig Ringer
• Re: Paged Query
  • From: Jeff Janes
• Re: Paged Query
  • From: Craig Ringer
• Re: Paged Query
  • From: Craig Ringer
• Re: Paged Query
  • From: Misa Simic
• Re: Paged Query
  • From: Gurjeet Singh
• Re: Paged Query
  • From: Andrew Dunstan
• Re: Paged Query
  • From: Misa Simic
• Re: Create tables performance
  • From: Jeff Janes
• Re: Paged Query
  • From: Greg Spiegelberg
• Re: Paged Query
  • From: Craig James
• Re: Paged Query
  • From: Shaun Thomas
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Stanislaw Pankevich
• Re: how could select id=xx so slow?
  • From: Yan Chunlu
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Stanislaw Pankevich
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Stanislaw Pankevich
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Stanislaw Pankevich
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Stanislaw Pankevich
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Stanislaw Pankevich
• Re: Paged Query
  • From: Craig Ringer
• Re: Paged Query
  • From: Gregg Jaskiewicz
• Re: Create tables performance
  • From: Sylvain CAILLET
• Re: Terrible plan for join to nested union
  • From: Nate Allan
• Re: Terrible plan for join to nested union
  • From: Tom Lane
• Re: Terrible plan for join to nested union
  • From: Nate Allan
• Re: Terrible plan for join to nested union
  • From: Tom Lane
• Re: Terrible plan for join to nested union
  • From: Nate Allan
• Re: Terrible plan for join to nested union
  • From: Pavel Stehule
• Re: Terrible plan for join to nested union
  • From: Nate Allan
• Re: Terrible plan for join to nested union
  • From: Tom Lane
• Terrible plan for join to nested union
  • From: Nate Allan
• Re: Create tables performance
  • From: Craig Ringer
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Chris Hanks
• Re: Create tables performance
  • From: Richard Huxton
• Re: Create tables performance
  • From: Jeff Janes
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Steve Crawford
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Jeff Janes
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Marc Mamin
• Create tables performance
  • From: Sylvain CAILLET
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Albe Laurenz
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Craig Ringer
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Andres Freund
• Re: Paged Query
  • From: Misa Simic
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Albe Laurenz
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Craig Ringer
• Re: Paged Query
  • From: Greg Spiegelberg
• Re: Paged Query
  • From: Albe Laurenz
• Re: Paged Query
  • From: Віталій Тимчишин
• Re: how could select id=xx so slow?
  • From: Albe Laurenz
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Daniel Farina
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Craig Ringer
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Craig Ringer
• Re: how could select id=xx so slow?
  • From: Craig Ringer
• Re: how could select id=xx so slow?
  • From: Daniel Farina
• how could select id=xx so slow?
  • From: Yan Chunlu
• Paged Query
  • From: Hermann Matthes
• PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Stanislaw Pankevich
• Re: select operations that generate disk writes
  • From: Craig Ringer
• Re: select operations that generate disk writes
  • From: Pavel Stehule
• select operations that generate disk writes
  • From: CSS
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Reza Taheri
• Re: SSDs again, LSI Warpdrive 2 anyone?
  • From: Mark Kirkwood
• Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL
  • From: Reza Taheri
• The overall experience of TPC-V benchmark team with PostgreSQL
  • From: Reza Taheri
• Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL
  • From: Craig Ringer
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Reza Taheri
• Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL
  • From: Reza Taheri
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Craig Ringer
• What would effect planning time?
  • From: David Kerr
• Re: MemSQL the "world's fastest database"?
  • From: Greg Smith
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Greg Smith
• Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL
  • From: Greg Smith
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Craig Ringer
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Reza Taheri
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Craig Ringer
• SSDs again, LSI Warpdrive 2 anyone?
  • From: Mark Kirkwood
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Craig Ringer
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Andy Colson
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Samuel Gendler
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Reza Taheri
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Samuel Gendler
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Reza Taheri
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Reza Taheri
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Robert Klemme
• Re: Drop statistics?
  • From: David Kerr
• Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL
  • From: Mark Kirkwood
• Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL
  • From: Reza Taheri
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Claudio Freire
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Daniel Farina
• Re: static virtual columns as result?
  • From: PV
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Craig Ringer
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Thomas Kellerer
• Re: The need for clustered indexes to boost TPC-V performance
  • From: Craig Ringer
• Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL
  • From: Craig Ringer
• The need for clustered indexes to boost TPC-V performance
  • From: Reza Taheri
• Introducing the TPC-V benchmark, and its relationship to PostgreSQL
  • From: Reza Taheri
• Re: MemSQL the "world's fastest database"?
  • From: Gregg Jaskiewicz
• Re: Drop statistics?
  • From: Bruce Momjian
• Re: static virtual columns as result?
  • From: PV
• Re: static virtual columns as result?
  • From: Kevin Grittner
• static virtual columns as result?
  • From: PV
• Re: MemSQL the "world's fastest database"?
  • From: Scott Marlowe
• Re: SSD, Postgres and safe write cache
  • From: Greg Smith
• Re: MemSQL the "world's fastest database"?
  • From: Greg Smith
• Re: Performance of a large array access by position (tested version 9.1.3)
  • From: Cédric Villemain
• Re: Can I do better than this heapscan and sort?
  • From: Merlin Moncure
• Re: [pgsql-cluster-hackers][performance] fast reads on a busy server
  • From: Willy-Bas Loos
• Re: [pgsql-cluster-hackers][performance] fast reads on a busy server
  • From: Ants Aasma
• Re: [pgsql-cluster-hackers][performance] fast reads on a busy server
  • From: Willy-Bas Loos
• Re: [pgsql-cluster-hackers][performance] fast reads on a busy server
  • From: Willy-Bas Loos
• Re: [pgsql-cluster-hackers][performance] fast reads on a busy server
  • From: Willy-Bas Loos
• Re: [pgsql-cluster-hackers][performance] fast reads on a busy server
  • From: Hannu Krosing
• [pgsql-cluster-hackers][performance] fast reads on a busy server
  • From: Willy-Bas Loos
• Re: Can I do better than this heapscan and sort?
  • From: Merlin Moncure
• Re: Can I do better than this heapscan and sort?
  • From: Merlin Moncure
• Re: Performance of a large array access by position (tested version 9.1.3)
  • From: Pavel Stehule
• Re: Performance of a large array access by position (tested version 9.1.3)
  • From: Pavel Stehule
• Re: Performance of a large array access by position (tested version 9.1.3)
  • From: Marc Mamin
• Re: Performance of a large array access by position (tested version 9.1.3)
  • From: Pavel Stehule
• Re: Performance of a large array access by position (tested version 9.1.3)
  • From: Marc Mamin
• Re: Performance of a large array access by position (tested version 9.1.3)
  • From: Jesper Krogh
• Re: MemSQL the "world's fastest database"?
  • From: Tom Lane
• Re: Postgres delete performance problem
  • From: Alejandro Carrillo
• Re: MemSQL the "world's fastest database"?
  • From: gnuoytr
• Re: MemSQL the "world's fastest database"?
  • From: Josh Berkus
• Re: MemSQL the "world's fastest database"?
  • From: Kevin Grittner
• Re: MemSQL the "world's fastest database"?
  • From: Shaun Thomas
• MemSQL the "world's fastest database"?
  • From: Craig James
• Re: SSD, Postgres and safe write cache
  • From: Yeb Havinga
• Re: Postgres delete performance problem
  • From: Vitalii Tymchyshyn
• Performance of a large array access by position (tested version 9.1.3)
  • From: Maxim Boguk
• Can I do better than this heapscan and sort?
  • From: Andy Halsall
• random char or text variable in pgbench
  • From: philippe . beaudoin
• SSD, Postgres and safe write cache
  • From: Michal Szymanski
• Postgres delete performance problem
  • From: Frits Jalvingh
• Re: index-only scan is missing the INCLUDE feature
  • From: Cédric Villemain
• Re: "global/pgstat.stat" corrupt
  • From: David Kerr
• Re: "global/pgstat.stat" corrupt
  • From: Tom Lane
• "global/pgstat.stat" corrupt
  • From: David Kerr
• Re: Drop statistics?
  • From: David Kerr
• Re: Drop statistics?
  • From: Tom Lane
• Drop statistics?
  • From: David Kerr
• Re: Why is a hash join being used?
  • From: Kevin Grittner
• Re: moving tables
  • From: Albe Laurenz
• Re: index-only scan is missing the INCLUDE feature
  • From: Craig Ringer
• Re: moving tables
  • From: Josh Berkus
• moving tables
  • From: Midge Brown
• Re: index-only scan is missing the INCLUDE feature
  • From: Shaun Thomas
• Re: pgbouncer - massive overhead?
  • From: Steve Crawford
• Re: scale up (postgresql vs mssql)
  • From: Merlin Moncure
• Re: index-only scan is missing the INCLUDE feature
  • From: Craig Ringer
• Re: scale up (postgresql vs mssql)
  • From: Andy Colson
• Re: Why is a hash join being used?
  • From: Sergey Konoplev
• pgbouncer - massive overhead?
  • From: Strange, John W
• Why is a hash join being used?
  • From: Tim Jacobs
• index-only scan is missing the INCLUDE feature
  • From: Eyal Wilde
• Re: scale up (postgresql vs mssql)
  • From: Eyal Wilde
• High CPU Usage
  • From: Siddharth Shah
• Re: Expected performance of querying 5k records from 4 million records?
  • From: Josh Berkus
• Re: Expected performance of querying 5k records from 4 million records?
  • From: Samuel Gendler
• Re: Expected performance of querying 5k records from 4 million records?
  • From: Anish Kejariwal
• Re: correlated exists with join is slow.
  • From: Віталій Тимчишин
• Re: correlated exists with join is slow.
  • From: Kevin Grittner
• Re: correlated exists with join is slow.
  • From: Tom Lane
• correlated exists with join is slow.
  • From: Віталій Тимчишин
• Re: Update blocking a select count(*)?
  • From: Kevin Grittner
• Re: Update blocking a select count(*)?
  • From: Benedict Holland
• Re: Update blocking a select count(*)?
  • From: Kevin Grittner
• Re: Update blocking a select count(*)?
  • From: Benedict Holland
• Re: Update blocking a select count(*)?
  • From: Kevin Grittner
• Re: Update blocking a select count(*)?
  • From: Benedict Holland
• Re: Update blocking a select count(*)?
  • From: Kevin Grittner
• Re: Update blocking a select count(*)?
  • From: Benedict Holland
• Re: Update blocking a select count(*)?
  • From: Benedict Holland
• Re: Update blocking a select count(*)?
  • From: Benedict Holland
• Re: Update blocking a select count(*)?
  • From: Kevin Grittner
• Re: Update blocking a select count(*)?
  • From: Kevin Grittner
• Re: Update blocking a select count(*)?
  • From: Benedict Holland
• Re: Update blocking a select count(*)?
  • From: Benedict Holland
• Re: Update blocking a select count(*)?
  • From: Kevin Grittner
• Re: Update blocking a select count(*)?
  • From: Kevin Grittner
• Re: Update blocking a select count(*)?
  • From: Peter Geoghegan
• Update blocking a select count(*)?
  • From: Benedict Holland
• Re: Expected performance of querying 5k records from 4 million records?
  • From: Jeff Janes
• Re: Expected performance of querying 5k records from 4 million records?
  • From: Josh Berkus
• Expected performance of querying 5k records from 4 million records?
  • From: Anish Kejariwal
• Re: pg_dump and thousands of schemas
  • From: Tatsuo Ishii
• Re: pg_dump and thousands of schemas
  • From: Jeff Janes
• Re: Performance of pg_basebackup
  • From: Shaun Thomas
• Re: Performance of pg_basebackup
  • From: Magnus Hagander
• Performance of pg_basebackup
  • From: Shaun Thomas
• Re: pg_dump and thousands of schemas
  • From: Tatsuo Ishii
• Re: Performance of CLUSTER
  • From: Jeff Davis
• Re: pg_dump and thousands of schemas
  • From: Jeff Janes
• Re: Performance of CLUSTER
  • From: Shaun Thomas
• Re: Performance of CLUSTER
  • From: Shaun Thomas
• Re: Performance of CLUSTER
  • From: Mark Thornton
• postgres clustering interactions with pg_dump
  • From: Fitch, Britt
• Re: Performance of CLUSTER
  • From: Shaun Thomas
• Re: how to change the index chosen in plan?
  • From: Rural Hunter
• Re: how to change the index chosen in plan?
  • From: Kevin Grittner
• Re: Tablespaces and query planning
  • From: Albe Laurenz
• Re: how to change the index chosen in plan?
  • From: Rural Hunter
• Re: pg_dump and thousands of schemas
  • From: Jeff Janes
• Re: partitioning performance question
  • From: Robert Klemme
• Performance of CLUSTER
  • From: Mark Thornton
• Re: pg 9.1 brings host machine down
  • From: Craig Ringer
• partitioning performance question
  • From: Kevin Kempter
• Re: how to change the index chosen in plan?
  • From: Kevin Grittner
• Re: how to change the index chosen in plan?
  • From: Kevin Grittner
• Re: how to change the index chosen in plan?
  • From: Rural Hunter
• Re: pg 9.1 brings host machine down
  • From: Konstantin Mikhailov
• Re: how to change the index chosen in plan?
  • From: Kevin Grittner
• Re: how to change the index chosen in plan?
  • From: Rural Hunter
• Re: how to change the index chosen in plan?
  • From: Kevin Grittner
• Re: non index use on LIKE on a non pattern string
  • From: Cédric Villemain
• Re: how to change the index chosen in plan?
  • From: Rural Hunter
• Re: how to change the index chosen in plan?
  • From: Tom Lane
• Re: non index use on LIKE on a non pattern string
  • From: Tom Lane
• how to change the index chosen in plan?
  • From: Rural Hunter
• Re: non index use on LIKE on a non pattern string
  • From: Cédric Villemain
• non index use on LIKE on a non pattern string
  • From: Guillaume Cottenceau
• Re: Seqscan slowness and stored procedures
  • From: Ivan Voras
• Re: Multiple Concurrent Updates of Shared Resource Counter
  • From: Cédric Villemain
• Re: Tablespaces and query planning
  • From: Cédric Villemain
• Re: Seqscan slowness and stored procedures
  • From: Albe Laurenz
• Tablespaces and query planning
  • From: Albe Laurenz
• Re: Multiple Concurrent Updates of Shared Resource Counter
  • From: Robert Klemme
• Multiple Concurrent Updates of Shared Resource Counter
  • From: Nir Zilberman
• Re: pg 9.1 brings host machine down
  • From: Julien Cigar
• Re: pg 9.1 brings host machine down
  • From: Patric Bechtel
• Re: pg 9.1 brings host machine down
  • From: Vitalii Tymchyshyn
• pg 9.1 brings host machine down
  • From: Konstantin Mikhailov
• Re: Missing block Magic
  • From: Alejandro Carrillo
• Re: Missing block Magic
  • From: Tom Lane
• Missing block Magic
  • From: Alejandro Carrillo
• Re: Sequencial scan in a JOIN
  • From: Shaun Thomas
• Re: Sequencial scan in a JOIN
  • From: Shaun Thomas
• Re: Sequencial scan in a JOIN
  • From: Andrew Jaimes
• Re: Sequencial scan in a JOIN
  • From: Shaun Thomas
• Sequencial scan in a JOIN
  • From: Andrew Jaimes
• Re: Trouble with plan statistics for behaviour for query.
  • From: Trevor Campbell
• Re: Trouble with plan statistics for behaviour for query.
  • From: Trevor Campbell
• Re: Recover rows deleted
  • From: Kevin Grittner
• Re: Recover rows deleted
  • From: Alejandro Carrillo
• Re: Recover rows deleted
  • From: Merlin Moncure
• Re: Recover rows deleted
  • From: Alejandro Carrillo
• Re: Recover rows deleted
  • From: Merlin Moncure
• Re: Recover rows deleted
  • From: Alejandro Carrillo
• Re: Recover rows deleted
  • From: Shaun Thomas
• Re: Recover rows deleted
  • From: Alejandro Carrillo
• Array fundamentals
  • From: idc danny
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Kevin Grittner
• Re: Select from sequence in slow query log
  • From: Chris Rimmer
• Re: Trouble with plan statistics for behaviour for query.
  • From: Maciek Sakrejda
• Re: does the query planner consider work_mem?
  • From: Tom Lane
• Re: Select from sequence in slow query log
  • From: Tom Lane
• Select from sequence in slow query log
  • From: Chris Rimmer
• Re: Trouble with plan statistics for behaviour for query.
  • From: Vitalii Tymchyshyn
• Re: Trouble with plan statistics for behaviour for query.
  • From: Craig James
• Re: Trouble with plan statistics for behaviour for query.
  • From: Trevor Campbell
• Re: Trouble with plan statistics for behaviour for query.
  • From: Craig James
• Re: Trouble with plan statistics for behaviour for query.
  • From: Trevor Campbell
• Re: does the query planner consider work_mem?
  • From: Mark Kirkwood
• Re: Trouble with plan statistics for behaviour for query.
  • From: Craig James
• Trouble with plan statistics for behaviour for query.
  • From: Trevor Campbell
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Claudio Freire
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Tom Lane
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Bruce Momjian
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Robert Haas
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Claudio Freire
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Bruce Momjian
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Tom Lane
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Robert Haas
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Tom Lane
• Re: pg_dump and thousands of schemas
  • From: Claudio Freire
• Re: pg_dump and thousands of schemas
  • From: Robert Klemme
• Re: pg_dump and thousands of schemas
  • From: Tatsuo Ishii
• Re: pg_dump and thousands of schemas
  • From: Robert Klemme
• Re: pg_dump and thousands of schemas
  • From: Tatsuo Ishii
• Re: pg_dump and thousands of schemas
  • From: Tatsuo Ishii
• Re: pg_dump and thousands of schemas
  • From: Tom Lane
• Re: pg_dump and thousands of schemas
  • From: Stephen Frost
• Re: pg_dump and thousands of schemas
  • From: Tom Lane
• Re: pg_dump and thousands of schemas
  • From: Tatsuo Ishii
• Re: does the query planner consider work_mem?
  • From: Murat Tasan
• Re: does the query planner consider work_mem?
  • From: Ants Aasma
• does the query planner consider work_mem?
  • From: Murat Tasan
• Re: pg_dump and thousands of schemas
  • From: Tatsuo Ishii
• Re: pg_dump and thousands of schemas
  • From: Tatsuo Ishii
• Re: Recover rows deleted
  • From: Alejandro Carrillo
• Re: Recover rows deleted
  • From: Alejandro Carrillo
• Re: Recover rows deleted
  • From: hubert depesz lubaczewski
• Re: Recover rows deleted
  • From: Jeff Davis
• Re: Strong slowdown on huge tables
  • From: Tom Lane
• Re: pg_dump and thousands of schemas
  • From: Tom Lane
• Strong slowdown on huge tables
  • From: Job
• Re: pg_dump and thousands of schemas
  • From: Tatsuo Ishii
• Re: pg_dump and thousands of schemas
  • From: Hugo <Nabble>
• Re: pg_dump and thousands of schemas
  • From: Tom Lane
• Re: pg_dump and thousands of schemas
  • From: Jeff Janes
• Recover rows deleted
  • From: Alejandro Carrillo
• Re: SSD selection
  • From: Greg Smith
• Re: Seqscan slowness and stored procedures
  • From: Pavel Stehule
• Re: Seqscan slowness and stored procedures
  • From: Ivan Voras
• Re: pg_dump and thousands of schemas
  • From: Hugo <Nabble>
• Re: Seqscan slowness and stored procedures
  • From: Pavel Stehule
• Seqscan slowness and stored procedures
  • From: Ivan Voras
• Re: pg_dump and thousands of schemas
  • From: Tatsuo Ishii
• Re: Parallel (concurrent) inserts?
  • From: Ivan Voras
• Re: Parallel (concurrent) inserts?
  • From: Jeff Janes
• Re: Parallel (concurrent) inserts?
  • From: Josh Berkus
• Parallel (concurrent) inserts?
  • From: Ivan Voras
• Re: pg_dump and thousands of schemas
  • From: Jeff Janes
• Re: pg_dump and thousands of schemas
  • From: Tom Lane
• Re: pg_dump and thousands of schemas
  • From: Jeff Janes
• Re: pg_dump and thousands of schemas
  • From: Tom Lane
• Re: pg_dump and thousands of schemas
  • From: Jeff Janes
• Millions of relations (from Maximum number of sequences that can be created)
  • From: Greg Spiegelberg
• Re: pg_dump and thousands of schemas
  • From: Jeff Janes
• Re: pg_dump and thousands of schemas
  • From: Bruce Momjian
• Re: Maximum number of sequences that can be created
  • From: Craig James
• Re: pg_dump and thousands of schemas
  • From: Tom Lane
• Re: Maximum number of sequences that can be created
  • From: Greg Spiegelberg
• Re: pg_dump and thousands of schemas
  • From: Ondrej Ivanič
• Re: pg_dump and thousands of schemas
  • From: Hugo <Nabble>
• Re: pg_dump and thousands of schemas
  • From: Bruce Momjian
• Re: pg_dump and thousands of schemas
  • From: Jeff Janes
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Claudio Freire
• Re: heavly load system spec
  • From: Merlin Moncure
• Re: heavly load system spec
  • From: Stephen Frost
• Re: heavly load system spec
  • From: Robert Haas
• Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
  • From: geirB
• Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
  • From: geirB
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Stephen Frost
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Rajesh Kumar. Mallah
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Rajesh Kumar. Mallah
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Stephen Frost
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Steve Crawford
• Re: pg_dump and thousands of schemas
  • From: Craig James
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Rajesh Kumar. Mallah
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Andy Colson
• pg_dump and thousands of schemas
  • From: Hugo <Nabble>
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Rajesh Kumar. Mallah
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Claudio Freire
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Rajesh Kumar. Mallah
• Re: Configuration Recommendations
  • From: Mark Kirkwood
• Re: High load average in 64-core server , no I/O wait and CPU is idle
  • From: Claudio Freire
• High load average in 64-core server , no I/O wait and CPU is idle
  • From: Rajesh Kumar. Mallah
• Re: local-storage versus SAN sequential read performance comparison
  • From: Shaun Thomas
• Re: local-storage versus SAN sequential read performance comparison
  • From: Scott Marlowe
• local-storage versus SAN sequential read performance comparison
  • From: Jan Nielsen
• Re: Configuration Recommendations
  • From: Jan Nielsen
• Re: Configuration Recommendations
  • From: Jan Nielsen
• Re: Configuration Recommendations
  • From: Jan Nielsen
• Re: SSD selection
  • From: Alejandro Carrillo
• Re: SSD selection
  • From: Merlin Moncure
• Re: SSD selection
  • From: David Boreham
• Re: SSD selection
  • From: Merlin Moncure
• Re: Configuration Recommendations
  • From: Robert Klemme
• Re: [pgsql-performance] Daily digest v1.3606 (10 messages)
  • From: Merlin Moncure
• Re: [pgsql-performance] Daily digest v1.3606 (10 messages)
  • From: John Lister
• Re: SSD selection
  • From: David Boreham
• Re: SSD selection
  • From: Rosser Schwarz
• Re: Configuration Recommendations
  • From: Greg Sabino Mullane
• Re: SSD selection
  • From: Merlin Moncure
• Re: SSD selection
  • From: David Boreham
• SSD selection
  • From: Віталій Тимчишин
• Re: Maximum number of sequences that can be created
  • From: Robert Klemme
• Re: Maximum number of sequences that can be created
  • From: Andres Freund
• Re: Maximum number of sequences that can be created
  • From: Віталій Тимчишин
• Re: Maximum number of sequences that can be created
  • From: Jeff Janes
• Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
  • From: Noah Misch
• Re: Maximum number of sequences that can be created
  • From: Craig James
• Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
  • From: Clemens Eisserer
• Re: Maximum number of sequences that can be created
  • From: Robert Klemme
• Re: Maximum number of sequences that can be created
  • From: Віталій Тимчишин
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: MauMau
• Re: Maximum number of sequences that can be created
  • From: Robert Klemme
• Maximum number of sequences that can be created
  • From: Vidhya Bondre
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: Fujii Masao
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: MauMau
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: Merlin Moncure
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: Tomas Vondra
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: Thomas Kellerer
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: MauMau
• Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
  • From: Noah Misch
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: Claudio Freire
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: MauMau
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: Merlin Moncure
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: Robert Klemme
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: Claudio Freire
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: Robert Klemme
• Re: Could synchronous streaming replication really degrade the performance of the primary?
  • From: Merlin Moncure
• Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
  • From: Clemens Eisserer
• Could synchronous streaming replication really degrade the performance of the primary?
  • From: MauMau
• Re: scale up (postgresql vs mssql)
  • From: Merlin Moncure
• Re: scale up (postgresql vs mssql)
  • From: Robert Klemme
• Re: Sudden Query slowdown on our Postgresql Server
  • From: Robert Haas
• Re: Result Set over Network Question
  • From: Robert Klemme
• Re: Result Set over Network Question
  • From: Thomas Kellerer
• Re: Result Set over Network Question
  • From: Robert Klemme
• Re: Result Set over Network Question
  • From: Thomas Kellerer
• Re: Result Set over Network Question
  • From: Robert Klemme
• Re: Several optimization options (config/hardware)
  • From: Martin Grotzke
• Re: Partitioned/inherited tables with check constraints causing slower query plans
  • From: Richard Jones
• Re: Partitioned/inherited tables with check constraints causing slower query plans
  • From: Tom Lane
• Re: Configuration Recommendations
  • From: Jeff Janes
• Re: Configuration Recommendations
  • From: Kevin Grittner
• Re: Configuration Recommendations
  • From: Jan Nielsen
• Partitioned/inherited tables with check constraints causing slower query plans
  • From: Richard Jones
• Re: Unexpected sequence scan
  • From: Dan Fairs
• Re: Unexpected sequence scan
  • From: Tom Lane
• Re: Unexpected sequence scan
  • From: Kevin Grittner
• Unexpected sequence scan
  • From: Dan Fairs
• Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
  • From: Clemens Eisserer
• Re: scale up (postgresql vs mssql)
  • From: Merlin Moncure
• Re: Configuration Recommendations
  • From: John Lister
• Re: scale up (postgresql vs mssql)
  • From: Eyal Wilde
• Re: Configuration Recommendations
  • From: Shaun Thomas
• Re: Configuration Recommendations
  • From: Shaun Thomas
• Re: Several optimization options (config/hardware)
  • From: Albe Laurenz
• Re: Configuration Recommendations
  • From: Scott Carey
• Re: Configuration Recommendations
  • From: Scott Carey
• Re: Configuration Recommendations
  • From: Craig James
• Re: Query got slow from 9.0 to 9.1 upgrade
  • From: Rural Hunter
• Re: Result Set over Network Question
  • From: Merlin Moncure
• Re: Result Set over Network Question
  • From: Ronald Hahn, DOCFOCUS INC.
• Re: Result Set over Network Question
  • From: Merlin Moncure
• Re: Result Set over Network Question
  • From: Claudio Freire
• Re: Configuration Recommendations
  • From: Jan Nielsen
• Re: scale up (postgresql vs mssql)
  • From: Merlin Moncure
• Re: Configuration Recommendations
  • From: Jan Nielsen
• Re: Configuration Recommendations
  • From: Jan Nielsen
• Re: Query got slow from 9.0 to 9.1 upgrade
  • From: Jonathan
• Re: Several optimization options (config/hardware)
  • From: Martin Grotzke
• Re: Query got slow from 9.0 to 9.1 upgrade
  • From: Ants Aasma
• Re: Configuration Recommendations
  • From: Robert Klemme
• Re: Several optimization options (config/hardware)
  • From: Albe Laurenz
• Re: Configuration Recommendations
  • From: John Lister
• Query got slow from 9.0 to 9.1 upgrade
  • From: Josh Turmel
• Result Set over Network Question
  • From: Ronald Hahn, DOCFOCUS INC.
• Re: scale up (postgresql vs mssql)
  • From: Eyal Wilde
• Re: query optimization
  • From: Richard Kojedzinszky
• Re: Configuration Recommendations
  • From: Jan Nielsen
• Re: Several optimization options (config/hardware)
  • From: Tomas Vondra
• Several optimization options (config/hardware)
  • From: Martin Grotzke
• Re: Tuning Postgres 9.1 on Windows
  • From: Walker, James Les
• Re: Tuning Postgres 9.1 on Windows
  • From: Walker, James Les
• Re: Tuning Postgres 9.1 on Windows
  • From: Thomas Kellerer
• Re: Tuning Postgres 9.1 on Windows
  • From: Merlin Moncure
• Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
  • From: Clemens Eisserer
• Re: Tuning Postgres 9.1 on Windows
  • From: Walker, James Les
• Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
  • From: Tom Lane
• Any disadvantages of using =ANY(ARRAY()) instead of IN?
  • From: Clemens Eisserer
• Re: Tuning Postgres 9.1 on Windows
  • From: Merlin Moncure
• Re: Tuning Postgres 9.1 on Windows
  • From: Andy Colson
• Re: Tuning Postgres 9.1 on Windows
  • From: Walker, James Les
• Re: Tuning Postgres 9.1 on Windows
  • From: Merlin Moncure
• Re: Tuning Postgres 9.1 on Windows
  • From: Walker, James Les
• Re: Tuning Postgres 9.1 on Windows
  • From: Merlin Moncure
• Re: Tuning Postgres 9.1 on Windows
  • From: Thomas Kellerer
• Re: Tuning Postgres 9.1 on Windows
  • From: Merlin Moncure
• Re: Tuning Postgres 9.1 on Windows
  • From: Andy Colson
• Tuning Postgres 9.1 on Windows
  • From: Walker, James Les
• Re: NOT EXISTS or LEFT JOIN which one is better?
  • From: Rich
• NOT EXISTS or LEFT JOIN which one is better?
  • From: AI Rumman
• Re: Weird plan variation with recursive CTEs
  • From: Tom Lane
• Re: query optimization
  • From: Andrew Dunstan
• Re: auto-vacuum vs. full table update
  • From: Kevin Grittner
• Re: query optimization
  • From: Tom Lane
• Re: auto-vacuum vs. full table update
  • From: Steve Crawford
• Re: auto-vacuum vs. full table update
  • From: Joshua D. Drake
• auto-vacuum vs. full table update
  • From: Craig James
• Re: query optimization
  • From: Thomas Kellerer
• Re: query optimization
  • From: Tom Lane
• Re: query optimization
  • From: Kevin Grittner
• Re: Weird plan variation with recursive CTEs
  • From: Claudio Freire
• Re: Configuration Recommendations
  • From: John Lister
• query optimization
  • From: Richard Kojedzinszky
• Weird plan variation with recursive CTEs
  • From: Claudio Freire
• Re: Parallel Scaling of a pgplsql problem
  • From: Greg Spiegelberg
• Re: Parallel Scaling of a pgplsql problem
  • From: Yeb Havinga
• Re: Parallel Scaling of a pgplsql problem
  • From: Jan Nielsen
• Re: Parallel Scaling of a pgplsql problem
  • From: Venki Ramachandran
• Re: Configuration Recommendations
  • From: Greg Smith
• Re: Parallel Scaling of a pgplsql problem
  • From: Merlin Moncure
• Re: Parallel Scaling of a pgplsql problem
  • From: Tom Lane
• Re: Parallel Scaling of a pgplsql problem
  • From: Venki Ramachandran
• Re: Configuration Recommendations
  • From: Shaun Thomas
• Re: Parallel Scaling of a pgplsql problem
  • From: Pavel Stehule
• Re: Parallel Scaling of a pgplsql problem
  • From: Venki Ramachandran
• Re: Parallel Scaling of a pgplsql problem
  • From: Pavel Stehule
• Re: Parallel Scaling of a pgplsql problem
  • From: Kevin Grittner
• Re: Parallel Scaling of a pgplsql problem
  • From: Samuel Gendler
• Re: Configuration Recommendations
  • From: Robert Klemme
• Parallel Scaling of a pgplsql problem
  • From: Venki Ramachandran
• Re: Configuration Recommendations
  • From: Greg Sabino Mullane
• Re: Configuration Recommendations
  • From: Jan Nielsen
• Re: Configuration Recommendations
  • From: Jan Nielsen
• Re: Configuration Recommendations
  • From: Shaun Thomas
• Re: Configuration Recommendations
  • From: Robert Klemme
• Configuration Recommendations
  • From: Jan Nielsen
• Re: bad planning with 75% effective_cache_size
  • From: Istvan Endredy
• Re: bad planning with 75% effective_cache_size
  • From: Ants Aasma
• Re: bad planning with 75% effective_cache_size
  • From: Josh Berkus
• Re: Linux machine aggressively clearing cache
  • From: Josh Berkus
• Re: scale up (postgresql vs mssql)
  • From: Merlin Moncure
• Re: scale up (postgresql vs mssql)
  • From: Andy Colson
• Re: scale up (postgresql vs mssql)
  • From: Eyal Wilde
• Re: Random performance hit, unknown cause.
  • From: Strange, John W
• Re: bad planning with 75% effective_cache_size
  • From: Віталій Тимчишин
• Re: bad planning with 75% effective_cache_size
  • From: Istvan Endredy
• Re: H800 + md1200 Performance problem
  • From: Scott Marlowe
• Re: H800 + md1200 Performance problem
  • From: Glyn Astill
• Re: H800 + md1200 Performance problem
  • From: Scott Marlowe
• Re: SeqScan with full text search
  • From: Віталій Тимчишин
• Re: SeqScan with full text search
  • From: Merlin Moncure
• Re: SeqScan with full text search
  • From: Tomas Vondra
• Re: H800 + md1200 Performance problem
  • From: Merlin Moncure
• Re: scale up (postgresql vs mssql)
  • From: Richard Huxton
• Re: H800 + md1200 Performance problem
  • From: Scott Marlowe
• Re: scale up (postgresql vs mssql)
  • From: Andy Colson
• SeqScan with full text search
  • From: Tomek Walkuski
• Re: scale up (postgresql vs mssql)
  • From: Eyal Wilde
• Re: H800 + md1200 Performance problem
  • From: Cesar Martin
• Re: Slow fulltext query plan
  • From: Florent Guillaume
• Re: scale up (postgresql vs mssql)
  • From: Merlin Moncure
• Re: bad planning with 75% effective_cache_size
  • From: Filippos
• Re: Slow fulltext query plan
  • From: Tom Lane
• Re: scale up (postgresql vs mssql)
  • From: Claudio Freire
• Re: scale up (postgresql vs mssql)
  • From: Steve Crawford
• Re: PostgreSQL - Help Optimizing performance - full text search on Heroku
  • From: Tomas Vondra
• Re: scale up (postgresql vs mssql)
  • From: Claudio Freire
• Re: scale up (postgresql vs mssql)
  • From: Steve Crawford
• PostgreSQL - Help Optimizing performance - full text search on Heroku
  • From: xlash
• Re: scale up (postgresql vs mssql)
  • From: Claudio Freire
• Re: scale up (postgresql vs mssql)
  • From: Kevin Grittner
• Re: scale up (postgresql vs mssql)
  • From: Andrew Dunstan
• scale up (postgresql vs mssql)
  • From: Eyal Wilde
• Re: Planner selects slow "Bitmap Heap Scan" when "Index Scan" is faster
  • From: Kim Hansen
• Re: bad planning with 75% effective_cache_size
  • From: Istvan Endredy
• Re: Slow fulltext query plan
  • From: Benoit Delbosc
• Re: Slow fulltext query plan
  • From: Tom Lane
• Slow fulltext query plan
  • From: Benoit Delbosc
• Re: Random performance hit, unknown cause.
  • From: Kevin Grittner
• Re: Random performance hit, unknown cause.
  • From: Brian Fehrle
• Re: Random performance hit, unknown cause.
  • From: Claudio Freire
• Re: Random performance hit, unknown cause.
  • From: Kevin Grittner
• Re: Random performance hit, unknown cause.
  • From: Claudio Freire
• Random performance hit, unknown cause.
  • From: Brian Fehrle
• Re: Linux machine aggressively clearing cache
  • From: Steve Crawford
• Re: about multiprocessingmassdata
  • From: Merlin Moncure
• Re: Planner selects slow "Bitmap Heap Scan" when "Index Scan" is faster
  • From: Jeff Janes
• Re: about multiprocessingmassdata
  • From: Tomas Vondra
• Re: about multiprocessingmassdata
  • From: Merlin Moncure
• Re: H800 + md1200 Performance problem
  • From: Cesar Martin
• Re: Stats
  • From: Kevin Grittner
• Stats
  • From: Lukas
• Re: get/set priority of PostgreSQL backends
  • From: Josh Kupershmidt
• Re: get/set priority of PostgreSQL backends
  • From: Scott Marlowe
• get/set priority of PostgreSQL backends
  • From: Josh Kupershmidt
• Re: Planner selects slow "Bitmap Heap Scan" when "Index Scan" is faster
  • From: Kim Hansen
• Re: Planner selects slow "Bitmap Heap Scan" when "Index Scan" is faster
  • From: Jeff Janes
• Re: bad plan
  • From: Julien Cigar
• Re: Planner selects slow "Bitmap Heap Scan" when "Index Scan" is faster
  • From: Kim Hansen
• Re: H800 + md1200 Performance problem
  • From: Tomas Vondra
• Re: bad plan
  • From: Ants Aasma