Postgres Performance Date Index

• Thread Index

• Optimizing Bitmap Heap Scan.
  • From: niraj patel
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Schmitz, David
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Craig Ringer
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Schmitz, David
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Andres Freund
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Schmitz, David
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Thom Brown
• Re: Checkpoint spikes
  • From: Richard Neill
• Re: Checkpoint spikes
  • From: Richard Neill
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Schmitz, David
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Schmitz, David
• Re: Load experimentation
  • From: Dimitri Fontaine
• Re: Load experimentation
  • From: Scott Marlowe
• Re: Load experimentation
  • From: Dimitri Fontaine
• Re: Load experimentation
  • From: Scott Marlowe
• Re: Load experimentation
  • From: Scott Marlowe
• Re: Load experimentation
  • From: Greg Smith
• Re: Load experimentation
  • From: Ben Brehmer
• Re: Dynamlically updating the estimated cost of a transaction
  • From: Greg Smith
• error occured in dbt2 against with postgresql
  • From: Niu Yan
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Robert Haas
• Dynamlically updating the estimated cost of a transaction
  • From: Hasini Gunasinghe
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Andres Freund
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Schmitz, David
• Re: RAID card recommendation
  • From: Karl Denninger
• Re: RAID card recommendation
  • From: Greg Smith
• Re: RAID card recommendation
  • From: Greg Smith
• Re: RAID card recommendation
  • From: Karl Denninger
• Re: RAID card recommendation
  • From: Craig James
• Re: performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Kevin Grittner
• performance penalty between Postgresql 8.3.8 and 8.4.1
  • From: Schmitz, David
• Re: RAID card recommendation
  • From: Greg Smith
• Re: Load experimentation
  • From: Greg Smith
• Re: RAID card recommendation
  • From: Karl Denninger
• Re: Load experimentation
  • From: Alan Hodgson
• Re: Load experimentation
  • From: Craig James
• Re: Load experimentation
  • From: Ben Brehmer
• Re: RAID card recommendation
  • From: Scott Carey
• Re: RAID card recommendation
  • From: Scott Carey
• Re: Load experimentation
  • From: Craig James
• Re: Load experimentation
  • From: Ben Brehmer
• Re: Load experimentation
  • From: Thom Brown
• Re: Load experimentation
  • From: Scott Mead
• Re: Load experimentation
  • From: Kevin Grittner
• Load experimentation
  • From: Ben Brehmer
• Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
  • From: Scott Marlowe
• Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
  • From: Andres Freund
• Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
  • From: Andres Freund
• Re: performance while importing a very large data set in to database
  • From: Greg Smith
• Re: performance while importing a very large data set in to database
  • From: Kris Kewley
• Re: performance while importing a very large data set in to database
  • From: Pierre Frédéric Caillaud
• Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
  • From: Greg Smith
• Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
  • From: Craig Ringer
• Re: performance while importing a very large data set in to database
  • From: Scott Marlowe
• Re: query cost too high, anyway to reduce it
  • From: Scott Marlowe
• Re: performance while importing a very large data set in to database
  • From: Scott Marlowe
• Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
  • From: Scott Marlowe
• Re: performance while importing a very large data set in to database
  • From: "Ing . Marcos Luís Ortíz Valmaseda"
• Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
  • From: Andres Freund
• Re: performance while importing a very large data set in to database
  • From: Jeremy Harris
• performance while importing a very large data set in to database
  • From: Ashish Kumar Singh
• Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum
  • From: Andreas Thiel
• query cost too high, anyway to reduce it
  • From: nair rajiv
• Re: OpenMP in PostgreSQL-8.4.0
  • From: Denis Lussier
• Time Profiling inside the procedure
  • From: niraj patel
• Re: Server Freezing
  • From: Denis Lussier
• Re: SSD + RAID
  • From: Scott Carey
• Re: Checkpoint spikes
  • From: Greg Smith
• Re: Checkpoint spikes
  • From: Heikki Linnakangas
• Re: Analyse without locking?
  • From: Laurent Laborde
• Re: [BUGS] BUG #5228: Execution of prepared query is slow when timestamp parameter is used
  • From: Craig Ringer
• Re: Checkpoint spikes
  • From: Greg Smith
• Re: Analyse without locking?
  • From: Richard Neill
• Re: Query times change by orders of magnitude as DB ages
  • From: Scott Carey
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Richard Neill
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Kevin Grittner
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Richard Neill
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Kevin Grittner
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Tom Lane
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Kevin Grittner
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Tom Lane
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Kevin Grittner
• Re: Cost of sort/order by not estimated by the query planner
  • From: Tom Lane
• Re: Cost of sort/order by not estimated by the query planner
  • From: Robert Haas
• Re: Cost of sort/order by not estimated by the query planner
  • From: Laurent Laborde
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Craig Ringer
• Re: Cost of sort/order by not estimated by the query planner
  • From: Laurent Laborde
• Re: Cost of sort/order by not estimated by the query planner
  • From: Robert Haas
• Re: Cost of sort/order by not estimated by the query planner
  • From: Laurent Laborde
• Re: Cost of sort/order by not estimated by the query planner
  • From: Greg Stark
