Postgres Performance Date Index

• Thread Index

• optimizing query with multiple aggregates
  • From: Doug Cole
• Re: There is a statistic table?
  • From: Scott Marlowe
• Re: Are unreferenced TOASTed values retrieved?
  • From: Tom Lane
• Re: Random penalties on GIN index updates?
  • From: Tom Lane
• Are unreferenced TOASTed values retrieved?
  • From: William Blunn
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Scott Carey
• Re: Random penalties on GIN index updates?
  • From: Jesper Krogh
• Re: maintain_cluster_order_v5.patch
  • From: phb07@xxxxxxxxxxxx
• Re: There is a statistic table?
  • From: Scott Carey
• Re: Random penalties on GIN index updates?
  • From: Tom Lane
• Random penalties on GIN index updates?
  • From: jesper
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Shaul Dar
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Melton Low
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Tom Lane
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: A. Kretschmer
• Re: Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Shaul Dar
• Finding rows in table T1 that DO NOT MATCH any row in table T2
  • From: Shaul Dar
• Re: Domain vs table
  • From: Merlin Moncure
• Re: Performance with sorting and LIMIT on partitioned table
  • From: Joe Uhl
• Re: Performance with sorting and LIMIT on partitioned table
  • From: Merlin Moncure
• Re: maintain_cluster_order_v5.patch
  • From: Jeff Davis
• maintain_cluster_order_v5.patch
  • From: phb07@xxxxxxxxxxxx
• Re: Partitioned Tables and ORDER BY
  • From: Robert Haas
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Simon Riggs
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Gerhard Wiesinger
• Re: Calculation of unused columns
  • From: Simon Riggs
• Re: Calculation of unused columns
  • From: Kevin Grittner
• Re: Partitioned Tables and ORDER BY
  • From: Craig James
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Simon Riggs
• Re: Partitioned Tables and ORDER BY
  • From: Grzegorz Jaśkiewicz
• Re: Partitioned Tables and ORDER BY
  • From: Robert Haas
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Indexes on low cardinality columns
  • From: Ron Mayer
• Re: Known Bottlenecks
  • From: Grzegorz Jaśkiewicz
• Known Bottlenecks
  • From: Vikul Khosla
• Re: Performance with sorting and LIMIT on partitioned table
  • From: Joe Uhl
• Re: Issues with \copy from file
  • From: Matthew Wakeling
• Re: Partitioned Tables and ORDER BY
  • From: Grzegorz Jaśkiewicz
• Re: Performance with sorting and LIMIT on partitioned table
  • From: Robert Haas
• Re: Improving join performance over multiple moderately wide tables
  • From: Robert Haas
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Robert Haas
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Robert Haas
• Re: Full text search - query plan? PG 8.4.1
  • From: Tom Lane
• Re: Full text search - query plan? PG 8.4.1
  • From: Jesper Krogh
• Re: Full text search - query plan? PG 8.4.1
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Jeff Janes
• Re: Calculation of unused columns
  • From: Tim Landscheidt
• Full text search - query plan? PG 8.4.1
  • From: Jesper Krogh
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: sequential scan on child partition tables
  • From: Anj Adu
• Re: Calculation of unused columns
  • From: Daniel Migowski
• Re: Partitioned Tables and ORDER BY
  • From: Joe Uhl
• Re: Issues with \copy from file
  • From: Scott Marlowe
• Re: Issues with \copy from file
  • From: Euler Taveira de Oliveira
• Re: sequential scan on child partition tables
  • From: Scott Marlowe
• Re: table full scan or index full scan?
  • From: Melton Low
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Scott Marlowe
• Re: table full scan or index full scan?
  • From: Euler Taveira de Oliveira
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Karl Denninger
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Tory M Blue
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Karl Denninger
• Re: Calculation of unused columns
  • From: Tom Lane
• Improving join performance over multiple moderately wide tables
  • From: miller_2555
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Torsten Zühlsdorff
• sequential scan on child partition tables
  • From: Anj Adu
• Re: Indexes on low cardinality columns
  • From: Vikul Khosla
• Issues with \copy from file
  • From: Sigurgeir Gunnarsson
• Performance with sorting and LIMIT on partitioned table
  • From: Michal Szymanski
• Re: Partitioned Tables and ORDER BY
  • From: Michal Szymanski
• Re: Domain vs table
  • From: Michal Szymanski
• Domain vs table
  • From: Michal Szymanski
• table full scan or index full scan?
  • From: 旭斌 裴
• Re: Partitioned Tables and ORDER BY
  • From: Michal Szymanski
• Re: Calculation of unused columns
  • From: Robert Haas
• Re: Calculation of unused columns
  • From: Tom Lane
• Re: Calculation of unused columns
  • From: Tom Lane
• Calculation of unused columns
  • From: Volker Grabsch
• Re: Indexes on low cardinality columns
  • From: Jeff Janes
• Re: Indexes on low cardinality columns
  • From: Robert Haas
• Re: Indexes on low cardinality columns
  • From: Vikul Khosla
• Re: UUID as primary key
  • From: decibel
• Re: Indexes on low cardinality columns
  • From: Greg Stark
• Indexes on low cardinality columns
  • From: Vikul Khosla
• Re: UUID as primary key
  • From: Alvaro Herrera
• Re: UUID as primary key
  • From: decibel
• Re: There is a statistic table?
  • From: Albe Laurenz
