Postgres Performance Date Index

• Thread Index

• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Scalability in postgres
  • From: Dimitri
• Re: poor performing plan from analyze vs. fast default plan pre-analyze on new database
  • From: Scott Carey
• Re: poor performing plan from analyze vs. fast default plan pre-analyze on new database
  • From: Tom Lane
• Re: poor performing plan from analyze vs. fast default plan pre-analyze on new database
  • From: Grzegorz Jaśkiewicz
• poor performing plan from analyze vs. fast default plan pre-analyze on new database
  • From: Davin Potts
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Best way to load test a postgresql server
  • From: Kenneth Cox
• Re: Best way to load test a postgresql server
  • From: Shaul Dar
• Re: Scalability in postgres
  • From: James Mansion
• Re: Best way to load test a postgresql server
  • From: Dimitri Fontaine
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Best way to load test a postgresql server
  • From: Shaul Dar
• Re: Best way to load test a postgresql server
  • From: Kenneth Cox
• Re: Using index for bitwise operations?
  • From: Matthew Wakeling
• Re: Very inefficient query plan with disjunction in WHERE clause
  • From: Matthew Wakeling
• Re: Very inefficient query plan with disjunction in WHERE clause
  • From: Matthew Wakeling
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Віталій Тимчишин
• Re: Best way to load test a postgresql server
  • From: Dimitri Fontaine
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Ron Mayer
• Re: Vacuuming technique doubt
  • From: Robert Haas
• Re: Vacuuming technique doubt
  • From: Kevin Grittner
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Unexpected query plan results
  • From: Dave Dutcher
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Scalability in postgres
  • From: Scott Carey
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Vacuuming technique doubt
  • From: S Arvind
• Re: Best way to load test a postgresql server
  • From: Alan McKay
• Re: Very inefficient query plan with disjunction in WHERE clause
  • From: Віталій Тимчишин
• Re: Using index for bitwise operations?
  • From: Tom Lane
• Re: Using index for bitwise operations?
  • From: Richard Huxton
• Very inefficient query plan with disjunction in WHERE clause
  • From: Koen Martens
• Best way to load test a postgresql server
  • From: Peter Sheats
• Using index for bitwise operations?
  • From: Shaul Dar
• Re: Vacuuming technique doubt
  • From: Greg Smith
• Re: degenerate performance on one server of 3
  • From: Tom Lane
• Re: Postgresql cache (memory) performance + how to warm up the cache
  • From: Greg Smith
• Re: Vacuuming technique doubt
  • From: David Rees
• Postgresql cache (memory) performance + how to warm up the cache
  • From: Shaul Dar
• Vacuuming technique doubt
  • From: S Arvind
• Re: degenerate performance on one server of 3
  • From: Erik Aronesty
• Re: degenerate performance on one server of 3
  • From: Tom Lane
• Re: degenerate performance on one server of 3
  • From: Craig Ringer
• Re: autovacuum hung?
  • From: Tom Lane
• Re: autovacuum hung?
  • From: Tom Lane
• Re: autovacuum hung?
  • From: Brian Cox
• Re: autovacuum hung?
  • From: Tom Lane
• Re: autovacuum hung?
  • From: Brian Cox
• Re: autovacuum hung?
  • From: Tom Lane
• Re: autovacuum hung?
  • From: Brian Cox
• Re: Scalability in postgres
  • From: Fabrix
• Re: degenerate performance on one server of 3
  • From: Tom Lane
• degenerate performance on one server of 3
  • From: Erik Aronesty
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Greg Smith
• Re: autovacuum hung?
  • From: Tom Lane
• Re: Scalability in postgres
  • From: Scott Carey
• Re: autovacuum hung?
  • From: Brian Cox
• Re: autovacuum hung?
  • From: Alvaro Herrera
• autovacuum hung?
  • From: Brian Cox
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Robert Haas
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Scalability in postgres
  • From: Scott Mead
• Re: Scalability in postgres
  • From: Fabrix