• Re: Cost of sort/order by not estimated by the query planner
  • From: Laurent Laborde
• Re: Cost of sort/order by not estimated by the query planner
  • From: Greg Stark
• Re: Cost of sort/order by not estimated by the query planner
  • From: Laurent Laborde
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Matthew Wakeling
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Richard Neill
• Re: RAID card recommendation
  • From: Greg Smith
• Re: RAID card recommendation
  • From: Karl Denninger
• Re: RAID card recommendation
  • From: Scott Carey
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Kevin Grittner
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Richard Neill
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Jean-Michel Pouré
• Re: Order by (for 15 rows) adds 30 seconds to query time
  • From: Kevin Grittner
• Order by (for 15 rows) adds 30 seconds to query time
  • From: Richard Neill
• Re: Server Freezing
  • From: Fernando Hevia
• Re: Server Freezing
  • From: Waldomiro
• Re: Server Freezing
  • From: Waldomiro
• Re: Server Freezing
  • From: Greg Smith
• Re: Server Freezing
  • From: Robert Haas
• Re: Server Freezing
  • From: Fernando Hevia
• Re: truncate in transaction blocks read access
  • From: Joshua D. Drake
• truncate in transaction blocks read access
  • From: Craig James
• Server Freezing
  • From: Waldomiro
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Ron Mayer
• Re: SSD + RAID
  • From: Ron Mayer
• Re: query optimization
  • From: Robert Haas
• Re: Any have tested ZFS like PostgreSQL installation filesystem?
  • From: Ivan Voras
• Re: Any have tested ZFS like PostgreSQL installation filesystem?
  • From: "Ing . Marcos Luís Ortíz Valmaseda"
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: Any have tested ZFS like PostgreSQL installation filesystem?
  • From: Ivan Voras
• Re: SSD + RAID
  • From: Greg Smith
• Any have tested ZFS like PostgreSQL installation filesystem?
  • From: "Ing . Marcos Luís Ortíz Valmaseda"
• Re: SSD + RAID
  • From: Bruce Momjian
• Re: SSD + RAID
  • From: Ron Mayer
• Re: OpenMP in PostgreSQL-8.4.0
  • From: Greg Stark
• Re: OpenMP in PostgreSQL-8.4.0
  • From: Tom Lane
• Re: OpenMP in PostgreSQL-8.4.0
  • From: Reydan Cankur
• Re: OpenMP in PostgreSQL-8.4.0
  • From: Bruce Momjian
• Re: Analyse without locking?
  • From: Richard Neill
• Re: Analyse without locking?
  • From: Greg Smith
• Re: OpenMP in PostgreSQL-8.4.0
  • From: Reydan Cankur
• Re: Analyse without locking?
  • From: Tom Lane
• Re: Analyse without locking?
  • From: Richard Neill
• Re: OpenMP in PostgreSQL-8.4.0
  • From: Tom Lane
• Re: SSD + RAID
  • From: Bruce Momjian
• OpenMP in PostgreSQL-8.4.0
  • From: Reydan Cankur
• Re: query optimization
  • From: Faheem Mitha
• Re: Analyse without locking?
  • From: Greg Smith
• Re: RAID card recommendation
  • From: Ron Mayer
• Re: Analyse without locking?
  • From: Andres Freund
• Re: Analyse without locking?
  • From: Tom Lane
• Re: Analyse without locking?
  • From: Grzegorz Jaśkiewicz
• Analyse without locking?
  • From: Richard Neill
• Re: Query times change by orders of magnitude as DB ages
  • From: Richard Neill
• Re: Query times change by orders of magnitude as DB ages
  • From: Sergey Aleynikov
• Re: Query times change by orders of magnitude as DB ages
  • From: Sergey Aleynikov
• Re: Query times change by orders of magnitude as DB ages
  • From: Matthew Wakeling
• Re: query optimization
  • From: Robert Haas
• Re: query optimization
  • From: Faheem Mitha
• Re: Query times change by orders of magnitude as DB ages
  • From: Robert Haas
• Re: query optimization
  • From: Robert Haas
• Re: Query times change by orders of magnitude as DB ages
  • From: Grzegorz Jaśkiewicz
• Re: Query times change by orders of magnitude as DB ages
  • From: Kevin Grittner
• Re: RAID card recommendation
  • From: Steve Crawford
• Re: Query times change by orders of magnitude as DB ages
  • From: Grzegorz Jaśkiewicz
• Re: Query times change by orders of magnitude as DB ages
  • From: Kevin Grittner
• Re: DELETE performance problem
  • From: Grzegorz Jaśkiewicz
• Re: DELETE performance problem
  • From: Luca Tettamanti
• Re: DELETE performance problem
  • From: marcin mank
• Re: How exactly does Analyze work?
  • From: Kevin Kempter
• Re: How exactly does Analyze work?
  • From: Tom Lane
• Re: Best possible way to insert and get returned ids
  • From: Robert Haas
• How exactly does Analyze work?
  • From: Richard Neill
• Re: Query times change by orders of magnitude as DB ages
  • From: Richard Neill
• Re: Query times change by orders of magnitude as DB ages
  • From: Richard Neill
