Postgres Performance Date Index

• Thread Index

• Re: analyzing intermediate query
  • From: PFC
• analyzing intermediate query
  • From: Andrus
• Re: Sort causes system to freeze
  • From: PFC
• Re: Sort causes system to freeze
  • From: Tom Lane
• Re: Sort causes system to freeze
  • From: Richard Huxton
• Experience with HP Smart Array P400 and SATA drives?
  • From: Mario Weilguni
• Context switch storms
  • From: Omar Kilani
• Re: Sort causes system to freeze
  • From: Craig James
• Sort causes system to freeze
  • From: Craig James
• Re: Query optimization
  • From: PFC
• Seq scan over 3.3 millions of rows instead of using date and pattern indexes
  • From: Andrus
• Re: Query optimization
  • From: Marc Cousin
• Query optimization
  • From: tmp
• Re: Increasing GROUP BY CHAR columns speed
  • From: Greg Stark
• Re: Increasing GROUP BY CHAR columns speed
  • From: Andrus
• Re: Memory Allocation
  • From: Kevin Grittner
• Re: Increasing GROUP BY CHAR columns speed
  • From: Andrus
• Re: Increasing GROUP BY CHAR columns speed
  • From: Scott Marlowe
• Re: Increasing GROUP BY CHAR columns speed
  • From: Andrus
• Re: Increasing GROUP BY CHAR columns speed
  • From: Andrus
• Re: Increasing GROUP BY CHAR columns speed
  • From: Scott Carey
• Re: Increasing GROUP BY CHAR columns speed
  • From: Scott Marlowe
• Re: Increasing GROUP BY CHAR columns speed
  • From: Andrus
• Re: Increasing GROUP BY CHAR columns speed
  • From: Scott Carey
• Re: Deteriorating performance when loading large objects
  • From: Vegard Bønes
• Increasing GROUP BY CHAR columns speed
  • From: Andrus
• Re: Increasing pattern index query speed
  • From: Andrus
• Re: Deteriorating performance when loading large objects
  • From: Mario Weilguni
• Re: Deteriorating performance when loading large objects
  • From: Tom Lane
• Re: Deteriorating performance when loading large objects
  • From: Vegard Bønes
• Re: Partition table query performance
  • From: Greg Jaman
• Re: many to many performance
  • From: Chavdar Kopoev
• Re: performance tuning queries
  • From: Mario Weilguni
• Re: performance tuning queries
  • From: A. Kretschmer
• Re: performance tuning queries
  • From: PFC
• performance tuning queries
  • From: Kevin Kempter
• Re: Partition table query performance
  • From: Gregory Stark
• Re: Memory Allocation
  • From: Scott Carey
• Re: Memory Allocation
  • From: Kevin Grittner
• Re: Memory Allocation
  • From: Scott Carey
• Re: Memory Allocation
  • From: Tom Lane
• Re: Memory Allocation
  • From: Carlos Moreno
• Re: Increasing pattern index query speed
  • From: Scott Carey
• Re: Memory Allocation
  • From: Alan Hodgson
• Memory Allocation
  • From: Ryan Hansen
• Re: Increasing pattern index query speed
  • From: Richard Huxton
• Re: Increasing pattern index query speed
  • From: Andrus
• Re: Increasing pattern index query speed
  • From: Andrus
• Re: Increasing pattern index query speed
  • From: Richard Huxton
• many to many performance
  • From: Chavdar Kopoev
• Re: Increasing pattern index query speed
  • From: Andrus
• Re: Increasing pattern index query speed
  • From: Andrus
• Re: Increasing pattern index query speed
  • From: Richard Huxton
• Re: Increasing pattern index query speed
  • From: Andrus
• Re: many to many performance
  • From: Craig Ringer
• many to many performance
  • From: Chavdar Kopoev
• Re: Increasing pattern index query speed
  • From: Mario Weilguni
• Re: Increasing pattern index query speed
  • From: Richard Huxton
• Partition table query performance
  • From: Greg Jaman
• Re: Monitoring buffercache...
  • From: Mark Kirkwood
• Re: Deteriorating performance when loading large objects
  • From: Tom Lane
• Re: Deteriorating performance when loading large objects
  • From: Ivan Voras
• Deteriorating performance when loading large objects
  • From: Vegard Bønes
• Re: Monitoring buffercache...
  • From: Scott Marlowe
• Re: Monitoring buffercache...
  • From: Greg Smith
• Re: Monitoring buffercache...
  • From: Greg Smith
• Re: limit clause produces wrong query plan
  • From: Scott Carey
• Re: limit clause produces wrong query plan
  • From: PFC
• Re: Increasing pattern index query speed
  • From: Scott Carey
• Re: limit clause produces wrong query plan
  • From: Chris
• Re: Monitoring buffercache...
  • From: Scott Marlowe
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Increasing pattern index query speed
  • From: Andrus
• Re: limit clause produces wrong query plan
  • From: Andrus
• Re: Monitoring buffercache...
  • From: Brad Nicholson
• Re: Monitoring buffercache...
  • From: Scott Marlowe
• Re: Monitoring buffercache...
  • From: Brad Nicholson
• Re: limit clause produces wrong query plan
  • From: Scott Marlowe
• Re: limit clause produces wrong query plan
  • From: Andrus
• Monitoring buffercache...
  • From: Kevin Kempter
• Re: Perc 3 DC
  • From: PFC
• Re: Perc 3 DC
  • From: Scott Marlowe
• Re: Perc 3 DC
  • From: Simon Waters
• Re: Perc 3 DC
  • From: Scott Marlowe
• Re: Perc 3 DC
  • From: Glyn Astill
• Re: Perc 3 DC
  • From: Scott Marlowe
• Re: Perc 3 DC
  • From: Glyn Astill