• Re: Unexpected query plan results
  • From: Scott Mead
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Scott Mead
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Fabrix
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Unexpected query plan results
  • From: Dave Dutcher
• Re: Unexpected query plan results
  • From: Anne Rosset
• Re: Unexpected query plan results
  • From: Dave Dutcher
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Grzegorz Jaśkiewicz
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Grzegorz Jaśkiewicz
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Grzegorz Jaśkiewicz
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Grzegorz Jaśkiewicz
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Flavio Henrique Araque Gurgel
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Fabrix
• Re: Scalability in postgres
  • From: Flavio Henrique Araque Gurgel
• Re: Continuent (was: Postgres Clustering)
  • From: Flavio Henrique Araque Gurgel
• Unexpected query plan results
  • From: Anne Rosset
• Re: Scalability in postgres
  • From: Fabrix
• Re: Scalability in postgres
  • From: Fabrix
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: Scott Mead
• Re: Scalability in postgres
  • From: Fabrix
• Re: Scalability in postgres
  • From: Scott Marlowe
• Re: Scalability in postgres
  • From: David Rees
• Re: Storing sensor data
  • From: Greg Jaman
• Re: Storing sensor data
  • From: Greg Jaman
• Scalability in postgres
  • From: Fabrix
• Re: Storing sensor data
  • From: Kenneth Marshall
• Continuent (was: Postgres Clustering)
  • From: Alan McKay
• Re: Storing sensor data
  • From: Grzegorz Jaśkiewicz
• Re: Storing sensor data
  • From: Alexander Staubo
• Re: Storing sensor data
  • From: Ivan Voras
• Re: Storing sensor data
  • From: Ivan Voras
• Re: Storing sensor data
  • From: Kenneth Marshall
• Re: Storing sensor data
  • From: Ivan Voras
• Re: Storing sensor data
  • From: Ivan Voras
• Re: Storing sensor data
  • From: Alexander Staubo
• Re: Storing sensor data
  • From: Nikolas Everett
• Re: Storing sensor data
  • From: Heikki Linnakangas
• Storing sensor data
  • From: Ivan Voras
• Re: Postgres Clustering
  • From: Alan McKay
• Re: Postgres Clustering
  • From: Dimitri Fontaine
• Re: Postgres Clustering
  • From: Eddy Ernesto Baños Fernández
• Re: Postgres Clustering
  • From: Daniel van Ham Colchete
• Re: Postgres Clustering
  • From: Scott Mead
• Re: Postgres Clustering
  • From: Thomas Kellerer
• Postgres Clustering
  • From: Alan McKay
• Re: Improve Query
  • From: Heikki Linnakangas
• Re: Improve Query
  • From: Zach Calvert
• Re: Improve Query
  • From: Grzegorz Jaśkiewicz
• Re: Improve Query
  • From: Zach Calvert
• Re: Improve Query
  • From: Nikolas Everett
• Re: Hosted servers with good DB disk performance?
  • From: Scott Mead
• Re: running bonnie++
  • From: Greg Smith
• Re: Hosted servers with good DB disk performance?
  • From: David Wall
• Re: Improve Query
  • From: Grzegorz Jaśkiewicz
• Improve Query
  • From: Zach Calvert
• Re: Hosted servers with good DB disk performance?
  • From: Joshua D. Drake
• Re: running bonnie++
  • From: Glyn Astill
• running bonnie++
  • From: Alan McKay
• L
  • From: Thomas Kellerer
• Re: Bytea updation
  • From: Albe Laurenz
• Re: Hosted servers with good DB disk performance?
  • From: Dimitri Fontaine
• [no subject]
  • From: ramasubramanian
• Bytea updation
  • From: ramasubramanian
• Re: Hosted servers with good DB disk performance?
  • From: Alex Adriaanse
• Re: Hosted servers with good DB disk performance?
  • From: Erik Aronesty
• Re: Hosted servers with good DB disk performance?
  • From: Ron Mayer
• Re: Hosted servers with good DB disk performance?
  • From: Greg Smith