• Re: Query times change by orders of magnitude as DB ages
  • From: Matthew Wakeling
• Re: Query times change by orders of magnitude as DB ages
  • From: Richard Neill
• Re: Query times change by orders of magnitude as DB ages
  • From: Richard Neill
• Re: RAID card recommendation
  • From: Glyn Astill
• Re: Strange performance degradation
  • From: Matthew Wakeling
• Re: RAID card recommendation
  • From: Scott Marlowe
• Re: RAID card recommendation
  • From: Greg Smith
• Re: RAID card recommendation
  • From: Greg Smith
• Re: RAID card recommendation
  • From: Greg Smith
• Re: DELETE performance problem
  • From: Kris Kewley
• Re: RAID card recommendation
  • From: Robert Schnabel
• Re: RAID card recommendation
  • From: Jochen Erwied
• Re: RAID card recommendation
  • From: Dave Crooke
• Re: RAID card recommendation
  • From: Scott Marlowe
• Re: RAID card recommendation
  • From: Gurgel, Flavio
• Re: RAID card recommendation
  • From: Jochen Erwied
• Re: RAID card recommendation
  • From: Scott Marlowe
• Re: RAID card recommendation
  • From: Ing. Marcos Ortiz Valmaseda
• Re: [GENERAL] Strange performance degradation
  • From: Ing. Marcos Ortiz Valmaseda
• Re: RAID card recommendation
  • From: Scott Marlowe
• Re: RAID card recommendation
  • From: Jochen Erwied
• Re: RAID card recommendation
  • From: Scott Marlowe
• Re: RAID card recommendation
  • From: Gurgel, Flavio
• Re: RAID card recommendation
  • From: Ben Chobot
• Re: RAID card recommendation
  • From: Richard Neill
• RAID card recommendation
  • From: Matthew Wakeling
• Re: DELETE performance problem
  • From: Alan Hodgson
• Re: Strange performance degradation
  • From: Matthew Wakeling
• Re: DELETE performance problem
  • From: Grzegorz Jaśkiewicz
• Re: [GENERAL] Strange performance degradation
  • From: Lorenzo Allegrucci
• Re: DELETE performance problem
  • From: Jerry Champlin
• Re: DELETE performance problem
  • From: Thom Brown
• Re: DELETE performance problem
  • From: Luca Tettamanti
• DELETE performance problem
  • From: Luca Tettamanti
• Re: Dynamic sql example
  • From: Pavel Stehule
• Dynamic sql example
  • From: ramasubramanian
• Re: [GENERAL] Strange performance degradation
  • From: Matthew Wakeling
• Re: Query is slow when executing in procedure
  • From: ramasubramanian
• Re: Query is slow when executing in procedure
  • From: ramasubramanian
• Re: Query is slow when executing in procedure
  • From: A. Kretschmer
• Re: Query is slow when executing in procedure
  • From: Pavel Stehule
• Query is slow when executing in procedure
  • From: ramasubramanian
• Re: query optimization
  • From: Faheem Mitha
• Re: query optimization
  • From: Sebastian Jörgensen
• Re: query optimization
  • From: marcin mank
• Re: query optimization
  • From: Faheem Mitha
• Re: query optimization
  • From: Thom Brown
• query optimization
  • From: Faheem Mitha
• Re: Best possible way to insert and get returned ids
  • From: Scott Marlowe
• Re: [GENERAL] Strange performance degradation
  • From: Tom Lane
• Best possible way to insert and get returned ids
  • From: Jason Dictos
• Re: [GENERAL] Strange performance degradation
  • From: Lorenzo Allegrucci
• Re: Performance degrade running on multicore computer
  • From: Dave Youatt
• Re: Query times change by orders of magnitude as DB ages
  • From: Robert Haas
• Re: View based upon function won't use index on joins
  • From: Robert Haas
• Re: Why is the query not using the index for sorting?
  • From: Jonathan Blitz
• Re: Query times change by orders of magnitude as DB ages
  • From: Matthew Wakeling
• Re: Why is the query not using the index for sorting?
  • From: Matthew Wakeling
• Re: Query times change by orders of magnitude as DB ages
  • From: Sergey Aleynikov
• Query times change by orders of magnitude as DB ages
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Why is the query not using the index for sorting?
  • From: Jonathan Blitz
• Re: Why is the query not using the index for sorting?
  • From: Craig Ringer
• Re: Why is the query not using the index for sorting?
  • From: Thom Brown
• Why is the query not using the index for sorting?
  • From: Jonathan Blitz
• Re: Performance degrade running on multicore computer
  • From: afancy
• Re: sub-select makes query take too long - unusable
  • From: Sergey Aleynikov
• sub-select makes query take too long - unusable
  • From: Mark Dueck
• sub-select makes query take too long - unusable
  • From: Mark Dueck
• Re: Performance degrade running on multicore computer
  • From: Tom Lane
• Performance degrade running on multicore computer
  • From: afancy
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: SSD + RAID
  • From: Greg Smith
• Re: Postgres query completion status?
  • From: Greg Smith