• Re: There is a statistic table?
  • From: Scott Marlowe
• There is a statistic table?
  • From: waldomiro
• Re: sequential scan on child partition tables
  • From: Anj Adu
• Regarding facing lot of time Consumed by Socket.Poll()
  • From: keshav upadhyaya
• [OT] Recommended whitebox server vendors in the UK?
  • From: Glyn Astill
• Re: sequential scan on child partition tables
  • From: Tom Lane
• sequential scan on child partition tables
  • From: Anj Adu
• Re: Getting a random row
  • From: Віталій Тимчишин
• Re: Getting a random row
  • From: Scott Marlowe
• Re: Getting a random row
  • From: Pavel Stehule
• Re: Getting a random row
  • From: Thom Brown
• Re: Getting a random row
  • From: Scott Marlowe
• Re: Getting a random row
  • From: bricklen
• Re: Getting a random row
  • From: Robert Haas
• Re: Getting a random row
  • From: Shaul Dar
• Re: Getting a random row
  • From: Grzegorz Jaśkiewicz
• Re: Getting a random row
  • From: Michael Glaesemann
• Re: Getting a random row
  • From: Shaul Dar
• Re: Getting a random row
  • From: Thomas Kellerer
• Re: Getting a random row
  • From: Grzegorz Jaśkiewicz
• Getting a random row
  • From: Shaul Dar
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Kenneth Marshall
• Re: index on two tables or Howto speedup max/aggregate-function
  • From: Grzegorz Jaśkiewicz
• Re: index on two tables or Howto speedup max/aggregate-function
  • From: Jacques Caron
• index on two tables or Howto speedup max/aggregate-function
  • From: Michael Schwipps
• Re: Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Scott Marlowe
• Are folks running 8.4 in production environments? and 8.4 and slon 1.2?
  • From: Tory M Blue
• Re: Best suiting OS
  • From: Dimitri Fontaine
• Re: Query performance
  • From: Grzegorz Jaśkiewicz
• Re: Query performance
  • From: S Arvind
• Re: Query performance
  • From: S Arvind
• Re: updating a row in a table with only one row
  • From: Merlin Moncure
• Re: Best suiting OS
  • From: Cédric Villemain
• Re: Query performance
  • From: Grzegorz Jaśkiewicz
• Re: Query performance
  • From: Matthew Wakeling
• Re: Query performance
  • From: Grzegorz Jaśkiewicz
• Re: Query performance
  • From: S Arvind
• Re: Query performance
  • From: Matthew Wakeling
• Re: Query performance
  • From: S Arvind
• Re: Query performance
  • From: Grzegorz Jaśkiewicz
• Query performance
  • From: S Arvind
• Re: updating a row in a table with only one row
  • From: Michal Vitecek
• Re: Using unnest function on multi-dimensional array.
  • From: Pavel Stehule
• Using unnest function on multi-dimensional array.
  • From: Nimesh Satam
• Re: table partitioning & max_locks_per_transaction
  • From: Brian Karlak
• Re: vacuumdb command
  • From: Heikki Linnakangas
• vacuumdb command
  • From: soorjith p
• Re: table partitioning & max_locks_per_transaction
  • From: Tom Lane
• Re: Databases vs Schemas
  • From: Scott Marlowe
• table partitioning & max_locks_per_transaction
  • From: Brian Karlak
• Re: UUID as primary key
  • From: Mark Mielke
• Re: Databases vs Schemas
  • From: Chris Kratz
• Re: Databases vs Schemas
  • From: Merlin Moncure
• Re: UUID as primary key
  • From: tsuraan
• Re: Databases vs Schemas
  • From: Tom Lane
• Re: Databases vs Schemas
  • From: Scott Carey
• Re: disk I/O problems and Solutions
  • From: Scott Carey
• Re: disk I/O problems and Solutions
  • From: David Rees
• Re: Databases vs Schemas
  • From: Merlin Moncure
• Re: disk I/O problems and Solutions
  • From: Scott Marlowe
• Re: disk I/O problems and Solutions
  • From: Flavio Henrique Araque Gurgel
• Re: UUID as primary key
  • From: Mark Mielke
• Re: Databases vs Schemas
  • From: Ben Chobot
• Databases vs Schemas
  • From: Scott Otis
• Re: concurrent reindex issues
  • From: Tory M Blue
• UUID as primary key
  • From: tsuraan
• disk I/O problems and Solutions
  • From: Alan McKay
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Merlin Moncure
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Kenneth Marshall
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Xia Qingran
• Re: Explain Analyze returns faster than psql or JDBC calls.
  • From: Dave Cramer
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: Explain Analyze returns faster than psql or JDBC calls.
  • From: Tom Lane
• Re: dump time increase by 1h with new kernel
  • From: Justin T Pryzby
• Re: dump time increase by 1h with new kernel
  • From: Kevin Grittner
• Explain Analyze returns faster than psql or JDBC calls.
  • From: G B
• Re: dump time increase by 1h with new kernel
  • From: Justin T Pryzby
• Re: concurrent reindex issues
  • From: Scott Marlowe
• Re: concurrent reindex issues
  • From: Tom Lane
• Re: dump time increase by 1h with new kernel
  • From: Joshua D. Drake
• Re: dump time increase by 1h with new kernel
  • From: Justin T Pryzby
• concurrent reindex issues
  • From: Tory M Blue
• Partitioned Tables and ORDER BY
  • From: Joe Uhl