• Re: Hash join on int takes 8..114 seconds
  • From: tv
• Re: Perc 3 DC
  • From: Steve Clark
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Increasing pattern index query speed
  • From: Richard Huxton
• Re: Hash join on int takes 8..114 seconds
  • From: Tomas Vondra
• Re: Hash join on int takes 8..114 seconds
  • From: Tomas Vondra
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• limit clause produces wrong query plan
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: Scott Carey
• Re: Hash join on int takes 8..114 seconds
  • From: Tomas Vondra
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: seq scan over 3.3 million rows instead of single keyindex access
  • From: Andrus
• Re: seq scan over 3.3 million rows instead of single key index access
  • From: A. Kretschmer
• Re: seq scan over 3.3 million rows instead of single key index access
  • From: Andreas Kretschmer
• Re: seq scan over 3.3 million rows instead of single key index access
  • From: Andreas Kretschmer
• Re: Hash join on int takes 8..114 seconds
  • From: PFC
• Re: seq scan over 3.3 million rows instead of single key index access
  • From: Andrus
• Re: seq scan over 3.3 million rows instead of single key index access
  • From: Tom Lane
• Re: seq scan over 3.3 million rows instead of single key index access
  • From: Gregory Stark
• Re: Perc 3 DC
  • From: Glyn Astill
• Increasing pattern index query speed
  • From: Andrus
• seq scan over 3.3 million rows instead of single key index access
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Perc 3 DC
  • From: Scott Marlowe
• Re: Hash join on int takes 8..114 seconds
  • From: PFC
• Re: Perc 3 DC
  • From: Glyn Astill
• Re: Perc 3 DC
  • From: Scott Marlowe
• Perc 3 DC
  • From: Glyn Astill
• Re: Hash join on int takes 8..114 seconds
  • From: Scott Carey
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: Tomas Vondra
• Re: Hash join on int takes 8..114 seconds
  • From: Tomas Vondra
• Re: Hash join on int takes 8..114 seconds
  • From: Alvaro Herrera
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: Tom Lane
• Re: Hash join on int takes 8..114 seconds
  • From: Alvaro Herrera
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: Alvaro Herrera
• Re: Hash join on int takes 8..114 seconds
  • From: Alan Hodgson
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: PFC
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: PFC
• Re: Hash join on int takes 8..114 seconds
  • From: PFC
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: Richard Huxton
• Re: Hash join on int takes 8..114 seconds
  • From: tv
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Performance and IN clauses
  • From: Tomas Vondra
• Re: Hash join on int takes 8..114 seconds
  • From: PFC
• Re: Hash join on int takes 8..114 seconds
  • From: Richard Huxton
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Hash join on int takes 8..114 seconds
  • From: Richard Huxton
• Re: Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Very Urgent : Sequences Problem
  • From: Greg Smith
• Re: Hash join on int takes 8..114 seconds
  • From: PFC
• Hash join on int takes 8..114 seconds
  • From: Andrus
• Re: Very Urgent : Sequences Problem
  • From: tv
• Re: Very Urgent : Sequences Problem
  • From: Merlin Moncure
• Re: Very Urgent : Sequences Problem
  • From: Josh Berkus
• Very Urgent : Sequences Problem
  • From: Kranti™ K K Parisa
• Re: PostgreSQL NOT IN performance
  • From: Віталій Тимчишин
• Re: PostgreSQL NOT IN performance
  • From: Stephan Szabo
• Re: PostgreSQL NOT IN performance
  • From: Віталій Тимчишин
• Re: PostgreSQL NOT IN performance
  • From: Alvaro Herrera
• Re: PostgreSQL NOT IN performance
  • From: DANIEL CRISTIAN CRUZ
• PostgreSQL NOT IN performance
  • From: Віталій Тимчишин
• Re: Performance and IN clauses
  • From: Tomas Vondra
• Re: Performance and IN clauses
  • From: Mark Roberts
• Re: Performance and IN clauses
  • From: tv
• Re: Performance and IN clauses
  • From: Matthew Wakeling
• Performance and IN clauses
  • From: Kynn Jones
• Re: Bad performance on simple query
  • From: Dave Page
• Re: Bad performance on simple query
  • From: Dimi Paun
• Re: Bad performance on simple query
  • From: ries van Twisk
• Re: Bad performance on simple query
  • From: Scott Marlowe
• Re: Bad performance on simple query
  • From: Dimi Paun
• Re: Bad performance on simple query
  • From: Scott Marlowe
• Re: Bad performance on simple query
  • From: Dimi Paun
• Re: Bad performance on simple query
  • From: Scott Marlowe
• Re: Bad performance on simple query
  • From: Alan Hodgson
• Bad performance on simple query
  • From: Dimi Paun
• Re: Improve Seq scan performance
  • From: PFC
• Re: PostgreSQL OR performance
  • From: Віталій Тимчишин
• Re: Performance Question
  • From: PFC
• Re: slow full table update
  • From: PFC
• Re: Improve Seq scan performance
  • From: PFC
• Re: PostgreSQL OR performance
  • From: Tom Lane
• Re: PostgreSQL OR performance
  • From: Віталій Тимчишин
• Re: PostgreSQL OR performance
  • From: Віталій Тимчишин
• Re: Difference in query plan
  • From: Richard Huxton
• Re: Difference in query plan
  • From: Patrice Beliveau
• Re: Difference in query plan
  • From: Richard Huxton
• Difference in query plan
  • From: Patrice Beliveau
• Re: crosstab speed
  • From: Joe Conway
• Re: crosstab speed
  • From: Scott Marlowe
• crosstab speed
  • From: Jeremiah Elliott
• Re: Slow SQL query (14-15 seconds)
  • From: Bruno Baguette