• Re: Postgres query completion status?
  • From: Greg Smith
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: marcin mank
• Re: Postgres query completion status?
  • From: Fernando Hevia
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: Fernando Hevia
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: Thom Brown
• Re: [GENERAL] Strange performance degradation
  • From: Lorenzo Allegrucci
• Re: [GENERAL] Strange performance degradation
  • From: Lorenzo Allegrucci
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: Thom Brown
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: SSD + RAID
  • From: Richard Neill
• Re: View based upon function won't use index on joins
  • From: Jonathan Foy
• Re: SSD + RAID
  • From: Jeff Janes
• Re: Partitions and max_locks_per_transaction
  • From: Hrishikesh Mehendale
• Re: View based upon function won't use index on joins
  • From: Віталій Тимчишин
• Re: Postgres query completion status?
  • From: Kevin Grittner
• Re: Strange performance degradation
  • From: Matthew Wakeling
• Re: View based upon function won't use index on joins
  • From: Jonathan Foy
• Re: [GENERAL] Strange performance degradation
  • From: Tom Lane
• Re: Postgres query completion status?
  • From: Greg Williamson
• Re: Postgres query completion status?
  • From: Thom Brown
• Re: Postgres query completion status?
  • From: Greg Smith
• Re: SSD + RAID
  • From: Matthew Wakeling
• Re: Strange performance degradation
  • From: Guillaume Cottenceau
• Re: SSD + RAID
  • From: Axel Rau
• Re: Strange performance degradation
  • From: Lorenzo Allegrucci
• Re: View based upon function won't use index on joins
  • From: Віталій Тимчишин
• Re: Strange performance degradation
  • From: A. Kretschmer
• Strange performance degradation
  • From: Lorenzo Allegrucci
• Re: Partitions and max_locks_per_transaction
  • From: Tom Lane
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: Richard Neill
• Re: Postgres query completion status?
  • From: Greg Williamson
• Postgres query completion status?
  • From: Richard Neill
• Partitions and max_locks_per_transaction
  • From: Hrishikesh (हृषीकेश मेहेंदळे)
• Re: SSD + RAID
  • From: Scott Marlowe
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Brad Nicholson
• Re: FSM - per database or per installation?
  • From: Heikki Linnakangas
• FSM - per database or per installation?
  • From: Craig James
• Re: SSD + RAID
  • From: Anton Rommerskirchen
• Re: SSD + RAID
  • From: Scott Marlowe
• View based upon function won't use index on joins
  • From: Jonathan Foy
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Karl Denninger
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Craig Ringer
• Re: SSD + RAID
  • From: Scott Carey
• Re: SSD + RAID
  • From: Scott Carey
• Re: SSD + RAID
  • From: Tom Lane
• Re: SSD + RAID
  • From: Scott Carey
• Re: SSD + RAID
  • From: Scott Carey
• Re: SSD + RAID
  • From: Kenny Gorman
• Re: Too much blocks read
  • From: A. Kretschmer
• Re: Too much blocks read
  • From: Craig James
• Re: Too much blocks read
  • From: Matthew Wakeling
• Too much blocks read
  • From: Waldomiro
• Re: Weird index or sort behaviour
  • From: Matthew Wakeling
• Re: Performance regression 8.3.8 -> 8.4.1 with NOT EXISTS
  • From: Grzegorz Jaśkiewicz
• Re: SSD + RAID
  • From: david
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Mark Mielke
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Peter Eisentraut
• Re: Is Diskeeper Automatic Mode safe?
  • From: Brad Nicholson
• Re: SSD + RAID
  • From: Scott Marlowe
• Re: SSD + RAID
  • From: Brad Nicholson
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: Performance regression 8.3.8 -> 8.4.1 with NOT EXISTS
  • From: Tom Lane
• Re: Is Diskeeper Automatic Mode safe?
  • From: Craig James
• Re: Is Diskeeper Automatic Mode safe?
  • From: Scott Marlowe
• Re: Is Diskeeper Automatic Mode safe?
  • From: Kevin Grittner
• Performance regression 8.3.8 -> 8.4.1 with NOT EXISTS
  • From: Wiktor Wodecki
• Re: Is Diskeeper Automatic Mode safe?
  • From: Greg Smith
• Re: Is Diskeeper Automatic Mode safe?
  • From: cb
• Re: Is Diskeeper Automatic Mode safe?
  • From: Scott Marlowe
• Re: Is Diskeeper Automatic Mode safe?
  • From: Greg Smith
• Re: Is Diskeeper Automatic Mode safe?
  • From: Tom Lane
• Re: Is Diskeeper Automatic Mode safe?
  • From: cb
• Re: Is Diskeeper Automatic Mode safe?
  • From: cb
• Re: Is Diskeeper Automatic Mode safe?
  • From: Scott Marlowe
• Re: Unexpected sequential scan on an indexed column
  • From: Eddy Escardo-Raffo
• Re: Unexpected sequential scan on an indexed column
  • From: Dave Crooke
• Re: Unexpected sequential scan on an indexed column
  • From: Eddy Escardo-Raffo
• Re: Is Diskeeper Automatic Mode safe?
  • From: John Rouillard
• Re: Is Diskeeper Automatic Mode safe?
  • From: Alvaro Herrera