• Re: position in DDL of columns used in indexes
  • From: Tom Lane
• Re: position in DDL of columns used in indexes
  • From: Matthew Wakeling
• position in DDL of columns used in indexes
  • From: Michael Gould
• Re: Best suiting OS
  • From: Matthew Wakeling
• Query logging time, not values
  • From: Ludwik Dylag
• Regarding mulitple rows insert in one shot using ADO .net connected to postgres
  • From: keshav upadhyaya
• Re: dump time increase by 1h with new kernel
  • From: Greg Smith
• Re: Query plan for NOT IN
  • From: Guy Rouillier
• Re: Query plan for NOT IN
  • From: Craig James
• Re: Query plan for NOT IN
  • From: Kevin Grittner
• Re: Query plan for NOT IN
  • From: Guy Rouillier
• Re: Query plan for NOT IN
  • From: Kevin Grittner
• Re: Query plan for NOT IN
  • From: Grzegorz Jaśkiewicz
• Re: Speed / Server
  • From: richard.henwood
• Re: Speed / Server
  • From: Greg Smith
• Re: Speed / Server
  • From: Anthony Presley
• Re: Speed / Server
  • From: Merlin Moncure
• Re: Speed / Server
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: Scott Mead
• Re: Speed / Server
  • From: Karl Denninger
• Re: Speed / Server
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: david
• Re: updating a row in a table with only one row
  • From: Craig James
• Re: updating a row in a table with only one row
  • From: Merlin Moncure
• Re: updating a row in a table with only one row
  • From: Michal Vitecek
• Re: Speed / Server
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Dumping + restoring a subset of a table?
  • From: Joshua Tolley
• Re: Speed / Server
  • From: Nikolas Everett
• Dumping + restoring a subset of a table?
  • From: Shaul Dar
• Re: What is the role of #fsync and #synchronous_commit in configuration file .
  • From: Dave Dutcher
• Re: Best suiting OS
  • From: Axel Rau
• What is the role of #fsync and #synchronous_commit in configuration file .
  • From: keshav upadhyaya
• Re: Distributed/Parallel Computing
  • From: Viji V Nair
• Re: Distributed/Parallel Computing
  • From: Jeff Janes
• Re: Maybe OT, not sure Re: Best suiting OS
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Speed / Server
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: Claus Guttesen
• Re: Best suiting OS
  • From: Axel Rau
• Re: Best suiting OS
  • From: Kevin Grittner
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Query plan for NOT IN
  • From: Guy Rouillier
• Distributed/Parallel Computing
  • From: Viji V Nair
• Re: Speed while runnning large transactions.
  • From: Greg Smith
• Re: Best suiting OS
  • From: Scott Carey
• Re: Best suiting OS
  • From: Greg Smith
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Best suiting OS
  • From: Axel Rau
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Best suiting OS
  • From: Scott Carey
• Re: Best suiting OS
  • From: Claus Guttesen
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Best suiting OS
  • From: Scott Carey
• Re: Performance RAID 0
  • From: Fernando Hevia
• Re: Best suiting OS
  • From: Stefan Kaltenbrunner
• Re: Best suiting OS
  • From: Stefan Kaltenbrunner
• Re: Query plan for NOT IN
  • From: Tom Lane
• Re: Query plan for NOT IN
  • From: Grzegorz Jaśkiewicz
• Re: Query plan for NOT IN
  • From: Matthew Wakeling
• Re: Query plan for NOT IN
  • From: Grzegorz Jaśkiewicz
• Query plan for NOT IN
  • From: Matthew Wakeling
• Re: [OT] Best suiting OS
  • From: Csaba Nagy
• Re: Best suiting OS
  • From: Adam Tauno Williams
• Re: Best suiting OS
  • From: Jean-David Beyer
• Re: Speed / Server
  • From: Nikolas Everett
• Re: Best suiting OS
  • From: Robert Haas
• Re: Maybe OT, not sure Re: Best suiting OS
  • From: Adam Tauno Williams
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Grzegorz Jaśkiewicz
• Re: Best suiting OS
  • From: Adam Tauno Williams
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Omar Kilani
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Robert Haas
• Re: updating a row in a table with only one row
  • From: Merlin Moncure
• Re: Best suiting OS
  • From: Devrim GÜNDÜZ
• Re: Best suiting OS
  • From: Devrim GÜNDÜZ
• Re: Best suiting OS
  • From: Jean-Michel Pouré
• Re: Best suiting OS
  • From: Devrim GÜNDÜZ
• Re: updating a row in a table with only one row
  • From: Michal Vitecek
• Re: Best suiting OS
  • From: Craig James
• Maybe OT, not sure Re: Best suiting OS
  • From: Mark Mielke
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Omar Kilani
• Re: Best suiting OS
  • From: Scott Marlowe
• Re: Speed / Server
  • From: Scott Marlowe
• Speed / Server
  • From: anthony
• Re: Best suiting OS
  • From: david
• Re: Best suiting OS
  • From: Gerhard Wiesinger
• Re: Best suiting OS
  • From: Mark Mielke
• Re: Confusion on shared buffer
  • From: Robert Haas
• Re: Best suiting OS
  • From: Devrim GÜNDÜZ
• Re: Best suiting OS
  • From: Mark Mielke
• Re: Confusion on shared buffer
  • From: Gurjeet Singh
• Re: Postgres performance
  • From: Gerd Koenig