• Re: Slow SQL query (14-15 seconds)
  • From: Bruno Baguette
• Re: Slow SQL query (14-15 seconds)
  • From: Tom Lane
• Re: Slow SQL query (14-15 seconds)
  • From: Vladimir Sitnikov
• Re: Slow SQL query (14-15 seconds)
  • From: Bruno Baguette
• Re: Slow SQL query (14-15 seconds)
  • From: Tomasz Myrta
• Re: Slow SQL query (14-15 seconds)
  • From: Tom Lane
• Re: Slow SQL query (14-15 seconds)
  • From: Matthew Wakeling
• Re: Performance Question
  • From: Merlin Moncure
• Slow SQL query (14-15 seconds)
  • From: Bruno Baguette
• Re: Performance Question
  • From: Dave Page
• Re: Performance Question
  • From: Scott Marlowe
• Re: Using index for IS NULL query
  • From: Tomas Vondra
• Re: slow full table update
  • From: Tomas Vondra
• Re: slow full table update
  • From: Tomas Vondra
• Re: Disk usage question
  • From: Scott Marlowe
• Re: slow full table update
  • From: Scott Marlowe
• Re: slow full table update
  • From: firerox
• Disk usage question
  • From: Franck Routier
• Re: Performance Question
  • From: Tom Lane
• Re: slow full table update
  • From: Scott Marlowe
• Re: slow full table update
  • From: Tom Lane
• Re: Increasing select max(datecol) from bilkaib wheredatecol<=date'2008-11-01' and (cr='00' or db='00') speed
  • From: Andrus
• Re: Increasing select max(datecol) from bilkaib where datecol<=date'2008-11-01' and (cr='00' or db='00') speed
  • From: Andrus
• Re: Increasing select max(datecol) from bilkaib where datecol<=date'2008-11-01' and (cr='00' or db='00') speed
  • From: hubert depesz lubaczewski
• Re: Increasing select max(datecol) from bilkaib where datecol<=date'2008-11-01' and (cr='00' or db='00') speed
  • From: Vladimir Sitnikov
• Re: Increasing select max(datecol) from bilkaib where datecol<=date'2008-11-01' and (cr='00' or db='00') speed
  • From: Andrus
• Re: slow full table update
  • From: Vladimir Sitnikov
• Re: slow full table update
  • From: Richard Huxton
• Re: Increasing select max(datecol) from bilkaib where datecol<=date'2008-11-01' and (cr='00' or db='00') speed
  • From: Matthew Wakeling
• Re: Increasing select max(datecol) from bilkaib where datecol<=date'2008-11-01' and (cr='00' or db='00') speed
  • From: Vladimir Sitnikov
• Re: Increasing select max(datecol) from bilkaib where datecol<=date'2008-11-01' and (cr='00' or db='00') speed
  • From: Matthew Wakeling
• Re: slow full table update
  • From: firerox
• Re: Performance Question
  • From: Fernando Hevia
• Increasing select max(datecol) from bilkaib where datecol<=date'2008-11-01' and (cr='00' or db='00') speed
  • From: Andrus
• Re: Performance Question
  • From: tv
• Re: Performance Question
  • From: J Sisson
• Re: slow full table update
  • From: tv
• Performance Question
  • From: - -
• Re: slow full table update
  • From: firerox
• Re: Index usage with sub select or outer joins
  • From: Julien Theulier
• Re: Index usage with sub select or inner joins
  • From: Joshua Tolley
• Index usage with sub select or inner joins
  • From: Julien Theulier
• Re: Using index for IS NULL query
  • From: Matthew Wakeling
• Re: Oddity with view (now with test case)
  • From: Tom Lane
• Re: Using index for IS NULL query
  • From: Scott Marlowe
• Re: Using index for IS NULL query
  • From: Vladimir Sitnikov
• Re: Oddity with view (now with test case)
  • From: Jim 'Decibel!' Nasby
• Re: Using index for IS NULL query
  • From: Tomas Vondra
• Re: Using index for IS NULL query
  • From: Andreas Kretschmer
• Re: Using index for IS NULL query
  • From: Andreas Kretschmer
• Re: Using index for IS NULL query
  • From: Tom Lane
• Using index for IS NULL query
  • From: Andrus
• Re: Oddity with view (now with test case)
  • From: Tom Lane
• Re: Oddity with view (now with test case)
  • From: Jim 'Decibel!' Nasby
• Re: Create and drop temp table in 8.3.4
  • From: Aidan Van Dyk
• Re: Create and drop temp table in 8.3.4
  • From: Matthew Wakeling
• Re: Oddity with view (now with test case)
  • From: Tom Lane
• Re: Oddity with view (now with test case)
  • From: Jim 'Decibel!' Nasby
• Re: Oddity with view (now with test case)
  • From: Tom Lane
• Re: Oddity with view (now with test case)
  • From: Jim 'Decibel!' Nasby
• Re: Oddity with view
  • From: Tom Lane
• Re: Simple indexed IN query takes 40 seconds
  • From: Andrus
• Re: Oddity with view
  • From: Richard Huxton
• Re: Oddity with view
  • From: Jim 'Decibel!' Nasby
• paging on windows
  • From: Anshul Dutta
• Re: Simple indexed IN query takes 40 seconds
  • From: tv
• Re: slow full table update
  • From: tv
• slow full table update
  • From: firerox
• Re: Simple indexed IN query takes 40 seconds
  • From: Tom Lane
• Simple indexed IN query takes 40 seconds
  • From: Andrus
• Re: Improve Seq scan performance
  • From: Lutischán Ferenc
• Re: Oddity with view
  • From: Tom Lane
• Re: Improve Seq scan performance
  • From: Craig Ringer
• Oddity with view
  • From: Jim 'Decibel!' Nasby