• Re: Is Diskeeper Automatic Mode safe?
  • From: Craig James
• Re: Is Diskeeper Automatic Mode safe?
  • From: Robert Schnabel
• Re: Unexpected sequential scan on an indexed column
  • From: Kenneth Marshall
• Re: Is Diskeeper Automatic Mode safe?
  • From: Scott Marlowe
• Re: Is Diskeeper Automatic Mode safe?
  • From: Scott Marlowe
• Re: Unexpected sequential scan on an indexed column
  • From: Eddy Escardo-Raffo
• Re: Is Diskeeper Automatic Mode safe?
  • From: Karl Denninger
• Re: Is Diskeeper Automatic Mode safe?
  • From: Robert Schnabel
• Re: Is Diskeeper Automatic Mode safe?
  • From: Dave Crooke
• Re: Is Diskeeper Automatic Mode safe?
  • From: Karl Denninger
• Re: Is Diskeeper Automatic Mode safe?
  • From: Greg Smith
• Re: Is Diskeeper Automatic Mode safe?
  • From: Scott Marlowe
• Re: Is Diskeeper Automatic Mode safe?
  • From: Scott Marlowe
• Re: Is Diskeeper Automatic Mode safe?
  • From: Robert Schnabel
• Re: Is Diskeeper Automatic Mode safe?
  • From: Robert Haas
• Re: Is Diskeeper Automatic Mode safe?
  • From: Robert Schnabel
• Re: Is Diskeeper Automatic Mode safe?
  • From: Robert Haas
• Is Diskeeper Automatic Mode safe?
  • From: cb
• Re: Unexpected sequential scan on an indexed column
  • From: Dave Crooke
• Re: Manual vacs 5x faster than autovacs?
  • From: Wayne Beaver
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Wayne Beaver
• Re: Unexpected sequential scan on an indexed column
  • From: Eddy Escardo-Raffo
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: Unexpected sequential scan on an indexed column
  • From: Tom Lane
• Re: Unexpected sequential scan on an indexed column
  • From: Eddy Escardo-Raffo
• Re: Unexpected sequential scan on an indexed column
  • From: Eddy Escardo-Raffo
• Re: Unexpected sequential scan on an indexed column
  • From: Tom Lane
• Re: limiting performance impact of wal archiving.
  • From: david
• Re: Unexpected sequential scan on an indexed column
  • From: Tom Lane
• Unexpected sequential scan on an indexed column
  • From: Eddy Escardo-Raffo
• Re: SSD + RAID
  • From: Heikki Linnakangas
• Re: SSD + RAID
  • From: Craig James
• Re: FTS performance with the Polish config
  • From: Oleg Bartunov
• Re: SSD + RAID
  • From: Laszlo Nagy
• Re: SSD + RAID
  • From: Craig Ringer
• Re: SSD + RAID
  • From: Laszlo Nagy
• Re: FTS performance with the Polish config
  • From: Pavel Stehule
• Re: FTS performance with the Polish config
  • From: Oleg Bartunov
• Re: SSD + RAID
  • From: Craig Ringer
• Re: FTS performance with the Polish config
  • From: Pavel Stehule
• Re: FTS performance with the Polish config
  • From: Oleg Bartunov
• Re: SSD + RAID
  • From: Laszlo Nagy
• Re: SSD + RAID
  • From: Laszlo Nagy
• Re: Weird index or sort behaviour
  • From: Tom Lane
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: SSD + RAID
  • From: Robert Haas
• Re: SSD + RAID
  • From: Laszlo Nagy
• Re: FTS performance with the Polish config
  • From: Pavel Stehule
• Re: FTS performance with the Polish config
  • From: Tom Lane
• Re: FTS performance with the Polish config
  • From: Kenneth Marshall
• Re: SSD + RAID
  • From: Heikki Linnakangas
• Re: SSD + RAID
  • From: Merlin Moncure
• FTS performance with the Polish config
  • From: Wojciech Knapik
• Re: SSD + RAID
  • From: Heikki Linnakangas
• Re: SSD + RAID
  • From: Ivan Voras
• Re: SSD + RAID
  • From: Lists
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Craig Ringer
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Craig Ringer
• Re: SSD + RAID
  • From: Kenny Gorman
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: SSD + RAID
  • From: Greg Smith
• Re: Why age (datfrozenxid) in postgres becomes 1073742202 not zero after each vacuum of database.
  • From: Robert Haas
• Re: SSD + RAID
  • From: Fernando Hevia
• Re: SSD + RAID
  • From: Dave Crooke
• Re: SSD + RAID
  • From: Brad Nicholson
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: SSD + RAID
  • From: Karl Denninger
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Karl Denninger
• Re: SSD + RAID
  • From: Scott Carey
• Re: SSD + RAID
  • From: Greg Smith
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: SSD + RAID
  • From: Heikki Linnakangas
• Re: SSD + RAID
  • From: Merlin Moncure
• Re: SSD + RAID
  • From: Scott Marlowe
• Re: SSD + RAID
  • From: Marcos Ortiz Valmaseda
• Re: SSD + RAID
  • From: Laszlo Nagy
• Re: SSD + RAID
  • From: Karl Denninger