• Re: dump time increase by 1h with new kernel
  • From: Scott Marlowe
• Re: Performance problems with DISTINCT ON
  • From: Tom Lane
• Re: Best suiting OS
  • From: Karl Denninger
• Re: Performance problems with DISTINCT ON
  • From: imad
• dump time increase by 1h with new kernel
  • From: Justin Pryzby
• Re: Best suiting OS
  • From: Jon Nelson
• Re: AMD, Intel and RAID controllers
  • From: Alpesh Gajbe
• Re: Best suiting OS
  • From: Denis Lussier
• Performance RAID 0
  • From: mange
• Re: PG 8.3 and large shared buffer settings
  • From: Hannu Krosing
• Performance problems with DISTINCT ON
  • From: Sgarbossa Domenico
• Re: Use of sequence rather than index scan for one text column on one instance of a database
  • From: Bill Kirtley
• Postgres performance
  • From: std pik
• Re: Confusion on shared buffer
  • From: Robert Haas
• Re: Confusion on shared buffer
  • From: S Arvind
• Re: dump time increase by 1h with new kernel
  • From: Tom Lane
• dump time increase by 1h with new kernel
  • From: Justin Pryzby
• Re: Speed while runnning large transactions.
  • From: Tom Lane
• Re: Best suiting OS
  • From: Dimitri Fontaine
• Re: Best suiting OS
  • From: Tom Lane
• Re: Speed while runnning large transactions.
  • From: Kevin Grittner
• Re: Confusion on shared buffer
  • From: Robert Haas
• Re: Best suiting OS
  • From: Mark Mielke
• Re: Best suiting OS
  • From: Kevin Grittner
• Re: updating a row in a table with only one row
  • From: Heikki Linnakangas
• Re: updating a row in a table with only one row
  • From: Merlin Moncure
• Re: Best suiting OS
  • From: Greg Smith
• Re: updating a row in a table with only one row
  • From: Robert Haas
• Re: Best suiting OS
  • From: Greg Smith
• Re: Best suiting OS
  • From: Merlin Moncure
• Re: Best suiting OS
  • From: Greg Smith
• Re: Best suiting OS
  • From: Jon Nelson
• Re: Best suiting OS - now off topic
  • From: Aidan Van Dyk
• Re: Best suiting OS
  • From: Mark Mielke
• Re: Best suiting OS
  • From: Joe Uhl
• Re: Best suiting OS
  • From: Matthew Wakeling
• Re: Best suiting OS
  • From: Tom Lane
• Re: updating a row in a table with only one row
  • From: Merlin Moncure
• Re: AMD, Intel and RAID controllers
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: Devrim GÜNDÜZ
• Re: Best suiting OS
  • From: Matthew Wakeling
• Re: updating a row in a table with only one row
  • From: Hélder M. Vieira
• Re: Best suiting OS
  • From: Scara Maccai
• Re: updating a row in a table with only one row
  • From: A. Kretschmer
• updating a row in a table with only one row
  • From: Michal Vitecek
• Re: Best suiting OS
  • From: Scara Maccai
• Re: AMD, Intel and RAID controllers
  • From: alpesh gajbe
• Re: long running insert statement
  • From: Gerd König
• Re: Best suiting OS
  • From: Scott Marlowe
• Re: Best suiting OS
  • From: david
• Re: AMD, Intel and RAID controllers
  • From: Greg Smith
• Re: Best suiting OS
  • From: Greg Smith
• Re: Best suiting OS
  • From: Greg Smith
• Re: Best suiting OS
  • From: S Arvind
• AMD, Intel and RAID controllers
  • From: Benjamin Minshall
• Re: Best suiting OS
  • From: Tom Lane
• Re: Speed while runnning large transactions.
  • From: Tom Lane
• Re: Best suiting OS
  • From: Haszlakiewicz, Eric
• Re: long running insert statement
  • From: Tom Lane
• Re: Database performance post-VACUUM FULL
  • From: Kevin Grittner
• Re: Best suiting OS
  • From: Claus Guttesen
• Re: Best suiting OS
  • From: S Arvind
• Re: long running insert statement
  • From: Matthew Wakeling
• Re: Best suiting OS
  • From: Jean-David Beyer
• Re: Best suiting OS
  • From: S Arvind
• Re: Speed while runnning large transactions.
  • From: Greg Smith
• Re: Best suiting OS
  • From: Jean-David Beyer
• Re: Best suiting OS
  • From: Matthew Wakeling
• Re: CPU cost of operators
  • From: Matthew Wakeling
• Best suiting OS
  • From: S Arvind
• Confusion on shared buffer
  • From: S Arvind
• long running insert statement
  • From: Gerd König
• Re: CPU cost of operators
  • From: Tom Lane
• Re: CPU cost of operators
  • From: Robert Haas
• Re: CPU cost of operators
  • From: Robert Haas
• CPU cost of operators
  • From: Matthew Wakeling
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Ivan Voras
• Re: FullTextSearch - UNION individual indexes or concatenated columns index ?
  • From: Josh Berkus
• Re: Speed while runnning large transactions.
  • From: Robert Haas
• FullTextSearch - UNION individual indexes or concatenated columns index ?
  • From: Jeremy Ferrante
• Re: Performance problems with DISTINCT ON
  • From: Scott Carey
• Re: Using OProfile
  • From: Tom Lane
• Re: Performance problems with DISTINCT ON
  • From: hubert depesz lubaczewski