• Re: Improve Seq scan performance
  • From: Vladimir Sitnikov
• Re: Improve Seq scan performance
  • From: Craig Ringer
• Re: Improve Seq scan performance
  • From: Vladimir Sitnikov
• Re: Improve Seq scan performance
  • From: Craig Ringer
• Improve Seq scan performance
  • From: Lutischán Ferenc
• Re: PostgreSQL OR performance
  • From: Richard Huxton
• Re: PostgreSQL OR performance
  • From: David Wilson
• Re: PostgreSQL OR performance
  • From: Віталій Тимчишин
• Re: Create and drop temp table in 8.3.4
  • From: David Rees
• Re: Create and drop temp table in 8.3.4
  • From: Scott Marlowe
• Re: Create and drop temp table in 8.3.4
  • From: Kevin Grittner
• Re: lru_multiplier and backend page write-outs
  • From: Peter Schuller
• Re: Create and drop temp table in 8.3.4
  • From: Scott Marlowe
• Re: Create and drop temp table in 8.3.4
  • From: Kevin Grittner
• Re: lru_multiplier and backend page write-outs
  • From: Greg Smith
• Re: Create and drop temp table in 8.3.4
  • From: Scott Marlowe
• Re: Create and drop temp table in 8.3.4
  • From: Kevin Grittner
• Re: Create and drop temp table in 8.3.4
  • From: Scott Carey
• Re: Create and drop temp table in 8.3.4
  • From: Kevin Grittner
• Re: Create and drop temp table in 8.3.4
  • From: Joshua D. Drake
• Re: Create and drop temp table in 8.3.4
  • From: Kevin Grittner
• Re: Occasional Slow Commit
  • From: David Rees
• Re: PostgreSQL OR performance
  • From: Віталій Тимчишин
• Re: PostgreSQL OR performance
  • From: Helio Campos Mello de Andrade
• Re: PostgreSQL OR performance
  • From: Richard Huxton
• Re: PostgreSQL OR performance
  • From: Віталій Тимчишин
• Re: Occasional Slow Commit
  • From: Scott Marlowe
• Re: Occasional Slow Commit
  • From: David Rees
• Re: PostgreSQL OR performance
  • From: Helio Campos Mello de Andrade
• Re: server space increasing very fast but transaction are very low
  • From: Guillaume Cottenceau
• Re: server space increasing very fast but transaction are very low
  • From: Richard Huxton
• server space increasing very fast but transaction are very low
  • From: brahma tiwari
• Re: PostgreSQL OR performance
  • From: Віталій Тимчишин
• Re: Occasional Slow Commit
  • From: Peter Schuller
• Re: lru_multiplier and backend page write-outs
  • From: Peter Schuller
• Re: Occasional Slow Commit
  • From: David Rees
• Re: Create and drop temp table in 8.3.4
  • From: Tom Lane
• Re: Create and drop temp table in 8.3.4
  • From: Kevin Grittner
• Re: Query planner cost estimate less than the sum of its parts?
  • From: Scott Carey
• Re: Query planner cost estimate less than the sum of its parts?
  • From: Gregory Stark
• Re: lru_multiplier and backend page write-outs
  • From: Greg Smith
• Query planner cost estimate less than the sum of its parts?
  • From: Scott Carey
• Re: Create and drop temp table in 8.3.4
  • From: Kevin Grittner
• Create and drop temp table in 8.3.4
  • From: Kevin Grittner
• Re: PostgreSQL OR performance
  • From: Jeff Davis
• Re: PostgreSQL OR performance
  • From: Tom Lane
• lru_multiplier and backend page write-outs
  • From: Peter Schuller
• PostgreSQL OR performance
  • From: Віталій Тимчишин
• Re: [ADMIN] Installation Error of postgresql-8.1.5 with perl.
  • From: praveen
• Installation Error of postgresql-8.1.5 with perl.
  • From: praveen
• Re: Aggregate weirdness
  • From: Tom Lane
• epqa; postgres performance optimizer support tool; opensource.
  • From: sathiya psql
• Aggregate weirdness
  • From: Martin Kjeldsen
• Re: Index bloat, reindex weekly, suggestions etc?
  • From: Tory M Blue
• Re: Occasional Slow Commit
  • From: David Rees
• Re: Index usage problem on 8.3.3
  • From: Jeff Frost
• Re: Configuring for maximum memory usage
  • From: Scott Carey
• Re: Index usage problem on 8.3.3
  • From: Gregory Stark
• Re: CPU utilization vs. IO wait, shared buffers?
  • From: znmeb
• Re: Index usage problem on 8.3.3
  • From: Tom Lane
• Re: Index usage problem on 8.3.3
  • From: Jeff Frost
• Re: Index usage problem on 8.3.3
  • From: Tom Lane
• Re: Index usage problem on 8.3.3
  • From: Jeff Frost
• Re: Index usage problem on 8.3.3
  • From: Tom Lane
• Re: Index usage problem on 8.3.3
  • From: Jeff Frost
• Re: Index usage problem on 8.3.3
  • From: Tom Lane
• Re: Index usage problem on 8.3.3
  • From: Jeff Frost
• Re: Index usage problem on 8.3.3
  • From: Tom Lane
• Index usage problem on 8.3.3
  • From: Jeff Frost
• Re: CPU utilization vs. IO wait, shared buffers?
  • From: Oliver Johnson
• Re: CPU utilization vs. IO wait, shared buffers?
  • From: Scott Marlowe
• Re: CPU utilization vs. IO wait, shared buffers?
  • From: Alan Hodgson
• CPU utilization vs. IO wait, shared buffers?
  • From: Oliver Johnson
• Re: Configuring for maximum memory usage
  • From: Christiaan Willemsen
• Re: Configuring for maximum memory usage
  • From: Scott Carey