• SSD + RAID
  • From: Laszlo Nagy
• Re: Manual vacs 5x faster than autovacs?
  • From: Dave Crooke
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Wayne Beaver
• activerecord-jdbc-adapter bug can affect RoR query performance
  • From: Kevin Grittner
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Wayne Beaver
• Re: Manual vacs 5x faster than autovacs?
  • From: Scott Marlowe
• Re: Manual vacs 5x faster than autovacs?
  • From: Tom Lane
• Manual vacs 5x faster than autovacs?
  • From: Wayne Beaver
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Why age (datfrozenxid) in postgres becomes 1073742202 not zero after each vacuum of database.
  • From: Brahma Prakash Tiwari
• Re: limiting performance impact of wal archiving.
  • From: Scott Carey
• Re: limiting performance impact of wal archiving.
  • From: Greg Smith
• Re: Adaptec Zero-Maintenance Cache Protection - Anyone using?
  • From: Robert Schnabel
• Adaptec Zero-Maintenance Cache Protection - Anyone using?
  • From: Glyn Astill
• Database tuning at Duke
  • From: Greg Smith
• Re: limiting performance impact of wal archiving.
  • From: Jeff
• Re: limiting performance impact of wal archiving.
  • From: Scott Marlowe
• Re: limiting performance impact of wal archiving.
  • From: Greg Smith
• Re: limiting performance impact of wal archiving.
  • From: Greg Smith
• Re: limiting performance impact of wal archiving.
  • From: Greg Smith
• Re: limiting performance impact of wal archiving.
  • From: Scott Marlowe
• Re: limiting performance impact of wal archiving.
  • From: Craig James
• Re: limiting performance impact of wal archiving.
  • From: Scott Marlowe
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: limiting performance impact of wal archiving.
  • From: Greg Smith
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: limiting performance impact of wal archiving.
  • From: Kevin Grittner
• Re: limiting performance impact of wal archiving.
  • From: Scott Marlowe
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: limiting performance impact of wal archiving.
  • From: Ivan Voras
• Re: limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: limiting performance impact of wal archiving.
  • From: Ivan Voras
• Re: limiting performance impact of wal archiving.
  • From: Kenneth Marshall
• limiting performance impact of wal archiving.
  • From: Laurent Laborde
• Re: CREATE TABLE slowing down significantly over time
  • From: Greg Smith
• Re: random_page_cost for tablespace
  • From: Laszlo Nagy
• Re: CREATE TABLE slowing down significantly over time
  • From: Robert Haas
• Re: CREATE TABLE slowing down significantly over time
  • From: Scott Marlowe
• Re: CREATE TABLE slowing down significantly over time
  • From: Anj Adu
• Re: maintaining a reference to a fetched row
  • From: Dimitri Fontaine
• Re: random_page_cost for tablespace
  • From: Robert Haas
• random_page_cost for tablespace
  • From: Laszlo Nagy
• Re: CREATE TABLE slowing down significantly over time
  • From: Robert Haas
• Re: CREATE TABLE slowing down significantly over time
  • From: Grzegorz Jaśkiewicz
• Re: CREATE TABLE slowing down significantly over time
  • From: Robert Haas
• Re: CREATE TABLE slowing down significantly over time
  • From: Scott Marlowe
• Re: CREATE TABLE slowing down significantly over time
  • From: Aris Samad-Yahaya
• Re: CREATE TABLE slowing down significantly over time
  • From: Aris Samad-Yahaya
• Re: CREATE TABLE slowing down significantly over time
  • From: Craig Ringer
• Re: CREATE TABLE slowing down significantly over time
  • From: Tom Lane
• CREATE TABLE slowing down significantly over time
  • From: Aris Samad-Yahaya
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Alvaro Herrera
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Kevin Grittner
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Craig James
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Greg Smith
• High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Jay Manni
• Problem with database performance, Debian 4gb ram ?
  • From: Massan
• Re: Followup: vacuum'ing toast
  • From: Craig Ringer
• Re: Running some query in low priority
  • From: Scott Marlowe
• Re: Followup: vacuum'ing toast
  • From: Greg Smith
• Re: Running some query in low priority
  • From: Grzegorz Jaśkiewicz
• Re: Running some query in low priority
  • From: Matthew Wakeling
• Re: Running some query in low priority
  • From: Grzegorz Jaśkiewicz
• Re: Running some query in low priority
  • From: S Arvind
• Re: Followup: vacuum'ing toast
  • From: Craig Ringer
• Re: Followup: vacuum'ing toast
  • From: Craig Ringer
• Re: Running some query in low priority
  • From: Greg Stark
• Re: Running some query in low priority
  • From: Grzegorz Jaśkiewicz
• Running some query in low priority
  • From: S Arvind
• Re: Followup: vacuum'ing toast
  • From: Eduardo Morras
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Jay Manni
• Re: Optimizer + bind variables
  • From: Scott Carey
• Re: maintaining a reference to a fetched row
  • From: Jeff Janes
• Re: Followup: vacuum'ing toast
  • From: Craig Ringer
• Re: Followup: vacuum'ing toast
  • From: Greg Smith
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Craig Ringer
• Followup: vacuum'ing toast
  • From: Dave Crooke