• Re: Performance problems with DISTINCT ON
  • From: Sgarbossa Domenico
• Using OProfile
  • From: Reydan Cankur
• Re: Performance problems with DISTINCT ON
  • From: Richard Huxton
• Performance problems with DISTINCT ON
  • From: Sgarbossa Domenico
• Re: Postgres performance
  • From: Scott Marlowe
• Re: PG 8.3 and large shared buffer settings
  • From: Josh Berkus
• Re: Postgres performance
  • From: Andy Colson
• Re: LIMIT confuses the planner (again)
  • From: Robert Haas
• LIMIT confuses the planner (again)
  • From: Kouber Saparev
• Re: Regarding Sequential Scans count increase each time we press refresh .
  • From: Tom Lane
• Re: Slow query after upgrade to 8.4
  • From: Robert Haas
• Re: query memory consumption
  • From: Robert Haas
• Re: Regarding Sequential Scans count increase each time we press refresh .
  • From: Robert Haas
• Re: PG 8.3 and large shared buffer settings
  • From: Greg Smith
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Xia Qingran
• Re: Bad performance of SELECT ... where id IN (...)
  • From: Xia Qingran
• Re: Many left outer joins with limit performance
  • From: Gerhard Wiesinger
• Re: query memory consumption
  • From: Jeff Janes
• Re: PG 8.3 and large shared buffer settings
  • From: Jeff Janes
• Re: PG 8.3 and large shared buffer settings
  • From: Aidan Van Dyk
• Re: PG 8.3 and large shared buffer settings
  • From: Scott Carey
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Craig James
• Re: PG 8.3 and large shared buffer settings
  • From: Aidan Van Dyk
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Gerhard Wiesinger
• Re: PG 8.3 and large shared buffer settings
  • From: Dan Sugalski
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Grzegorz Jaśkiewicz
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Grzegorz Jaśkiewicz
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: PG 8.3 and large shared buffer settings
  • From: Tom Lane
• PG 8.3 and large shared buffer settings
  • From: Dan Sugalski
• Re: Regarding Sequential Scans count increase each time we press refresh .
  • From: Josh Berkus
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Craig James
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Karl Denninger
• Regarding Sequential Scans count increase each time we press refresh .
  • From: keshav upadhyaya
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Dave Dutcher
• Re: Use of sequence rather than index scan for one text column on one instance of a database
  • From: Tom Lane
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Karl Denninger
• Re: Use of sequence rather than index scan for one text column on one instance of a database
  • From: Tom Lane
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Andy Colson
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Praveen DS
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: Slow query after upgrade to 8.4
  • From: Jared Beck
• Re: Speed while runnning large transactions.
  • From: jesper
• Re: Speed while runnning large transactions.
  • From: jesper
• Re: Slow query after upgrade to 8.4
  • From: tv
• Re: Index row requires 9324 bytes maximum size is 8191
  • From: solAris23
• Re: Speed while runnning large transactions.
  • From: Scott Marlowe
• Re: Speed while runnning large transactions.
  • From: Grzegorz Jaśkiewicz
• Re: Speed while runnning large transactions.
  • From: Claus Guttesen
• Speed while runnning large transactions.
  • From: jesper
• Re: Different query plans for the same query
  • From: Hell, Robert
• Re: Use of sequence rather than index scan for one text column on one instance of a database
  • From: Tom Lane
• Re: Slow query after upgrade to 8.4
  • From: Tom Lane
• Use of sequence rather than index scan for one text column on one instance of a database
  • From: Bill Kirtley
• Slow query after upgrade to 8.4
  • From: Jared Beck
• Re: Slow query after upgrade to 8.4
  • From: Greg Williamson
• Slow query after upgrade to 8.4
  • From: Jared Beck
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Scott Marlowe
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Karl Denninger
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Fernando Hevia
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Andy Colson
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: statement stats extra load?
  • From: Magnus Hagander
• Re: Hunting Unused Indexes .. is it this simple ?
  • From: Josh Berkus
• Re: session servers in ram
  • From: Scott Marlowe
• Re: session servers in ram
  • From: Ron Mayer
• Re: session servers in ram
  • From: Alan Hodgson
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Fernando Hevia
• Re: Hunting Unused Indexes .. is it this simple ?
  • From: Andy Colson
• Re: Hunting Unused Indexes .. is it this simple ?
  • From: Gurjeet Singh
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Andy Colson
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Andy Colson
• Re: High CPU load on Postgres Server during Peak times!!!!
  • From: Merlin Moncure
• Hunting Unused Indexes .. is it this simple ?
  • From: Stef Telford
• High CPU load on Postgres Server during Peak times!!!!
  • From: Shiva Raman
• Re: statement stats extra load?
  • From: Alan McKay
• Re: session servers in ram
  • From: Aidan Van Dyk
• Re: session servers in ram
  • From: Pavel Stehule
• Re: query memory consumption
  • From: Grzegorz Jaśkiewicz
• Re: session servers in ram
  • From: Greg Spiegelberg
• Re: query memory consumption
  • From: Alan McKay
• Re: query memory consumption
  • From: Grzegorz Jaśkiewicz
• Re: query memory consumption
  • From: Alan McKay
• Re: Slow select times on select with xpath
  • From: Dimitri Fontaine
• Re: query memory consumption
  • From: Matthew Wakeling
• Re: statement stats extra load?
  • From: Magnus Hagander