• Re: Hosted servers with good DB disk performance?
  • From: Scott Marlowe
• Re: Hosted servers with good DB disk performance?
  • From: Scott Carey
• Re: Hosted servers with good DB disk performance?
  • From: Scott Carey
• Re: Problems with autovacuum
  • From: Scott Marlowe
• Re: Hosted servers with good DB disk performance?
  • From: Scott Marlowe
• Re: Hosted servers with good DB disk performance?
  • From: Scott Carey
• Re: Hosted servers with good DB disk performance?
  • From: Josh Berkus
• Re: Hosted servers with good DB disk performance?
  • From: Greg Smith
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Hosted servers with good DB disk performance?
  • From: Dave Page
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Hosted servers with good DB disk performance?
  • From: Joshua D. Drake
• Re: Hosted servers with good DB disk performance?
  • From: Jerry Champlin
• Re: Hosted servers with good DB disk performance?
  • From: Marcin Stępnicki
• Re: Hosted servers with good DB disk performance?
  • From: Craig James
• Hosted servers with good DB disk performance?
  • From: Greg Smith
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Łukasz Jagiełło
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Putting tables or indexes in SSD or RAM: avoiding double caching?
  • From: Kenny Gorman
• Re: Problems with autovacuum
  • From: Grzegorz Jaśkiewicz
• Re: Problems with autovacuum
  • From: Łukasz Jagiełło
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Łukasz Jagiełło
• Re: Problems with autovacuum
  • From: Łukasz Jagiełło
• Re: Problems with autovacuum
  • From: Scott Marlowe
• Re: Problems with autovacuum
  • From: Grzegorz Jaśkiewicz
• Re: Problems with autovacuum
  • From: Scott Marlowe
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Putting tables or indexes in SSD or RAM: avoiding double caching?
  • From: Shaul Dar
• Problems with autovacuum
  • From: Łukasz Jagiełło
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: Full statement logging problematic on larger machines?
  • From: Frank Joerdens
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: raid10 hard disk choice
  • From: Robert Schnabel
• Re: raid10 hard disk choice
  • From: Greg Smith
• Re: raid10 hard disk choice
  • From: Scott Marlowe
• Re: raid10 hard disk choice
  • From: Greg Smith
• Re: raid10 hard disk choice
  • From: Robert Schnabel
• Re: raid10 hard disk choice
  • From: Linos
• Re: raid10 hard disk choice
  • From: Greg Smith
• Re: raid10 hard disk choice
  • From: Greg Smith
• Re: raid10 hard disk choice
  • From: Scott Carey
• Re: raid10 hard disk choice
  • From: Robert Haas
• Re: raid10 hard disk choice
  • From: Scott Carey
• Re: raid10 hard disk choice
  • From: Scott Marlowe
• Re: raid10 hard disk choice
  • From: Robert Haas
• Re: raid10 hard disk choice
  • From: Craig James
• Re: raid10 hard disk choice
  • From: Scott Marlowe
• Re: raid10 hard disk choice
  • From: Joshua D. Drake
• Re: query planner uses sequencial scan instead of index scan
  • From: Tom Lane
• Re: raid10 hard disk choice
  • From: Robert Schnabel
• Re: raid10 hard disk choice
  • From: Merlin Moncure
• Re: raid10 hard disk choice
  • From: Matthew Wakeling
• raid10 hard disk choice
  • From: Linos
• query planner uses sequencial scan instead of index scan
  • From: Daniel Ferreira
• PQisBusy behaving strangely
  • From: Richard Yen
• Re: postgresql.conf suggestions?
  • From: Greg Smith
• Re: postgresql.conf suggestions?
  • From: Robert Haas
• postgresql.conf suggestions?
  • From: Kobby Dapaah
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dave Dutcher
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: superlative missuse
  • From: Craig James
• Re: superlative missuse
  • From: David Wilson
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: UNION ALL and sequential scans
  • From: Tom Lane
• Re: UNION ALL and sequential scans
  • From: Mathieu De Zutter