• Re: vacuum'ing toast crumbs, detecting dangling transactions
  • From: Scott Marlowe
• Re: vacuum'ing toast crumbs, detecting dangling transactions
  • From: Kevin Grittner
• vacuum'ing toast crumbs, detecting dangling transactions
  • From: Dave Crooke
• Re: maintaining a reference to a fetched row
  • From: Tom Lane
• Re: maintaining a reference to a fetched row
  • From: Brian Karlak
• Re: maintaining a reference to a fetched row
  • From: Brian Karlak
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Anj Adu
• Re: maintaining a reference to a fetched row
  • From: Jeff Janes
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Jeff Janes
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Greg Smith
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Merlin Moncure
• Re: Free memory usage Sol10, 8.2.9
  • From: Ivan Voras
• Re: maintaining a reference to a fetched row
  • From: Tom Lane
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: David Saracini
• Re: High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Scott Marlowe
• High Frequency Inserts to Postgres Database vs Writing to a File
  • From: Jay Manni
• Re: Optimizer + bind variables
  • From: David Kerr
• Re: maintaining a reference to a fetched row
  • From: Brian Karlak
• Re: maintaining a reference to a fetched row
  • From: Craig Ringer
• Re: Optimizer + bind variables
  • From: Chris
• Re: Optimizer + bind variables
  • From: David Kerr
• Re: Optimizer + bind variables
  • From: Craig Ringer
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Re: Free memory usage Sol10, 8.2.9
  • From: Jeremy Harris
• maintaining a reference to a fetched row
  • From: Brian Karlak
• Free memory usage Sol10, 8.2.9
  • From: Subbiah Stalin-XCGF84
• Re: Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Kevin Grittner
• Optimizer + bind variables
  • From: David Kerr
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Jeff Janes
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Re: Queryplan within FTS/GIN index -search.
  • From: Tom Lane
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Kevin Grittner
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Re: Queryplan within FTS/GIN index -search.
  • From: Tom Lane
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Re: database size growing continously
  • From: Robert Haas
• Re: database size growing continously
  • From: Anj Adu
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Ivan Voras
• Re: Problem with database performance, Debian 4gb ram ?
  • From: Grzegorz Jaśkiewicz
• Problem with database performance, Debian 4gb ram ?
  • From: Grant Masan
• Re: database size growing continously
  • From: Peter Meszaros
• Re: Compression in PG
  • From: Eduardo Morras
• Re: Compression in PG
  • From: Robert Haas
• Re: Compression in PG
  • From: Scott Marlowe
• Re: Compression in PG
  • From: Adam Tauno Williams
• Re: Compression in PG
  • From: Shaul Dar
• Re: Compression in PG
  • From: Scott Marlowe
• Re: Compression in PG
  • From: Jesper Krogh
• Re: Compression in PG
  • From: Pavel Stehule
• Compression in PG
  • From: Shaul Dar
• Re: Modeling a table with arbitrary columns
  • From: Robert Haas
• Re: Queryplan within FTS/GIN index -search.
  • From: Greg Stark
• Re: Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: Queryplan within FTS/GIN index -search.
  • From: Tom Lane
• Re: database size growing continously
  • From: Greg Stark
• Re: database size growing continously
  • From: Jeremy Harris
• Re: database size growing continously
  • From: Anj Adu
• Re: database size growing continously
  • From: Greg Stark
• Re: database size growing continously
  • From: Anj Adu
• Re: Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: database size growing continously
  • From: Jeremy Harris
• Re: sub-select in IN clause results in sequential scan
  • From: Robert Haas
• Re: database size growing continously
  • From: Merlin Moncure
• Re: sub-select in IN clause results in sequential scan
  • From: Grzegorz Jaśkiewicz
• Re: Modeling a table with arbitrary columns
  • From: Віталій Тимчишин
• Re: AMD, Intel and RAID controllers
  • From: Greg Smith
• Re: optimizing query with multiple aggregates
  • From: Doug Cole
• Re: Modeling a table with arbitrary columns
  • From: Thomas Kellerer
• Modeling a table with arbitrary columns
  • From: Andreas Hartmann
• Re: database size growing continously
  • From: Scott Marlowe
• Re: query planning different in plpgsql?
  • From: Scott Carey
• Re: database size growing continously
  • From: Steve Crawford
• Re: database size growing continously
  • From: Steve Crawford
• Re: database size growing continously
  • From: Joshua D. Drake
• Re: database size growing continously
  • From: Chris Ernst
• Re: database size growing continously
  • From: Ludwik Dylag
• Re: database size growing continously
  • From: Matthew Wakeling
• Re: database size growing continously
  • From: Josh Rovero
• Re: sub-select in IN clause results in sequential scan
  • From: Anj Adu
• Re: sub-select in IN clause results in sequential scan
  • From: Robert Haas
• Re: database size growing continously
  • From: Ludwik Dylag
• Re: sub-select in IN clause results in sequential scan
  • From: Bob Lunney
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Tom Lane
• database size growing continously
  • From: Peter Meszaros
• Re: query planning different in plpgsql?
  • From: Michal J. Kubski