• Re: Slow select times on select with xpath
  • From: Ron Mayer
• Re: Slow select times on select with xpath
  • From: astro77
• Re: Slow select times on select with xpath
  • From: astro77
• Re: Slow select times on select with xpath
  • From: astro77
• Re: slow query : very simple delete, 100% cpu, nearly no disk activity
  • From: Vincent de Phily
• Re: slow query : very simple delete, 100% cpu, nearly no disk activity
  • From: Vincent de Phily
• Re: slow query : very simple delete, 100% cpu, nearly no disk activity
  • From: Vincent de Phily
• session servers in ram
  • From: Scott Marlowe
• Re: statement stats extra load?
  • From: Bruce Momjian
• Re: statement stats extra load?
  • From: Alan McKay
• Re: Planner question - wrong row count estimation
  • From: Josh Berkus
• Re: statement stats extra load?
  • From: Bruce Momjian
• Re: query memory consumption
  • From: Robert Haas
• Re: How to post Performance Questions
  • From: Alvaro Herrera
• Re: slow query : very simple delete, 100% cpu, nearly no disk activity
  • From: Merlin Moncure
• query memory consumption
  • From: Alan McKay
• Re: Index row requires 9324 bytes maximum size is 8191
  • From: Florian Weimer
• Re: Index row requires 9324 bytes maximum size is 8191
  • From: Grzegorz Jaśkiewicz
• Re: Index row requires 9324 bytes maximum size is 8191
  • From: Pavel Stehule
• Re: Index row requires 9324 bytes maximum size is 8191
  • From: Euler Taveira de Oliveira
• Planner question - wrong row count estimation
  • From: Michael Korbakov
• Index row requires 9324 bytes maximum size is 8191
  • From: solAris23
• Re: noapic option
  • From: christian.storm
• Re: Possible causes of sometimes slow single-row UPDATE with trivial indexed condition?
  • From: Vlad Romascanu
• Planner question - wrong row count estimation
  • From: Michael Korbakov
• Re: Different query plans for the same query
  • From: Robert Haas
• Re: Different query plans for the same query
  • From: Tom Lane
• Re: Use of BETWEEN with identical values
  • From: Robert Haas
• Re: Database performance post-VACUUM FULL
  • From: Robert Haas
• Database performance post-VACUUM FULL
  • From: Karl Wright
• Re: Different query plans for the same query
  • From: Hell, Robert
• Re: Different query plans for the same query
  • From: tv
• Different query plans for the same query
  • From: Hell, Robert
• Re: Planner question - "bit" data types
  • From: Karl Denninger
• Re: Planner question - "bit" data types
  • From: Bruce Momjian
• Re: Planner question - "bit" data types
  • From: Bruce Momjian
• Re: Planner question - "bit" data types
  • From: Karl Denninger
• Re: Planner question - "bit" data types
  • From: Bruce Momjian
• Re: Use of BETWEEN with identical values
  • From: André Volpato
• Use of BETWEEN with identical values
  • From: André Volpato
• Re: optimizing for temporal data behind a view
  • From: Hrishikesh (हृषीकेश मेहेंदळे)
• Re: Possible causes of sometimes slow single-row UPDATE with trivial indexed condition?
  • From: Andy Colson
• Re: statistical table
  • From: Joshua Tolley
• Re: statistical table
  • From: Lennin Caro
• optimizing for temporal data behind a view
  • From: Richard Henwood
• Re: noapic option
  • From: Craig Ringer
• Re: Possible causes of sometimes slow single-row UPDATE with trivial indexed condition?
  • From: Richard Huxton
• statistical table
  • From: std pik
• noapic option
  • From: C Storm
• Possible causes of sometimes slow single-row UPDATE with trivial indexed condition?
  • From: Vlad Romascanu
• Re: CLUSTER and a problem
  • From: Grzegorz Jaśkiewicz
• Re: CLUSTER and a problem
  • From: Andrzej Zawadzki
• statement stats extra load?
  • From: Alan McKay
• Re: View vs Stored Proc Performance
  • From: Ivan Voras
• Re: disable heavily updated (but small) table auto-vecuuming
  • From: Robert Haas
• Re: View vs Stored Proc Performance
  • From: Tom Lane
• Re: View vs Stored Proc Performance
  • From: Ivan Voras
• Re: How to post Performance Questions
  • From: Kevin Grittner
• Problem with partitionning and orderby query plans
  • From: Gaël Le Mignot
• Re: CLUSTER and a problem
  • From: Andrzej Zawadzki
• Re: possible wrong query plan on pg 8.3.5,
  • From: zz_11
• Re: possible wrong query plan on pg 8.3.5,
  • From: Віталій Тимчишин
• Re: CLUSTER and a problem
  • From: Andrzej Zawadzki
• disable heavily updated (but small) table auto-vecuuming
  • From: Ludwik Dylag
• Re: How to post Performance Questions
  • From: Michael Glaesemann
• Re: CLUSTER and a problem
  • From: Tom Lane
• Re: CLUSTER and a problem
  • From: Andrzej Zawadzki
• How to post Performance Questions
  • From: Josh Berkus
• CLUSTER and a problem
  • From: Andrzej Zawadzki
• Re: CLUSTER and a problem
  • From: Josh Berkus
• Re: possible wrong query plan on pg 8.3.5,
  • From: zz_11
• Re: possible wrong query plan on pg 8.3.5,
  • From: zz_11