• Re: Configuring for maximum memory usage
  • From: Scott Carey
• Re: Configuring for maximum memory usage
  • From: Joshua D. Drake
• Re: Configuring for maximum memory usage
  • From: Alvaro Herrera
• Re: Configuring for maximum memory usage
  • From: Christiaan Willemsen
• Re: Configuring for maximum memory usage
  • From: Joshua D. Drake
• Re: Configuring for maximum memory usage
  • From: Scott Carey
• Re: Configuring for maximum memory usage
  • From: Scott Carey
• Re: Configuring for maximum memory usage
  • From: Joshua D. Drake
• Re: Configuring for maximum memory usage
  • From: Christiaan Willemsen
• Re: Configuring for maximum memory usage
  • From: Joshua D. Drake
• Re: Configuring for maximum memory usage
  • From: Ulrich
• Configuring for maximum memory usage
  • From: Christiaan Willemsen
• Re: Occasional Slow Commit
  • From: David Rees
• Re: Occasional Slow Commit
  • From: Greg Smith
• Re: Occasional Slow Commit
  • From: Andrew Sullivan
• Re: Occasional Slow Commit
  • From: Merlin Moncure
• Occasional Slow Commit
  • From: David Rees
• maintenance_work_mem and create index
  • From: Ioana Danes
• Re: Hardware HD choice...
  • From: Lionel
• Re: Hardware HD choice...
  • From: Lutz Steinborn
• Re: Hardware HD choice...
  • From: Scott Marlowe
• Re: Hardware HD choice...
  • From: Scott Carey
• Re: Hardware HD choice...
  • From: Ivan Voras
• Re: Hardware HD choice...
  • From: Scott Marlowe
• Re: Hardware HD choice...
  • From: Scott Marlowe
• Hardware HD choice...
  • From: Lionel
• "Mysterious" - Dynamic Programming X GEQO
  • From: tarcizioab
• Re: Explain Analyze - Total runtime very differentes
  • From: Stefan Kaltenbrunner
• Re: Postgres Performance on CPU limited Platforms
  • From: Scott Marlowe
• Explain Analyze - Total runtime very differentes
  • From: tarcizioab
• Re: Index bloat, reindex weekly, suggestions etc?
  • From: Віталій Тимчишин
• Re: Backup strategies
  • From: Simon Riggs
• Re: Index bloat, reindex weekly, suggestions etc?
  • From: Kevin Grittner
• Re: Index bloat, reindex weekly, suggestions etc?
  • From: Tory M Blue
• Re: Index bloat, reindex weekly, suggestions etc?
  • From: Kevin Grittner
• Re: Index bloat, reindex weekly, suggestions etc?
  • From: Tory M Blue
• Re: Index bloat, reindex weekly, suggestions etc?
  • From: Scott Marlowe
• Re: Index bloat, reindex weekly, suggestions etc?
  • From: Tory M Blue
• Re: Index bloat, reindex weekly, suggestions etc?
  • From: Kevin Grittner
• Index bloat, reindex weekly, suggestions etc?
  • From: Tory M Blue
• Re: Backup strategies
  • From: Scott Marlowe
• Re: Backup strategies
  • From: Tom Lane
• Re: Backup strategies
  • From: Ivan Voras
• Re: Backup strategies
  • From: Peter Childs
• Re: Backup strategies
  • From: Ivan Voras
• Re: Backup strategies
  • From: Matthew Wakeling
• Re: Backup strategies
  • From: Ivan Voras
• Re: Backup strategies
  • From: Guillaume Lelarge
• Re: Backup strategies
  • From: Ivan Voras
• Re: Backup strategies
  • From: Jesper Krogh
• Re: Backup strategies
  • From: Craig Ringer
• Re: Backup strategies
  • From: Ivan Voras
• Re: speeding up table creation
  • From: Craig Ringer
• Re: speeding up table creation
  • From: Scott Marlowe
• Re: speeding up table creation
  • From: Steve Crawford
• speeding up table creation
  • From: Rainer Mager
• Re: Backup strategies
  • From: Kevin Grittner
• Backup strategies
  • From: Reuven M. Lerner
• Re: "Mysterious" issues with newly installed 8.3
  • From: Greg Smith
• Re: [GENERAL] Drupal and PostgreSQL - performance issues?
  • From: Greg Smith
• Re: "Mysterious" issues with newly installed 8.3
  • From: Carlos Moreno
• Re: "Mysterious" issues with newly installed 8.3
  • From: Scott Marlowe
• Re: "Mysterious" issues with newly installed 8.3
  • From: Carlos Moreno
• Re: [GENERAL] Drupal and PostgreSQL - performance issues?
  • From: Simon Waters
• Re: [GENERAL] Drupal and PostgreSQL - performance issues?
  • From: Scott Marlowe
• Re: [GENERAL] Drupal and PostgreSQL - performance issues?
  • From: Scott Marlowe
• Re: Drupal and PostgreSQL - performance issues?
  • From: Ang Chin Han
• Re: Drupal and PostgreSQL - performance issues?
  • From: Greg Smith
• Re: Drupal and PostgreSQL - performance issues?
  • From: Mikkel Høgh
• Re: Drupal and PostgreSQL - performance issues?
  • From: Greg Smith
• Re: [GENERAL] Drupal and PostgreSQL - performance issues?
  • From: Mikkel Høgh
• Re: [GENERAL] Drupal and PostgreSQL - performance issues?
  • From: John DeSoi
• Drupal and PostgreSQL - performance issues?
  • From: Mikkel Høgh
• Re: Identical DB's, different execution plans
  • From: Doug Eck
• Re: Identical DB's, different execution plans
  • From: Tom Lane
• Re: Identical DB's, different execution plans
  • From: Doug Eck