• Re: UNION ALL and sequential scans
  • From: Tom Lane
• UNION ALL and sequential scans
  • From: Brad Jorsch
• Re: increase index performance
  • From: Ow Mun Heng
• Re: increase index performance
  • From: Matthew Wakeling
• Re: AMD Shanghai versus Intel Nehalem
  • From: Greg Smith
• Re: increase index performance
  • From: Ow Mun Heng
• Re: AMD Shanghai versus Intel Nehalem
  • From: Arjen van der Meijden
• Re: Any better plan for this query?..
  • From: Dimitri Fontaine
• Re: increase index performance
  • From: Thomas Finneid
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: superlative missuse
  • From: Angel Alvarez
• Re: superlative missuse
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Kevin Grittner
• Re: superlative missuse
  • From: Chris Browne
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Greg Stark
• Re: Any better plan for this query?..
  • From: Kevin Grittner
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Stefan Kaltenbrunner
• Re: increase index performance
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Timestamp index not used in some cases
  • From: Евгений Василев
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: raid setup for db
  • From: Thomas Finneid
• Re: raid setup for db
  • From: Rafael Martinez
• Re: AMD Shanghai versus Intel Nehalem
  • From: Arjen van der Meijden
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Marlowe
• Re: raid setup for db
  • From: Scott Marlowe
• Re: increase index performance
  • From: Thomas Finneid
• raid setup for db
  • From: Thomas Finneid
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Marlowe
• Re: Any better plan for this query?..
  • From: Glenn Maynard
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: AMD Shanghai versus Intel Nehalem
  • From: Scott Marlowe
• Re: Any better plan for this query?..
  • From: Stephen Frost
• Re: AMD Shanghai versus Intel Nehalem
  • From: Greg Smith
• Re: increase index performance
  • From: Greg Smith
• Re: Any better plan for this query?..
  • From: Aidan Van Dyk
• Re: Any better plan for this query?..
  • From: Joshua D. Drake
• Re: superlative missuse
  • From: David Wilson
• superlative missuse
  • From: Angel Alvarez
• Re: Any better plan for this query?..
  • From: Greg Stark
• Re: Any better plan for this query?..
  • From: Alvaro Herrera
• increase index performance
  • From: Thomas Finneid
• Re: Any better plan for this query?..
  • From: Robert Haas
• AMD Shanghai versus Intel Nehalem
  • From: Scott Marlowe
• Re: Query planner making bad decisions
  • From: Rafael Martinez
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: Any better plan for this query?..
  • From: Joshua D. Drake
• Re: Any better plan for this query?..
  • From: Scott Carey
• Re: Any better plan for this query?..
  • From: Dimitri Fontaine
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Alvaro Herrera
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Joshua D. Drake
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Kevin Grittner
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Stefan Kaltenbrunner
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Robert Haas
• Re: Any better plan for this query?..
  • From: Stefan Kaltenbrunner
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Julian v. Bock
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Stefan Kaltenbrunner
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Query planner making bad decisions
  • From: Cory Coager
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Heikki Linnakangas
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Timestamp index not used in some cases
  • From: Scott Marlowe
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Laurent Laborde
• Timestamp index not used in some cases
  • From: Евгений Василев
• Re: Any better plan for this query?..
  • From: Dimitri Fontaine
• Re: Any better plan for this query?..
  • From: Andres Freund
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Heikki Linnakangas
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Scott Marlowe
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Greg Smith
• Re: Query planner making bad decisions
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Alvaro Herrera
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Query planner making bad decisions
  • From: Cory Coager
• Re: Any better plan for this query?..
  • From: Aidan Van Dyk
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Scott Marlowe
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Kevin Grittner
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Kevin Grittner
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: What is the most optimal config parameters to keep stable write TPS ?..
  • From: Kevin Grittner