• Re: possible wrong query plan on pg 8.3.5,
  • From: Scott Marlowe
• Re: possible wrong query plan on pg 8.3.5,
  • From: Robert Haas
• CLUSTER and a problem
  • From: Andrzej Zawadzki
• Re: possible wrong query plan on pg 8.3.5,
  • From: zz_11
• Re: possible wrong query plan on pg 8.3.5,
  • From: Robert Haas
• Re: possible wrong query plan on pg 8.3.5,
  • From: zz_11
• Re: Persistent Plan Cache
  • From: Ivan Voras
• Re: possible wrong query plan on pg 8.3.5,
  • From: tv
• Re: Persistent Plan Cache
  • From: Dimitri Fontaine
• Re: possible wrong query plan on pg 8.3.5,
  • From: zz_11
• Re: Persistent Plan Cache
  • From: Heikki Linnakangas
• Re: Persistent Plan Cache
  • From: Joshua Rubin
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: Tom Lane
• Re: [PERFORMANCE] work_mem vs temp files issue
  • From: decibel
• Re: Persistent Plan Cache
  • From: Stephen Frost
• Re: Persistent Plan Cache
  • From: Heikki Linnakangas
• Re: possible wrong query plan on pg 8.3.5,
  • From: Tom Lane
• Re: Persistent Plan Cache
  • From: Tom Lane
• Persistent Plan Cache
  • From: Joshua Rubin
• possible wrong query plan on pg 8.3.5,
  • From: zz_11
• Re: View vs Stored Proc Performance
  • From: Merlin Moncure
• Re: View vs Stored Proc Performance
  • From: Dimitri Fontaine
• Re: slow query : very simple delete, 100% cpu, nearly no disk activity
  • From: Merlin Moncure
• Re: View vs Stored Proc Performance
  • From: Merlin Moncure
• Re: slow query : very simple delete, 100% cpu, nearly no disk activity
  • From: Robert Haas
• Re: View vs Stored Proc Performance
  • From: Jason Tesser
• Re: View vs Stored Proc Performance
  • From: Merlin Moncure
• Re: odd iostat graph
  • From: Greg Smith
• Re: odd iostat graph
  • From: Alan McKay
• Re: odd iostat graph
  • From: Greg Smith
• Re: View vs Stored Proc Performance
  • From: Jason Tesser
• Re: odd iostat graph
  • From: Kevin Grittner
• Re: odd iostat graph
  • From: Alan McKay
• Re: odd iostat graph
  • From: Scott Carey
• Re: View vs Stored Proc Performance
  • From: Merlin Moncure
• odd iostat graph
  • From: Alan McKay
• View vs Stored Proc Performance
  • From: Jason Tesser
• Re: PSQL 8.4 - partittions - join tables - not optimal plan
  • From: A. Kretschmer
• Re: Forcing postgresql to use an index
  • From: Eugene Morozov
• PSQL 8.4 - partittions - join tables - not optimal plan
  • From: Vratislav Benes
• Re: slow query : very simple delete, 100% cpu, nearly no disk activity
  • From: Vincent de Phily
• Re: Sub-optimal plan chosen
  • From: bricklen
• Re: Sub-optimal plan chosen
  • From: Tom Lane
• Re: Sub-optimal plan chosen
  • From: bricklen
• Re: Sub-optimal plan chosen
  • From: bricklen
• Re: Sub-optimal plan chosen
  • From: Robert Haas
• Re: Sub-optimal plan chosen
  • From: bricklen
• Re: Sub-optimal plan chosen
  • From: Robert Haas
• Re: Sub-optimal plan chosen
  • From: bricklen
• Re: Sub-optimal plan chosen
  • From: Tom Lane
• Re: Sub-optimal plan chosen
  • From: tv
• Re: Best Profiler for PostgreSQL
  • From: Robert Haas
• Re: Sub-optimal plan chosen
  • From: bricklen
• Re: Sub-optimal plan chosen
  • From: tv
• Sub-optimal plan chosen
  • From: bricklen
• Re: partitioning max() sql not using index
  • From: Kevin Kempter
• Re: partitioning max() sql not using index
  • From: Kenneth Cox
• Best Profiler for PostgreSQL
  • From: Reydan Cankur
• Re: partitioning max() sql not using index
  • From: Heikki Linnakangas
• Re: Forcing postgresql to use an index
  • From: Eugene Morozov
• partitioning max() sql not using index
  • From: Kevin Kempter
• Re: [GENERAL] [sfpug] Statistics and PostgreSQL: Streaming Webcast tonight
  • From: David Fetter
• Re: [sfpug] Statistics and PostgreSQL: Streaming Webcast tonight
  • From: David Fetter
• Statistics and PostgreSQL: Streaming Webcast tonight
  • From: David Fetter
• Re: Forcing postgresql to use an index
  • From: Scott Marlowe
• Re: Forcing postgresql to use an index
  • From: Kevin Grittner
• Re: Forcing postgresql to use an index
  • From: Grzegorz Jaśkiewicz
• Forcing postgresql to use an index
  • From: Eugene Morozov
• Re: Using Gprof with Postgresql
  • From: Craig James
• Re: Using Gprof with Postgresql
  • From: Pierre Frédéric Caillaud
• Re: Using Gprof with Postgresql
  • From: Reydan Cankur
• Re: Using Gprof with Postgresql
  • From: Reydan Cankur