• Re: Identical DB's, different execution plans
  • From: Tom Lane
• Identical DB's, different execution plans
  • From: Doug Eck
• dedicated server & postgresql 8.1 conf tunning
  • From: paul
• Re: CPU load
  • From: Albe Laurenz
• Re: CPU load
  • From: kiki
• Re: CPU load
  • From: Albe Laurenz
• Re: CPU load
  • From: Albe Laurenz
• Re: CPU load
  • From: hubert depesz lubaczewski
• Re: CPU load
  • From: kiki
• Re: CPU load
  • From: kiki
• Re: CPU load
  • From: Albe Laurenz
• Re: CPU load
  • From: Harald Armin Massa
• Re: CPU load
  • From: kiki
• Re: Slow updates, poor IO
  • From: Scott Marlowe
• Re: Slow updates, poor IO
  • From: John Huttley
• Re: Slow updates, poor IO
  • From: Dan Langille
• Re: Slow updates, poor IO
  • From: John Huttley
• Re: Slow updates, poor IO
  • From: Scott Marlowe
• Re: Slow updates, poor IO
  • From: John Huttley
• Re: Slow updates, poor IO
  • From: Greg Smith
• Re: Slow updates, poor IO
  • From: John Huttley
• Re: Slow updates, poor IO
  • From: John Huttley
• Re: Slow updates, poor IO
  • From: Scott Carey
• Re: Slow updates, poor IO
  • From: Tom Lane
• Re: Slow updates, poor IO
  • From: John Huttley
• Re: Slow updates, poor IO
  • From: Scott Marlowe
• Re: Slow updates, poor IO
  • From: Scott Marlowe
• Re: Slow updates, poor IO
  • From: Greg Smith
• Re: Slow updates, poor IO
  • From: John Huttley
• Re: Slow updates, poor IO
  • From: John Huttley
• Re: CPU load
  • From: Scott Carey
• Re: Slow updates, poor IO
  • From: Andrew Sullivan
• Re: CPU load
  • From: Albe Laurenz
• Re: CPU load
  • From: kiki
• Re: CPU load
  • From: Albe Laurenz
• Re: Slow updates, poor IO
  • From: Greg Smith
• Re: CPU load
  • From: Scott Marlowe
• CPU load
  • From: kiki
• Re: Slow updates, poor IO
  • From: Alan Hodgson
• Re: Slow updates, poor IO
  • From: Scott Marlowe
• Slow updates, poor IO
  • From: John Huttley
• Re: Slow index
  • From: Matthew Wakeling
• Re: Slow index
  • From: Tom Lane
• Slow index
  • From: Matthew Wakeling
• Re: query planner and scanning methods
  • From: Richard Broersma
• Re: UFS 2: soft updates vs. gjournal (AKA: Choosing a filesystem 2.)
  • From: Axel Rau
• Re: Intel's X25-M SSD
  • From: Steve Clark
• Re: Different execution plan
  • From: Matthew Wakeling
• Re: UFS 2: soft updates vs. gjournal (AKA: Choosing a filesystem 2.)
  • From: Artis Caune
• Re: UFS 2: soft updates vs. gjournal (AKA: Choosing a filesystem 2.)
  • From: Claus Guttesen
• UFS 2: soft updates vs. gjournal (AKA: Choosing a filesystem 2.)
  • From: Laszlo Nagy
• Re: Different execution plan
  • From: Sabin Coanda
• Re: Different execution plan
  • From: Sabin Coanda
• Re: Intel's X25-M SSD
  • From: Scott Carey
• Re: Chaotically weird execution plan
  • From: Scott Carey
• Re: Intel's X25-M SSD
  • From: Bruce Momjian
• Re: Chaotically weird execution plan
  • From: Craig Ringer
• Re: Chaotically weird execution plan
  • From: Tom Lane
• Re: Chaotically weird execution plan
  • From: Tom Lane
• Re: Chaotically weird execution plan
  • From: Craig Ringer
• Chaotically weird execution plan
  • From: Einars
• Re: query planner and scanning methods
  • From: Richard Broersma
• Re: query planner and scanning methods
  • From: Colin Copeland
• Re: query planner and scanning methods
  • From: Richard Broersma
• query planner and scanning methods
  • From: Colin Copeland
• Re: Choosing a filesystem
  • From: Simon Riggs
• Re: Choosing a filesystem
  • From: Bruce Momjian
• Re: Intel's X25-M SSD
  • From: Simon Riggs
• Re: Different execution plan
  • From: Scott Marlowe
• Re: Different execution plan
  • From: Sabin Coanda
• Re: Intel's X25-M SSD
  • From: Greg Smith
• Re: why does this use the wrong index?
  • From: Jeff Davis
• Re: why does this use the wrong index?
  • From: Jeff Davis
• Re: RAID arrays and performance
  • From: Mark Mielke
• Re: RAID arrays and performance
  • From: Matthew Wakeling
• Re: RAID arrays and performance
  • From: Tom Lane
• Re: RAID arrays and performance
  • From: Matthew Wakeling
• why does this use the wrong index?
  • From: Rainer Mager
• Re: RAID arrays and performance
  • From: Scott Marlowe
• Re: RAID arrays and performance
  • From: Greg Smith
• Re: Why does this query write to the disk?
  • From: Tom Lane
• Re: Why does this query write to the disk?
  • From: Nikolas Everett
• Re: Why does this query write to the disk?
  • From: Scott Carey
• Re: Why does this query write to the disk?
  • From: Scott Carey
• Re: Why does this query write to the disk?
  • From: Tom Lane
• Re: Why does this query write to the disk?
  • From: Kevin Grittner
• Why does this query write to the disk?
  • From: Nikolas Everett