• What is the most optimal config parameters to keep stable write TPS ?..
  • From: Dimitri
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Stefan Kaltenbrunner
• Re: Any better plan for this query?..
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: PFC
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Paolo Rizzi
• Reminder: Please Respond to Rohan's Invitation
  • From: Rohan Pethkar
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Laurent Wandrebeck
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: Transparent table partitioning in future version of PG?
  • From: Craig Ringer
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Tom Lane
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Paolo Rizzi
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: PFC
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Paolo Rizzi
• Re: Transparent table partitioning in future version of PG?
  • From: Tom Lane
• Re: Transparent table partitioning in future version of PG?
  • From: Robert Haas
• Re: Transparent table partitioning in future version of PG?
  • From: Scott Carey
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Fernando Hevia
• Re: Transparent table partitioning in future version of PG?
  • From: david
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Paolo Rizzi
• Re: Transparent table partitioning in future version of PG?
  • From: Scott Carey
• Re: PostgreSQL with PostGIS on embedded hardware
  • From: Joshua D. Drake
• Re: Transparent table partitioning in future version of PG?
  • From: Robert Haas
• Re: Statistics use with functions
  • From: Tom Lane
• PostgreSQL with PostGIS on embedded hardware
  • From: Paolo Rizzi
• Re: Statistics use with functions
  • From: Matthew Wakeling
• Re: Statistics use with functions
  • From: Tom Lane
• Statistics use with functions
  • From: Matthew Wakeling
• Re: Indexes not used in DELETE
  • From: Viktor Rosenfeld
• Rohan Pethkar sent you a Friend Request on Yaari
  • From: Rohan Pethkar
• Re: Transparent table partitioning in future version of PG?
  • From: david
• Re: Transparent table partitioning in future version of PG?
  • From: Robert Haas
• Re: Indexes not used in DELETE
  • From: Tom Lane
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Indexes not used in DELETE
  • From: Viktor Rosenfeld
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Bad Plan for Questionnaire-Type Query
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Transparent table partitioning in future version of PG?
  • From: Scott Carey
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Nikolas Everett
• Re: Any better plan for this query?..
  • From: Alvaro Herrera
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Matthew Wakeling
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Nikolas Everett
• Re: Slow select performance despite seemingly reasonable query plan
  • From: David Brain
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Matthew Wakeling
• Re: Slow select performance despite seemingly reasonable query plan
  • From: David Brain
• Re: Slow select performance despite seemingly reasonable query plan
  • From: Scott Mead
• Slow select performance despite seemingly reasonable query plan
  • From: David Brain
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Gregory Stark
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: GiST index performance
  • From: Oleg Bartunov
• Re: Transparent table partitioning in future version of PG?
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Transparent table partitioning in future version of PG?
  • From: Craig Ringer
• Re: Transparent table partitioning in future version of PG?
  • From: Alvaro Herrera
• Re: Transparent table partitioning in future version of PG?
  • From: Tom Lane
• Re: Transparent table partitioning in future version of PG?
  • From: Simon Riggs
• Re: GiST index performance
  • From: Tom Lane
• Re: Transparent table partitioning in future version of PG?
  • From: Tom Lane
• Re: Any better plan for this query?..
  • From: Simon Riggs
• Re: Transparent table partitioning in future version of PG?
  • From: Simon Riggs
• Re: Any better plan for this query?..
  • From: Kenneth Marshall
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Kenneth Marshall
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Kenneth Marshall
• Re: Any better plan for this query?..
  • From: Craig Ringer
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Ries van Twisk
• Re: Any better plan for this query?..
  • From: Kenneth Marshall
• Re: Any better plan for this query?..
  • From: Kenneth Marshall
• Re: Any better plan for this query?..
  • From: Richard Huxton
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Albe Laurenz
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: Any better plan for this query?..
  • From: Merlin Moncure
• Re: Any better plan for this query?..
  • From: Matthew Wakeling
• Re: Any better plan for this query?..
  • From: Richard Huxton
• Re: Any better plan for this query?..
  • From: Richard Huxton
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Chris
• Re: Any better plan for this query?..
  • From: Heikki Linnakangas
• Re: Any better plan for this query?..
  • From: Dimitri