• Re: Planner question - "bit" data types
  • From: Tom Lane
• Re: Planner question - "bit" data types
  • From: Robert Haas
• Re: Planner question - "bit" data types
  • From: Alvaro Herrera
• Re: Planner question - "bit" data types
  • From: Karl Denninger
• Re: Planner question - "bit" data types
  • From: Brian Cox
• Re: Planner question - "bit" data types
  • From: Robert Haas
• Re: Planner question - "bit" data types
  • From: Karl Denninger
• Re: Planner question - "bit" data types
  • From: Robert Haas
• Re: Planner question - "bit" data types
  • From: Fernando Hevia
• Re: Using Gprof with Postgresql
  • From: Tom Lane
• Re: Using Gprof with Postgresql
  • From: Jeff Janes
• Re: Using Gprof with Postgresql
  • From: Grzegorz Jaśkiewicz
• Using Gprof with Postgresql
  • From: Reydan Cankur
• Re: slow query : very simple delete, 100% cpu, nearly no disk activity
  • From: Tom Lane
• slow query : very simple delete, 100% cpu, nearly no disk activity
  • From: Vincent de Phily
• Re: Planner question - "bit" data types
  • From: Merlin Moncure
• Re: Planner question - "bit" data types
  • From: Karl Denninger
• Re: Planner question - "bit" data types
  • From: Alvaro Herrera
• Re: Planner question - "bit" data types
  • From: Karl Denninger
• Re: Planner question - "bit" data types
  • From: Tom Lane
• Re: Planner question - "bit" data types
  • From: Karl Denninger
• Re: Planner question - "bit" data types
  • From: Tom Lane
• Re: Planner question - "bit" data types
  • From: Karl Denninger
• Re: Planner question - "bit" data types
  • From: Tom Lane
• Re: Planner question - "bit" data types
  • From: Merlin Moncure
• Re: Planner question - "bit" data types
  • From: Josh Berkus
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Kevin Grittner
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Scott Otis
• Planner question - "bit" data types
  • From: Karl Denninger
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Magnus Hagander
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Claus Guttesen
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Scott Otis
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Scott Otis
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Robert Haas
• Re: PostgreSQL not using index for statement with group by
  • From: Scott Marlowe
• Re: SAAS and MySQL
  • From: Merlin Moncure
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Scott Otis
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Scott Otis
• Re: PostgreSQL not using index for statement with group by
  • From: Kevin Grittner
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Ivan Voras
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Robert Haas
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Andy Colson
• Re: Slow select times on select with xpath
  • From: Robert Haas
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Robert Haas
• Re: Slow select times on select with xpath
  • From: astro77
• Re: SAAS and MySQL
  • From: Tguru
• PostgreSQL not using index for statement with group by
  • From: Mark Starkman
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Andy Colson
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Scott Otis
• Re: Slow select times on select with xpath
  • From: Robert Haas
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Andy Colson
• Re: partition query using Seq Scan even when index is present
  • From: Kenneth Cox
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Andy Colson
• Re: Slow select times on select with xpath
  • From: Kevin Grittner
• Re: Seeking performance advice and explanation for high I/O on 8.3
  • From: Ivan Voras
• Re: partition query using Seq Scan even when index is present
  • From: Merlin Moncure
• Re: Help: how to speed up query after db server reboot
  • From: Tom Lane
• Re: pg_stat_activity.current_query explanation?
  • From: Joshua Tolley
• Re: Help: how to speed up query after db server reboot
  • From: Magnus Hagander
• Looking for real configuration data
  • From: Wei Zheng
• pg_stat_activity.current_query explanation?
  • From: Pat Chan
• Slow select times on select with xpath
  • From: astro77
• Help: how to speed up query after db server reboot
  • From: Wei Yan
• Seeking performance advice and explanation for high I/O on 8.3
  • From: Scott Otis
• Re: partition query using Seq Scan even when index is present
  • From: Greg Jaman
• partition query using Seq Scan even when index is present
  • From: Kenneth Cox
• Re: partition queries hitting all partitions even though check key is specified
  • From: Scott Carey
• Re: partition queries hitting all partitions even though check key is specified
  • From: Tom Lane
• Re: partition queries hitting all partitions even though check key is specified
  • From: Tom Lane
• Re: partition queries hitting all partitions even though check key is specified
  • From: Joshua D. Drake
• Re: partition queries hitting all partitions even though check key is specified
  • From: Kevin Kempter
• Re: partition queries hitting all partitions even though check key is specified
  • From: Greg Stark
• Re: partition queries hitting all partitions even though check key is specified
  • From: Tom Lane
• Re: partition queries hitting all partitions even though check key is specified
  • From: Greg Jaman
• Re: partition queries hitting all partitions even though check key is specified
  • From: bricklen
• Re: partition queries hitting all partitions even though check key is specified
  • From: Kevin Kempter
• Re: partition queries hitting all partitions even though check key is specified
  • From: Kevin Kempter
• Re: partition queries hitting all partitions even though check key is specified
  • From: Scott Marlowe
• Re: partition queries hitting all partitions even though check key is specified
  • From: Kenneth Marshall
• partition queries hitting all partitions even though check key is specified
  • From: Kevin Kempter
• Re: Performance issues with large amounts of time-series data
  • From: Hrishikesh (हृषीकेश मेहेंदळे)
• Re: moving data between tables causes the db to overwhelm the system
  • From: Robert Schnabel