• Re: RAID arrays and performance
  • From: Matthew Wakeling
• Re: Statement Timeout at User Level
  • From: Albe Laurenz
• Statement Timeout at User Level
  • From: Gauri Kanekar
• Re: Effects of setting linux block device readahead size
  • From: Scott Carey
• Re: Effects of setting linux block device readahead size
  • From: Matthew Wakeling
• Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
  • From: Craig James
• Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
  • From: Florian Weimer
• Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
  • From: Craig James
• Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
  • From: Florian Weimer
• Re: Choosing a filesystem
  • From: Merlin Moncure
• Re: Choosing a filesystem
  • From: david
• Re: Effects of setting linux block device readahead size
  • From: david
• Re: Postgres Performance on CPU limited Platforms
  • From: H. Hall
• Postgres Performance on CPU limited Platforms
  • From: George McCollister
• Re: Choosing a filesystem
  • From: Merlin Moncure
• Re: Choosing a filesystem
  • From: Greg Smith
• Re: Effects of setting linux block device readahead size
  • From: James Mansion
• Re: Choosing a filesystem
  • From: Greg Smith
• Re: Choosing a filesystem
  • From: Guillaume Cottenceau
• Re: Choosing a filesystem
  • From: Matthew Wakeling
• Re: [GENERAL] PostgreSQL TPC-H test result?
  • From: Jonah H. Harris
• Re: Effects of setting linux block device readahead size
  • From: Greg Smith
• Re: [GENERAL] PostgreSQL TPC-H test result?
  • From: Tom Lane
• Re: [GENERAL] PostgreSQL TPC-H test result?
  • From: Jignesh K. Shah
• Re: Effects of setting linux block device readahead size
  • From: Scott Marlowe
• Re: Effects of setting linux block device readahead size
  • From: Scott Carey
• Re: Effects of setting linux block device readahead size
  • From: david
• Re: Effects of setting linux block device readahead size
  • From: Alan Hodgson
• Re: Effects of setting linux block device readahead size
  • From: david
• Re: Effects of setting linux block device readahead size
  • From: Scott Marlowe
• Re: Effects of setting linux block device readahead size
  • From: david
• Re: Effects of setting linux block device readahead size
  • From: Scott Carey
• Re: Effects of setting linux block device readahead size
  • From: Scott Carey
• Re: Choosing a filesystem
  • From: Greg Smith
• Re: Choosing a filesystem
  • From: Craig James
• Re: Effects of setting linux block device readahead size
  • From: James Mansion
• Re: Effects of setting linux block device readahead size
  • From: Scott Carey
• Re: Choosing a filesystem
  • From: Scott Marlowe
• Re: Choosing a filesystem
  • From: Scott Marlowe
• Re: Choosing a filesystem
  • From: Laszlo Nagy
• Re: Choosing a filesystem
  • From: Kevin Grittner
• Re: Choosing a filesystem
  • From: Kenneth Marshall
• Re: Choosing a filesystem
  • From: Matthew Wakeling
• Re: Choosing a filesystem
  • From: Andrew Sullivan
• Choosing a filesystem
  • From: Laszlo Nagy
• Re: performance impact of non-C locale
  • From: Peter Eisentraut
• Re: performance impact of non-C locale
  • From: Axel Rau
• Re: performance impact of non-C locale
  • From: Peter Eisentraut
• Re: Effects of setting linux block device readahead size
  • From: Greg Smith
• Re: Effects of setting linux block device readahead size
  • From: Scott Marlowe
• Re: Effects of setting linux block device readahead size
  • From: James Mansion
• Re: Effects of setting linux block device readahead size
  • From: Greg Smith
• 答复: [PERFORM] Improve COPY performance for large data sets
  • From: jay
• Re: Effects of setting linux block device readahead size
  • From: Scott Carey
• Re: Improve COPY performance for large data sets
  • From: Scott Marlowe
• Re: Improve COPY performance for large data sets
  • From: Dimitri Fontaine
• Re: Effects of setting linux block device readahead size
  • From: Greg Smith
• Re: Effects of setting linux block device readahead size
  • From: Scott Carey
• Re: too many clog files
  • From: Alvaro Herrera
• Re: too many clog files
  • From: Scott Carey
• Re: Improve COPY performance for large data sets
  • From: Scott Carey
• Re: Improve COPY performance for large data sets
  • From: Scott Carey
• Re: too many clog files
  • From: Kevin Grittner
• Re: too many clog files
  • From: Tom Lane
• Re: Effects of setting linux block device readahead size
  • From: Mark Wong
• Re: too many clog files
  • From: Scott Marlowe
• Re: Improve COPY performance for large data sets
  • From: Dimitri Fontaine
• Re: Improve COPY performance for large data sets
  • From: Bill Moran
• Re: Improve COPY performance for large data sets
  • From: Alan Hodgson
• Re: Improve COPY performance for large data sets
  • From: Ryan Hansen
• Improve COPY performance for large data sets
  • From: Ryan Hansen
• Re: Effects of setting linux block device readahead size
  • From: Scott Carey
• Re: too many clog files
  • From: Kevin Grittner
• Re: Effects of setting linux block device readahead size
  • From: Greg Smith
• Re: Intel's X25-M SSD
  • From: Chris Browne
• Effects of setting linux block device readahead size
  • From: Mark Wong
• Re: too many clog files
  • From: Matt Smiley
• Re: How to measure IO performance?
  • From: Scott Marlowe
• How to measure IO performance?
  • From: Andre Brandt
• Re: too many clog files
  • From: Matt Smiley
• Re: best use of another drive
  • From: Alex Hunsaker
• Re: best use of another drive
  • From: Rainer Mager
• Re: best use of another drive
  • From: Joshua Drake
• Re: best use of another drive
  • From: Scott Marlowe