• Re: Any better plan for this query?..
  • From: Craig Ringer
• Any better plan for this query?..
  • From: Dimitri
• Re: Limit I/O bandwidth of a certain backend
  • From: Greg Smith
• Re: Limit I/O bandwidth of a certain backend
  • From: Bryan Murphy
• Re: [HACKERS] high shared buffer and swap
  • From: Matthew Wakeling
• Re: [HACKERS] high shared buffer and swap
  • From: Laurent Laborde
• Re: [HACKERS] high shared buffer and swap
  • From: PFC
• Limit I/O bandwidth of a certain backend
  • From: Vlad Arkhipov
• Re: high shared buffer and swap
  • From: Scott Marlowe
• Re: [HACKERS] high shared buffer and swap
  • From: Martijn van Oosterhout
• Re: high shared buffer and swap
  • From: Greg Stark
• high shared buffer and swap
  • From: Laurent Laborde
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: PFC
• Re: Transparent table partitioning in future version of PG?
  • From: Scott Carey
• Re: Many left outer joins with limit performance
  • From: Tom Lane
• Re: bad plan and LIMIT
  • From: James Nelson
• Re: Transparent table partitioning in future version of PG?
  • From: Robert Haas
• Re: bad plan and LIMIT
  • From: James Nelson
• Re: bad plan and LIMIT
  • From: James Nelson
• Re: bad plan and LIMIT
  • From: Tom Lane
• Transparent table partitioning in future version of PG?
  • From: henk de wit
• Many left outer joins with limit performance
  • From: Gerhard Wiesinger
• Re: bad plan and LIMIT
  • From: Grzegorz Jaśkiewicz
• Re: bad plan and LIMIT
  • From: Grzegorz Jaśkiewicz
• Re: bad plan and LIMIT
  • From: Adam Ruth
• bad plan and LIMIT
  • From: James Nelson
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Scott Carey
• Re: partition question for new server setup
  • From: Scott Carey
• Re: partition question for new server setup
  • From: Scott Carey
• Re: partition question for new server setup
  • From: Scott Marlowe
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Scott Carey
• Re: partition question for new server setup
  • From: Scott Carey
• Re: pg_lock_status() performance
  • From: Tom Lane
• Re: pg_lock_status() performance
  • From: Merlin Moncure
• Re: pg_lock_status() performance
  • From: Merlin Moncure
• Re: pg_lock_status() performance
  • From: Tom Lane
• Re: partition question for new server setup
  • From: Scott Marlowe
• Re: partition question for new server setup
  • From: Scott Marlowe
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Scott Marlowe
• Re: partition question for new server setup
  • From: Kevin Grittner
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Kenneth Marshall
• Re: partition question for new server setup
  • From: Kevin Grittner
• Re: partition question for new server setup
  • From: Craig James
• Re: partition question for new server setup
  • From: Alan Hodgson
• Re: partition question for new server setup
  • From: Craig James
• Re: partition question for new server setup
  • From: Kenneth Marshall
• Re: partition question for new server setup
  • From: Scott Marlowe
• pg_lock_status() performance
  • From: Merlin Moncure
• Re: partition question for new server setup
  • From: Whit Armstrong
• Re: partition question for new server setup
  • From: Scott Marlowe
• partition question for new server setup
  • From: Whit Armstrong
• any interest of changing the page size ?
  • From: Laurent Laborde
• Re: plpgsql function running long, but resources consumption is very low
  • From: Scott Carey
• Re: Using IOZone to simulate DB access patterns
  • From: Laurent Laborde
• Re: plpgsql function running long, but resources consumption is very low
  • From: Pavel Stehule
• plpgsql function running long, but resources consumption is very low
  • From: Wojtek
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Scott Marlowe
• Re: performance for high-volume log insertion
  • From: Kris Jurka
• Re: performance for high-volume log insertion
  • From: Scott Marlowe
• Re: Using IOZone to simulate DB access patterns
  • From: Mark Wong