• Re: Postgresql optimisation
  • From: Denis BUCHER
• Re: query planning different in plpgsql?
  • From: Michal J. Kubski
• Re: sub-select in IN clause results in sequential scan
  • From: Anj Adu
• Re: sub-select in IN clause results in sequential scan
  • From: Angayarkanni
• Re: sub-select in IN clause results in sequential scan
  • From: Grzegorz Jaśkiewicz
• sub-select in IN clause results in sequential scan
  • From: Anj Adu
• Re: Postgresql optimisation
  • From: Dave Dutcher
• Re: Postgresql optimisation
  • From: Matthew Wakeling
• Re: Postgresql optimisation
  • From: Dave Dutcher
• Re: Postgresql optimisation
  • From: Greg Smith
• Re: Postgresql optimisation
  • From: Denis BUCHER
• Re: Postgresql optimisation
  • From: Kevin Grittner
• Re: Postgresql optimisation
  • From: Grzegorz Jaśkiewicz
• Re: Postgresql optimisation
  • From: Denis BUCHER
• Re: Postgresql optimisation
  • From: Grzegorz Jaśkiewicz
• Postgresql optimisation
  • From: Denis BUCHER
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Robert Haas
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: jesper
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Robert Haas
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Craig Ringer
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Jesper Krogh
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Jesper Krogh
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Craig Ringer
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Jesper Krogh
• Re: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Craig Ringer
• bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).
  • From: Jesper Krogh
• Re: query planning different in plpgsql?
  • From: Waldomiro
• Re: query planning different in plpgsql?
  • From: Tom Lane
• 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: query planning different in plpgsql?
  • From: Michal J. Kubski
• Re: query planning different in plpgsql?
  • From: Merlin Moncure
• Re: query planning different in plpgsql?
  • From: Michal J. Kubski
• Re: optimizing query with multiple aggregates
  • From: Marc Mamin
• Re: Domain vs table
  • From: decibel
• Re: Table Clustering & Time Range Queries
  • From: Greg Smith
• Re: Full text search - query plan? PG 8.4.1
  • From: Jesper Krogh
• Re: Table Clustering & Time Range Queries
  • From: Stephen Frost
• Re: Full text search - query plan? PG 8.4.1
  • From: Scott Marlowe
• 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: Calculating selectivity for the query-planner on ts_vector colums.
  • From: Jesper Krogh
• Re: Queryplan within FTS/GIN index -search.
  • From: Jeff Davis
• Re: Table Clustering & Time Range Queries
  • From: Kevin Buckham
• Re: Calculating selectivity for the query-planner on ts_vector colums.
  • From: Tom Lane
• Calculating selectivity for the query-planner on ts_vector colums.
  • From: Jesper Krogh
• Re: Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: Queryplan within FTS/GIN index -search.
  • From: Richard Huxton
• Re: query planning different in plpgsql?
  • From: Tom Lane
• Re: Queryplan within FTS/GIN index -search.
  • From: Jeff Davis
• Re: query planning different in plpgsql?
  • From: Grzegorz Jaśkiewicz
• Re: Queryplan within FTS/GIN index -search.
  • From: Jeff Davis
• Re: query planning different in plpgsql?
  • From: Scott Mead
• query planning different in plpgsql?
  • From: Michal J. Kubski
• Re: Queryplan within FTS/GIN index -search.
  • From: Richard Huxton
• Re: Queryplan within FTS/GIN index -search.
  • From: jesper
• Re: Queryplan within FTS/GIN index -search.
  • From: Richard Huxton
• Re: Queryplan within FTS/GIN index -search.
  • From: jesper
• Re: Table Clustering & Time Range Queries
  • From: Scara Maccai
• Re: Queryplan within FTS/GIN index -search.
  • From: Jeff Davis
• Re: Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: Queryplan within FTS/GIN index -search.
  • From: Jeff Davis
• Re: Partitioned Tables and ORDER BY
  • From: Scott Carey
• Re: optimizing query with multiple aggregates
  • From: Scott Carey
• Re: Table Clustering & Time Range Queries
  • From: Scott Carey
• Re: Table Clustering & Time Range Queries
  • From: Kevin Grittner
• Table Clustering & Time Range Queries
  • From: Kevin Buckham
• Re: Queryplan within FTS/GIN index -search.
  • From: Kevin Grittner
• Queryplan within FTS/GIN index -search.
  • From: Jesper Krogh
• Re: optimizing query with multiple aggregates
  • From: Robert Haas
• Re: optimizing query with multiple aggregates
  • From: Kenneth Marshall
• Re: There is a statistic table?
  • From: Cédric Villemain
• Re: maintain_cluster_order_v5.patch
  • From: Heikki Linnakangas
• Re: Random penalties on GIN index updates?
  • From: Jesper Krogh
• Re: Random penalties on GIN index updates?
  • From: Robert Haas
• Re: optimizing query with multiple aggregates
  • From: Nikolas Everett
• Re: optimizing query with multiple aggregates
  • From: David Wilson
• Re: optimizing query with multiple aggregates
  • From: Doug Cole
• Re: optimizing query with multiple aggregates
  • From: Merlin Moncure