• best use of another drive
  • From: Rainer Mager
• Re: Intel's X25-M SSD
  • From: Scott Carey
• Re: Intel's X25-M SSD
  • From: Merlin Moncure
• Intel's X25-M SSD
  • From: Greg Smith
• Re: SAN and full_page_writes
  • From: Bruce Momjian
• bitmap heap scan versus simple index and nested loop
  • From: Scott Marlowe
• Re: inaccurate stats on large tables
  • From: Matt Smiley
• Re: SAN and full_page_writes
  • From: Nikolas Everett
• Re: SAN and full_page_writes
  • From: Gregory Stark
• Re: SAN and full_page_writes
  • From: Nikolas Everett
• Re: SAN and full_page_writes
  • From: Gregory Stark
• Re: SAN and full_page_writes
  • From: Nikolas Everett
• Re: indexing for distinct search in timestamp based table
  • From: Rainer Mager
• Re: too many clog files
  • From: Duan Ligong
• Re: too many clog files
  • From: Duan Ligong
• performance impact of non-C locale
  • From: Axel Rau
• Re: SAN and full_page_writes
  • From: Bruce Momjian
• Re: You may need to increase mas_loks_per_trasaction
  • From: Greg Smith
• Re: too many clog files
  • From: Scott Marlowe
• Re: too many clog files
  • From: Alvaro Herrera
• Re: indexing for distinct search in timestamp based table
  • From: Vladimir Sitnikov
• Re: SAN and full_page_writes
  • From: Nikolas Everett
• Re: You may need to increase mas_loks_per_trasaction
  • From: Claus Guttesen
• You may need to increase mas_loks_per_trasaction
  • From: Jonas Pacheco
• Re: too many clog files
  • From: Matthew Wakeling
• Re: slow update of index during insert/copy
  • From: Thomas Finneid
• Re: inaccurate stats on large tables
  • From: David Wilson
• Re: too many clog files
  • From: Duan Ligong
• Re: More shared_buffers instead of effective_cache_size?
  • From: Scott Marlowe
• Re: More shared_buffers instead of effective_cache_size?
  • From: Ulrich
• Re: limit clause breaks query planner?
  • From: Gregory Stark
• Re: More shared_buffers instead of effective_cache_size?
  • From: Scott Marlowe
• Re: More shared_buffers instead of effective_cache_size?
  • From: Ulrich
• Re: slow update of index during insert/copy
  • From: Greg Smith
• Re: More shared_buffers instead of effective_cache_size?
  • From: Scott Marlowe
• More shared_buffers instead of effective_cache_size?
  • From: Ulrich
• Re: limit clause breaks query planner?
  • From: Matt Smiley
• inaccurate stats on large tables
  • From: Kiran Mukhyala
• Re: limit clause breaks query planner?
  • From: Scott Carey
• Re: limit clause breaks query planner?
  • From: Tom Lane
• Re: limit clause breaks query planner?
  • From: Matthew Wakeling
• Re: limit clause breaks query planner?
  • From: Guillaume Cottenceau
• Re: Partitions number limitation ?
  • From: Thomas Finneid
• Re: limit clause breaks query planner?
  • From: Matthew Wakeling
• Re: limit clause breaks query planner?
  • From: Tom Lane
• Re: slow update of index during insert/copy
  • From: Thomas Finneid
• Re: limit clause breaks query planner?
  • From: Matt Smiley
• Re: Partitions number limitation ?
  • From: Scott Marlowe
• SAN and full_page_writes
  • From: Nikolas Everett
• Partitions number limitation ?
  • From: s . caillet
• dblink /synonyms?
  • From: Jan-Peter Seifert
• Re: Samsung 32GB SATA SSD tested
  • From: behrangs
• Re: limit clause breaks query planner?
  • From: Tom Lane
• Re: limit clause breaks query planner?
  • From: Matt Smiley
• Re: logging options...
  • From: Guillaume Lelarge
• logging options...
  • From: Jessica Richard
• Re: too many clog files
  • From: Greg Smith
• Re: too many clog files
  • From: Guillaume Lelarge
• Re: limit clause breaks query planner?
  • From: David West
• Re: limit clause breaks query planner?
  • From: Guillaume Cottenceau
• Re: slow update of index during insert/copy
  • From: Matthew Wakeling
• Re: limit clause breaks query planner?
  • From: David West
• Re: limit clause breaks query planner?
  • From: David West
• Re: limit clause breaks query planner?
  • From: Guillaume Cottenceau
• Re: limit clause breaks query planner?
  • From: Gregory Stark
• Re: limit clause breaks query planner?
  • From: David West
• Re: limit clause breaks query planner?
  • From: Guillaume Cottenceau
• Re: slow update of index during insert/copy
  • From: Greg Smith
• Re: limit clause breaks query planner?
  • From: Pavel Stehule
• Re: limit clause breaks query planner?
  • From: Guillaume Cottenceau
• Re: slow update of index during insert/copy
  • From: Thomas Finneid
• Re: too many clog files
  • From: Tom Lane
• Re: too many clog files
  • From: Greg Smith
• Re: limit clause breaks query planner?
  • From: Russell Smith
• Re: too many clog files
  • From: Duan Ligong
• Re: slow update of index during insert/copy
  • From: Greg Smith
• Re: slow update of index during insert/copy
  • From: Scott Carey
• Re: slow update of index during insert/copy
  • From: Scott Marlowe
• Re: slow update of index during insert/copy
  • From: Scott Marlowe
• Re: slow update of index during insert/copy
  • From: Scott Carey
• Re: slow update of index during insert/copy
  • From: Thomas Finneid
• Re: slow update of index during insert/copy
  • From: Gregory Stark
• Re: limit clause breaks query planner?
  • From: Pavel Stehule