• Re: Using IOZone to simulate DB access patterns
  • From: Mark Wong
• Re: performance for high-volume log insertion
  • From: Thomas
• Re: performance for high-volume log insertion
  • From: Kris Jurka
• [no subject]
  • From: Adam Ruth
• Re: performance for high-volume log insertion
  • From: Thomas Kellerer
• Re: WHERE condition not being pushed down to union parts
  • From: Tom Lane
• Re: WHERE condition not being pushed down to union parts
  • From: John L. Clark
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: Joshua D. Drake
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: performance for high-volume log insertion
  • From: James Mansion
• Re: performance for high-volume log insertion
  • From: Tom Lane
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Glenn Maynard
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: performance for high-volume log insertion
  • From: Simon Riggs
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: probelm with alter table add constraint......
  • From: roopabenzer
• Re: performance for high-volume log insertion
  • From: James Mansion
• Re: performance for high-volume log insertion
  • From: Robert Haas
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Greg Smith
• Re: WHERE condition not being pushed down to union parts
  • From: Tom Lane
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: James Mansion
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Kenneth Marshall
• Re: WHERE condition not being pushed down to union parts
  • From: John L. Clark
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Greg Smith
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Ben Chobot
• Re: SQL With Dates
  • From: Robert Haas
• Re: performance for high-volume log insertion
  • From: Kenneth Marshall
• Re: performance for high-volume log insertion
  • From: david
• Re: WHERE condition not being pushed down to union parts
  • From: Tom Lane
• Re: WHERE condition not being pushed down to union parts
  • From: John L. Clark
• Re: WHERE condition not being pushed down to union parts
  • From: Tom Lane
• WHERE condition not being pushed down to union parts
  • From: John L. Clark
• Re: performance for high-volume log insertion
  • From: Kenneth Marshall
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: performance for high-volume log insertion
  • From: Richard Huxton
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: Greg Smith
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• Re: performance for high-volume log insertion
  • From: david
• Re: performance for high-volume log insertion
  • From: Stephen Frost
• performance for high-volume log insertion
  • From: david
• Re: SQL With Dates
  • From: Mark Lewis
• Re: SQL With Dates
  • From: Scott Marlowe
• Re: SQL With Dates
  • From: Rafael Domiciano
• Re: GiST index performance
  • From: Tom Lane
• Re: SQL With Dates
  • From: Grzegorz Jaśkiewicz
• Re: GiST index performance
  • From: Matthew Wakeling
• SQL With Dates
  • From: Rafael Domiciano
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: stats are way off on 8.4 b1
  • From: Grzegorz Jaśkiewicz
• Re: stats are way off on 8.4 b1
  • From: Heikki Linnakangas
• Re: stats are way off on 8.4 b1
  • From: Grzegorz Jaśkiewicz
• Re: stats are way off on 8.4 b1
  • From: Tom Lane
• stats are way off on 8.4 b1
  • From: Grzegorz Jaśkiewicz
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: No hash join across partitioned tables?
  • From: Kris Jurka
• Re: No hash join across partitioned tables?
  • From: Kris Jurka
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Optimizer's issue
  • From: Vlad Arkhipov
• Re: GiST index performance
  • From: Craig Ringer
• Re: No hash join across partitioned tables?
  • From: Kris Jurka
• Re: No hash join across partitioned tables?
  • From: Kris Jurka
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• No hash join across partitioned tables?
  • From: Kris Jurka
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Tom Lane
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Tom Lane
• Re: GiST index performance
  • From: dforum
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Tom Lane
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Kevin Grittner
• GiST index performance
  • From: Matthew Wakeling
• Re: Really dumb planner decision
  • From: Tom Lane
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Tom Lane
• Re: Really dumb planner decision
  • From: Matthew Wakeling
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Lists
• Re: Really dumb planner decision
  • From: Robert Haas
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Tom Lane
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Tom Lane
• Re: Really dumb planner decision
  • From: Merlin Moncure
• Re: Really dumb planner decision
  • From: Kevin Grittner