Postgres Performance Date Index

• Thread Index

• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Merlin Moncure
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Greg Smith
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Dave Youatt
• Re: Will Postgres ever lock with read only queries?
  • From: Nikolas Everett
• Re: Will Postgres ever lock with read only queries?
  • From: Robert James
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Matthew Wakeling
• Re: Will Postgres ever lock with read only queries?
  • From: Tom Lane
• Re: Will Postgres ever lock with read only queries?
  • From: Chris
• Re: Will Postgres ever lock with read only queries?
  • From: Mark Mielke
• Will Postgres ever lock with read only queries?
  • From: Robert James
• Re: select query performance question
  • From: Mike Ivanov
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Scott Carey
• Re: More speed counting rows
  • From: Developer
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Dave Youatt
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Greg Smith
• Re: More speed counting rows
  • From: David Wilson
• Re: More speed counting rows
  • From: Chris Ernst
• Re: select query performance question
  • From: Kevin Grittner
• Re: select query performance question
  • From: Matthew Wakeling
• Re: Can Postgres use an INDEX over an OR?
  • From: Віталій Тимчишин
• Re: select query performance question
  • From: Pavel Stehule
• Re: Can Postgres use an INDEX over an OR?
  • From: Tom Lane
• select query performance question
  • From: Thomas Zaksek
• Re: More speed counting rows
  • From: Scott Marlowe
• Re: Can Postgres use an INDEX over an OR?
  • From: Віталій Тимчишин
• Re: Can Postgres use an INDEX over an OR?
  • From: Robert Haas
• Re: Can Postgres use an INDEX over an OR?
  • From: Віталій Тимчишин
• Re: Very big insert/join performance problem (bacula)
  • From: Eric Comeau
• Re: Can Postgres use an INDEX over an OR?
  • From: Robert Haas
• More speed counting rows
  • From: Developer
• Re: [BUGS] Postgres user authentification or LDAP authentification
  • From: Alvaro Herrera
• Re: Performance of quer or procedure going down when we are taking the backup
  • From: Robert Haas
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Greg Smith
• Re: Nested loop Query performance on PK
  • From: nha
• Re: Nested loop Query performance on PK
  • From: Greg Caulton
• Nested loop Query performance on PK
  • From: Greg Caulton
• Re: Very big insert/join performance problem (bacula)
  • From: Robert Haas
• Re: [BUGS] Postgres user authentification or LDAP authentification
  • From: Magnus Hagander
• Re: Configuring Postgresql for writing BLOB at a high-rate
  • From: Albe Laurenz
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Re: Very big insert/join performance problem (bacula)
  • From: Robert Haas
• Configuring Postgresql for writing BLOB at a high-rate
  • From: WANGRUNGVICHAISRI, SHIVESH
• Re: Performance difference between IN(...) and ANY(...) operator
  • From: Robert Haas
• Postgres user authentification or LDAP authentification
  • From: Lauris Ulmanis
• Re: Master/Slave, DB separation or just spend $$$?
  • From: David Rees
• Re: Atomic access to large arrays
  • From: Victor de Buen
• Re: regression ? 8.4 do not apply One-Time Filter to subquery
  • From: Robert Haas
• Re: Odd performance / query plan with bitmasked field as opposed to equality
  • From: Robert Haas
• Re: Atomic access to large arrays
  • From: Merlin Moncure
• Re: Master/Slave, DB separation or just spend $$$?
  • From: Chris Browne
• Re: Atomic access to large arrays
  • From: Victor de Buen (Bayes)
• Re: Master/Slave, DB separation or just spend $$$?
  • From: Greg Sabino Mullane
• Re: Atomic access to large arrays
  • From: Victor de Buen
• Re: Atomic access to large arrays
  • From: Tom Lane
• Re: Master/Slave, DB separation or just spend $$$?
  • From: Scott Marlowe
• Re: Atomic access to large arrays
  • From: Victor de Buen
• Re: Master/Slave, DB separation or just spend $$$?
  • From: Kelvin Quee
• Re: Master/Slave, DB separation or just spend $$$?
  • From: Scott Marlowe
• Re: Atomic access to large arrays
  • From: Oleg Bartunov
• Atomic access to large arrays
  • From: Victor de Buen (Bayes)
• Master/Slave, DB separation or just spend $$$?
  • From: Kelvin Quee
• Re: Full text search with ORDER BY performance issue
  • From: Oleg Bartunov
• Re: Used computers?
  • From: Merlin Moncure
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Jean-David Beyer
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Scott Carey
• Re: Full text search with ORDER BY performance issue
  • From: Krade
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Scott Marlowe
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Mark Mielke
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Grzegorz Jaśkiewicz
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Scott Marlowe
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Scott Marlowe
• Re: Calling conventions
  • From: Kevin Grittner
• Re: Full text search with ORDER BY performance issue
  • From: Matthew Wakeling
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Grzegorz Jaśkiewicz
• Re: Calling conventions
  • From: Matthew Wakeling
• hyperthreaded cpu still an issue in 8.4?
  • From: Doug Hunley
• Re: Full text search with ORDER BY performance issue
  • From: valgog
• Re: Full text search with ORDER BY performance issue
  • From: Scott Marlowe
• Re: Full text search with ORDER BY performance issue
  • From: Krade
• Re: Used computers?
  • From: Andy Colson
• Re: Full text search with ORDER BY performance issue
  • From: Devin Ben-Hur
• Re: Full text search with ORDER BY performance issue
  • From: Krade
• Re: Calling conventions
  • From: Tom Lane
• Re: Full text search with ORDER BY performance issue
  • From: Kevin Grittner
• Re: Fastest char datatype
  • From: Merlin Moncure
• Re: Calling conventions
  • From: Kevin Grittner
• Re: Full text search with ORDER BY performance issue
  • From: Krade
• Re: XMLPARSE() evaluated multiple times?
  • From: Tom Lane
• Re: Used computers?
  • From: Kenny Gorman
• XMLPARSE() evaluated multiple times?
  • From: Tim Landscheidt
• Re: Used computers?
  • From: Glyn Astill
• Re: Used computers?
  • From: Scott Marlowe
• Used computers?
  • From: Craig James
• Re: Can Postgres use an INDEX over an OR?
  • From: Віталій Тимчишин
• Re: Can Postgres use an INDEX over an OR?
  • From: Robert James
• Re: Fastest char datatype
  • From: Robert James
• Re: Full text search with ORDER BY performance issue
  • From: Marcin Stępnicki
• Re: Full text search with ORDER BY performance issue
  • From: Oleg Bartunov
• Re: Calling conventions
  • From: Matthew Wakeling
• Performance of quer or procedure going down when we are taking the backup
  • From: ramasubramanian
• Re: Trigger on column
  • From: A. Kretschmer
• Trigger on column
  • From: ramasubramanian
• Re: Can Postgres use an INDEX over an OR?
  • From: Chris
• Re: Can Postgres use an INDEX over an OR?
  • From: Віталій Тимчишин
• Re: Fastest char datatype
  • From: Peter Eisentraut
• Re: Poor query performance
  • From: Scott Marlowe
• Fastest char datatype
  • From: Robert James
• Can Postgres use an INDEX over an OR?
  • From: Robert James
• Full text search with ORDER BY performance issue
  • From: Krade
• Re: Concurrency issue under very heay loads
  • From: Haszlakiewicz, Eric
• Re: Calling conventions
  • From: Kevin Grittner
• Re: Calling conventions
  • From: Tom Lane
• Re: Calling conventions
  • From: Matthew Wakeling
• Re: Calling conventions
  • From: Peter Eisentraut
• Re: cluster index on a table
  • From: Kevin Grittner
• Re: cluster index on a table
  • From: Scara Maccai
• Re: Concurrency issue under very heay loads
  • From: Craig Ringer
• Re: cluster index on a table
  • From: Kevin Grittner
• Calling conventions
  • From: Matthew Wakeling
• Re: cluster index on a table
  • From: phb07@xxxxxxxxxxxx
• Re: Strange memory behavior with rails - caching in connection?
  • From: Scott Marlowe
• Re: cluster index on a table
  • From: Scara Maccai
• Re: cluster index on a table
  • From: Scara Maccai
• Re: Performance comparison between Postgres and Greenplum
  • From: Scott Marlowe
• Re: cluster index on a table
  • From: Justin Pitts
• Re: [BUGS] BUG #4919: CREATE USER command slows down systemperformance
  • From: Lauris Ulmanis
• Re: cluster index on a table
  • From: Justin Pitts
• Re: [GENERAL] Concurrency issue under very heay loads
  • From: Greenhorn
• Re: cluster index on a table
  • From: Justin Pitts
• Re: Poor overall performance unless regular VACUUM FULL
  • From: Wayne Conrad
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: toruvinn
• Re: Performance comparison between Postgres and Greenplum
  • From: Suvankar Roy
• Re: Poor overall performance unless regular VACUUM FULL
  • From: Wayne Conrad
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Lauris Ulmanis
• Re: Performance comparison between Postgres and Greenplum
  • From: Suvankar Roy
• Re: Performance comparison between Postgres and Greenplum
  • From: Suvankar Roy
• Strange memory behavior with rails - caching in connection?
  • From: Alex
• Re: Poor query performance
  • From: Alex
• Re: Poor query performance
  • From: Alex
• Re: cluster index on a table
  • From: Scott Carey
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: Mike Ivanov
• Re: cluster index on a table
  • From: Greg Stark
• Re: cluster index on a table
  • From: Scott Carey
• Re: Very big insert/join performance problem (bacula)
  • From: Kevin Grittner
• Re: Very big insert/join performance problem (bacula)
  • From: Devin Ben-Hur
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Re: Very big insert/join performance problem (bacula)
  • From: Kevin Grittner
• Re: cluster index on a table
  • From: Ibrahim Harrani
• Re: cluster index on a table
  • From: Greg Stark
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Re: cluster index on a table
  • From: Greg Stark
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: Dimitri Fontaine
• Re: cluster index on a table
  • From: Kevin Grittner
• Re: Very big insert/join performance problem (bacula)
  • From: Kevin Grittner
• Re: cluster index on a table
  • From: Scott Carey
• Re: cluster index on a table
  • From: Greg Stark
• Re: Incr/Decr Integer
  • From: Kevin Grittner
• Re: cluster index on a table
  • From: Scott Carey
• Re: cluster index on a table
  • From: Kevin Grittner
• Re: Incr/Decr Integer
  • From: Richard Huxton
• Re: cluster index on a table
  • From: Scott Carey
• Incr/Decr Integer
  • From: William Scott Jordan
• Re: cluster index on a table
  • From: Scott Carey
• Re: Poor overall performance unless regular VACUUM FULL
  • From: Wayne Conrad
• Re: cluster index on a table
  • From: Scara Maccai
• Re: cluster index on a table
  • From: Scott Mead
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: Andres Freund
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: ning
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: Andres Freund
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: ning
• Re: Concurrency issue under very heay loads
  • From: Albe Laurenz
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: Andres Freund
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Re: Concurrency issue under very heay loads
  • From: Scott Marlowe
• Re: Concurrency issue under very heay loads
  • From: ramasubramanian
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Concurrency issue under very heay loads
  • From: Raji Sridar (raji)
• Re: cluster index on a table
  • From: Scott Marlowe
• Re: Performance comparison between Postgres and Greenplum
  • From: Greg Smith
• Re: Performance comparison between Postgres and Greenplum
  • From: Greg Smith
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: ning
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: ning
• Re: Very big insert/join performance problem (bacula)
  • From: Scott Carey
• Re: Poor overall performance unless regular VACUUM FULL
  • From: Scott Marlowe
• Re: cluster index on a table
  • From: Scott Carey
• Re: Poor overall performance unless regular VACUUM FULL
  • From: Scott Carey
• Re: Very big insert/join performance problem (bacula)
  • From: Devin Ben-Hur
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: Andres Freund
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: Mike Ivanov
• Re: CREATE USER command slows down when user count per server reaches up to 500 000
  • From: Haszlakiewicz, Eric
• Re: Performance comparison between Postgres and Greenplum
  • From: Scott Mead
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Marko Kreen
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Tom Lane
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: David Wilson
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Marko Kreen
• Re: cluster index on a table
  • From: Ibrahim Harrani
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Tom Lane
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Alvaro Herrera
• Re: Poor overall performance unless regular VACUUM FULL
  • From: Scott Marlowe
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Alvaro Herrera
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Re: Very big insert/join performance problem (bacula)
  • From: Alvaro Herrera
• Re: Performance comparison between Postgres and Greenplum
  • From: Alex Goncharov
• Re: Performance comparison between Postgres and Greenplum
  • From: Alex Goncharov
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Re: Performance comparison between Postgres and Greenplum
  • From: Scott Marlowe
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: ning
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: ning
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: Greg Stark
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: Craig Ringer
• Re: Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: Craig Ringer
• Re: Poor query performance
  • From: Greg Stark
• Re: Poor query performance
  • From: Greg Stark
• Re: Poor overall performance unless regular VACUUM FULL
  • From: David Wilson
• Re: Poor overall performance unless regular VACUUM FULL
  • From: Scott Marlowe
• Re: Performance comparison between Postgres and Greenplum
  • From: Scott Marlowe
• Repeated Query is much slower in PostgreSQL8.2.4 than DB2 9.1
  • From: ning
• Performance comparison between Postgres and Greenplum
  • From: Suvankar Roy
• Poor overall performance unless regular VACUUM FULL
  • From: Wayne Conrad
• CREATE USER command slows down when user count per server reaches up to 500 000
  • From: Lauris Ulmanis
• Poor query performance
  • From: Alex
• Re: Poor query performance
  • From: Alex
• Performance difference between IN(...) and ANY(...) operator
  • From: Gnanam
• Maximum size of an XML document
  • From: Franclin Foping
• Re: [GENERAL] Postgres Clustering
  • From: Tim Uckun
• Re: embedded sql regression from 8.2.4 to 8.3.7
  • From: Albe Laurenz
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Re: Very big insert/join performance problem (bacula)
  • From: Richard Huxton
• Re: Very big insert/join performance problem (bacula)
  • From: Richard Huxton
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Odd performance / query plan with bitmasked field as opposed to equality
  • From: Frank Joerdens
• Re: embedded sql regression from 8.2.4 to 8.3.7
  • From: Haszlakiewicz, Eric
• Re: embedded sql regression from 8.2.4 to 8.3.7
  • From: Haszlakiewicz, Eric
• Re: Very big insert/join performance problem (bacula)
  • From: Andres Freund
• Re: Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Re: Very big insert/join performance problem (bacula)
  • From: SystemManagement
• Very big insert/join performance problem (bacula)
  • From: Marc Cousin
• Re: Res: Cost performace question
  • From: Matthew Wakeling
• Res: Cost performace question
  • From: paulo matadr
• Re: autovacuum hung?
  • From: Brian Cox
• Re: Cost performace question
  • From: Kevin Grittner
• Cost performace question
  • From: paulo matadr
• Re: embedded sql regression from 8.2.4 to 8.3.7
  • From: Albe Laurenz
• Re: Sorting by an arbitrary criterion
  • From: Grzegorz Jaśkiewicz
• Re: Sorting by an arbitrary criterion
  • From: Hartman, Matthew
• Re: Sorting by an arbitrary criterion
  • From: hubert depesz lubaczewski
• Re: Huge difference in query performance between 8.3 and 8.4 (possibly)
  • From: Hartman, Matthew
• embedded sql regression from 8.2.4 to 8.3.7
  • From: Haszlakiewicz, Eric
• Re: Huge difference in query performance between 8.3 and 8.4 (possibly)
  • From: Tom Lane
• Re: Huge difference in query performance between 8.3 and 8.4 (possibly)
  • From: Alvaro Herrera
• Re: Sorting by an arbitrary criterion
  • From: Alexander Staubo
• Re: Sorting by an arbitrary criterion
  • From: Kevin Grittner
• Re: Sorting by an arbitrary criterion
  • From: Tom Lane
• Huge difference in query performance between 8.3 and 8.4 (possibly)
  • From: Robin Houston
• Re: Sorting by an arbitrary criterion
  • From: Grzegorz Jaśkiewicz
• Sorting by an arbitrary criterion
  • From: Craig James
• Re: Data caching
  • From: Richard Huxton
• Data caching
  • From: Martin Chlupac
• Re: Bundling postgreSQL with my Java application
  • From: Kevin Grittner
• Re: Speeding up a query.
  • From: Hartman, Matthew
• Re: Speeding up a query.
  • From: Simon Riggs
• Re: Bundling postgreSQL with my Java application
  • From: Scott Marlowe
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Scott Marlowe
• Re: Bundling postgreSQL with my Java application
  • From: Saurabh Dave
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Craig Ringer
• Re: Bundling postgreSQL with my Java application
  • From: justin
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Mark Mielke
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Dave Page
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Greg Smith
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Stephen Frost
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Greg Stark
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Scott Carey
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Scott Carey
• Re: Bundling postgreSQL with my Java application
  • From: Mark Mielke
• Re: Bundling postgreSQL with my Java application
  • From: Saurabh Dave
• Re: Bundling postgreSQL with my Java application
  • From: Guillaume Cottenceau
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Mark Kirkwood
• Re: Bundling postgreSQL with my Java application
  • From: Mark Mielke
• Bundling postgreSQL with my Java application
  • From: Saurabh Dave
• Re: Six PostgreSQL questions from a pokerplayer
  • From: Craig Ringer
• Six PostgreSQL questions from a pokerplayer
  • From: Patvs
• Re: - Slow Query
  • From: Віталій Тимчишин
• Re: Most effective insert or replace
  • From: Matthew Wakeling
• Re: - Slow Query
  • From: Віталій Тимчишин
• Most effective insert or replace
  • From: Sergei Politov
• Re: slow DELETE on 12 M row table
  • From: Scott Marlowe
• Re: slow DELETE on 12 M row table
  • From: Janet Jacobsen
• regression ? 8.4 do not apply One-Time Filter to subquery
  • From: Sergey Burladyan
• Re: - Slow Query
  • From: Tom Lane
• Re: - Slow Query
  • From: Scott Marlowe
• Re: - Slow Query
  • From: Mike Ivanov
• Re: - Slow Query
  • From: Tom Lane
• Re: - Slow Query
  • From: Scott Marlowe
• Re: - Slow Query
  • From: Rui Carvalho
• Re: - Slow Query
  • From: Mike Ivanov
• Re: - Slow Query
  • From: justin
• Re: - Slow Query
  • From: Mike Ivanov
• - Slow Query
  • From: Rui Carvalho
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Scott Carey
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Scott Carey
• Re: random slow query
  • From: Scott Carey
• Re: random slow query
  • From: Scott Carey
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Jean-David Beyer
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Alan Hodgson
• Re: random slow query
  • From: Scott Marlowe
• Re: random slow query
  • From: Scott Marlowe
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Scott Marlowe
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Scott Marlowe
• Re: random slow query
  • From: Sean Ma
• Re: random slow query
  • From: Scott Marlowe
• Re: random slow query
  • From: Mike Ivanov
• Re: random slow query
  • From: Sean Ma
• Re: Utilizing multiple cores in a function call.
  • From: Hartman, Matthew
• Re: Utilizing multiple cores in a function call.
  • From: Merlin Moncure
• Re: Utilizing multiple cores in a function call.
  • From: Hartman, Matthew
• Re: Insert performance and multi-column index order
  • From: Bob Lunney
• Re: Terrible Write Performance of a Stored Procedure
  • From: valgog
• Re: Utilizing multiple cores in a function call.
  • From: Craig Ringer
• Re: random slow query
  • From: Mike Ivanov
• Re: Utilizing multiple cores in a function call.
  • From: Merlin Moncure
• Re: Utilizing multiple cores in a function call.
  • From: Greg Smith
• Re: Utilizing multiple cores in a function call.
  • From: Joe Conway
• Re: Utilizing multiple cores in a function call.
  • From: Hartman, Matthew
• Re: random slow query
  • From: Kevin Grittner
• Re: Utilizing multiple cores in a function call.
  • From: Jean-David Beyer
• Utilizing multiple cores in a function call.
  • From: Hartman, Matthew
• Re: random slow query
  • From: Andres Freund
• random slow query
  • From: Sean Ma
• Re: Terrible Write Performance of a Stored Procedure
  • From: Scott Mead
• Re: what server stats to track / monitor ?
  • From: Alan McKay
• Re: slow DELETE on 12 M row table
  • From: Robert Haas
• Re: slow DELETE on 12 M row table
  • From: Scott Carey
• Re: Insert performance and multi-column index order
  • From: Greg Smith
• Re: what server stats to track / monitor ?
  • From: Greg Smith
• Re: slow DELETE on 12 M row table
  • From: Robert Haas
• Re: slow DELETE on 12 M row table
  • From: Janet Jacobsen
• Re: Insert performance and multi-column index order
  • From: Tom Lane
• Re: Terrible Write Performance of a Stored Procedure
  • From: Greg Smith
• Re: Nested Loop "Killer" on 8.1
  • From: Tom Lane
• Re: Terrible Write Performance of a Stored Procedure
  • From: Scott Mead
• Re: Terrible Write Performance of a Stored Procedure
  • From: Brian Troutwine
• Re: Terrible Write Performance of a Stored Procedure
  • From: Brian Troutwine
• Re: Terrible Write Performance of a Stored Procedure
  • From: Merlin Moncure
• Re: Terrible Write Performance of a Stored Procedure
  • From: Alan Hodgson
• Terrible Write Performance of a Stored Procedure
  • From: Brian Troutwine
• Re: Nested Loop "Killer" on 8.1
  • From: Dave North
• Insert performance and multi-column index order
  • From: bob_lunney
• Re: GiST index performance
  • From: Robert Haas
• Re: GiST index performance
  • From: Greg Smith
• Re: slow DELETE on 12 M row table
  • From: Marcin Stępnicki
• Re: slow DELETE on 12 M row table
  • From: Janet Jacobsen
• Re: slow DELETE on 12 M row table
  • From: Richard Huxton
• Re: slow DELETE on 12 M row table
  • From: Greg Stark
• slow DELETE on 12 M row table
  • From: Janet Jacobsen
• Re: Nested Loop "Killer" on 8.1
  • From: Greg Stark
• Re: Nested Loop "Killer" on 8.1
  • From: Tom Lane
• Re: Nested Loop "Killer" on 8.1
  • From: Mark Mielke
• Re: Nested Loop "Killer" on 8.1
  • From: Greg Stark
• Re: Nested Loop "Killer" on 8.1
  • From: Josh Berkus
• Re: Implications of having large number of users
  • From: Mike Ivanov
• Re: tsvector_update_trigger performance?
  • From: Dimitri Fontaine
• Re: tsvector_update_trigger performance?
  • From: Craig Ringer
• Re: tsvector_update_trigger performance?
  • From: Chris St Denis
• Re: tsvector_update_trigger performance?
  • From: Dimitri Fontaine
• Re: cluster index on a table
  • From: Scott Marlowe
• Re: cluster index on a table
  • From: Kenneth Marshall
• cluster index on a table
  • From: Ibrahim Harrani
• Re: tsvector_update_trigger performance?
  • From: Alvaro Herrera
• Re: Implications of having large number of users
  • From: Robert Haas
• Re: Implications of having large number of users
  • From: Tom Lane
• Re: Implications of having large number of users
  • From: Albe Laurenz
• Nested Loop "Killer" on 8.1
  • From: Dave North
• Re: Implications of having large number of users
  • From: Robert Haas
• Re: Implications of having large number of users
  • From: Albe Laurenz
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: tsvector_update_trigger performance?
  • From: Oleg Bartunov
• tsvector_update_trigger performance?
  • From: Chris St Denis
• Re: How would you store read/unread topic status?
  • From: Chris St Denis
• Re: How would you store read/unread topic status?
  • From: Greg Stark
• SOLVED: processor running queue - general rule of thumb?
  • From: Alan McKay
• Re: How would you store read/unread topic status?
  • From: Craig James
• Re: processor running queue - general rule of thumb?
  • From: Alan McKay
• Re: How would you store read/unread topic status?
  • From: Alexander Staubo
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Implications of having large number of users
  • From: Mike Ivanov
• Re: How would you store read/unread topic status?
  • From: Greg Stark
• Re: How would you store read/unread topic status?
  • From: Scott Carey
• Re: How would you store read/unread topic status?
  • From: Scott Carey
• Re: How would you store read/unread topic status?
  • From: Mike
• Re: How would you store read/unread topic status?
  • From: Mike
• Re: How would you store read/unread topic status?
  • From: Robert Haas
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: How would you store read/unread topic status?
  • From: Grzegorz Jaśkiewicz
• Re: How would you store read/unread topic status?
  • From: Robert Haas
• Re: How would you store read/unread topic status?
  • From: Andres Freund
• Re: How would you store read/unread topic status?
  • From: Guillaume Cottenceau
• Re: How would you store read/unread topic status?
  • From: Robert Haas
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: How would you store read/unread topic status?
  • From: Matthew Wakeling
• Re: How would you store read/unread topic status?
  • From: Nikolas Everett
• Re: How would you store read/unread topic status?
  • From: justin
• Re: How would you store read/unread topic status?
  • From: Andres Freund
• Re: How would you store read/unread topic status?
  • From: Alexander Staubo
• Re: How would you store read/unread topic status?
  • From: Andres Freund
• How would you store read/unread topic status?
  • From: Mathieu Nebra
• Re: same query in high number of times
  • From: Laurent Laborde
• Re: same query in high number of times
  • From: Laurent Laborde
• Re: same query in high number of times
  • From: Scott Carey
• Re: same query in high number of times
  • From: Peter Alban
• Re: same query in high number of times
  • From: Robert Haas
• Re: same query in high number of times
  • From: Justin Graf
• Re: same query in high number of times
  • From: Scott Marlowe
• Re: same query in high number of times
  • From: Peter Alban
• Re: same query in high number of times
  • From: Justin Graf
• Re: same query in high number of times
  • From: Grzegorz Jaśkiewicz
• Re: same query in high number of times
  • From: Justin Graf
• Re: same query in high number of times
  • From: Peter Alban
• Re: same query in high number of times
  • From: Robert Haas
• Re: same query in high number of times
  • From: Justin Graf
• same query in high number of times
  • From: Peter Alban
• Re: select max() much slower than select min()
  • From: David Rees
• Re: select max() much slower than select min()
  • From: Brian Cox
• Re: select max() much slower than select min()
  • From: David Rees
• Re: select max() much slower than select min()
  • From: Brian Cox
• Re: processor running queue - general rule of thumb?
  • From: Alan McKay
• Re: processor running queue - general rule of thumb?
  • From: Scott Marlowe
• Re: processor running queue - general rule of thumb?
  • From: justin
• processor running queue - general rule of thumb?
  • From: Alan McKay
• Re: select max() much slower than select min()
  • From: Greg Stark
• Re: 8.4 COPY performance regression on Solaris
  • From: Tom Lane
• Re: select max() much slower than select min()
  • From: Tom Lane
• Re: select max() much slower than select min()
  • From: Dave Dutcher
• Re: 8.4 COPY performance regression on Solaris
  • From: Kenneth Marshall
• Re: select max() much slower than select min()
  • From: Kevin Grittner
• Re: select max() much slower than select min()
  • From: Brian Cox
• Re: select max() much slower than select min()
  • From: Kevin Grittner
• select max() much slower than select min()
  • From: Brian Cox
• Re: Index Scan taking long time
  • From: Bryce Ewing
• Re: Strange performance response for high load times
  • From: Kevin Grittner
• Re: Strange performance response for high load times
  • From: Peter Alban
• Re: Strange performance response for high load times
  • From: Kenneth Marshall
• Re: performance with query
  • From: Kevin Grittner
• Re: Strange performance response for high load times
  • From: Peter Alban
• Re: performance with query
  • From: Tom Lane
• Re: performance with query
  • From: Kevin Grittner
• Re: Strange performance response for high load times
  • From: Kenneth Marshall
• Strange performance response for high load times
  • From: Peter Alban
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Grzegorz Jaśkiewicz
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: very slow selects on a small table
  • From: Grzegorz Jaśkiewicz
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: enum for performance?
  • From: Merlin Moncure
• Re: performance with query
  • From: Alberto Dalmaso
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Brian Cox
• Re: Index Scan taking long time
  • From: Tom Lane
• Re: very slow selects on a small table
  • From: Tom Lane
• Re: enum for performance?
  • From: Tom Lane
• enum for performance?
  • From: Whit Armstrong
• Re: Index Scan taking long time
  • From: Bryce Ewing
• very slow selects on a small table
  • From: Brian Cox
• Re: Performance issue - 2 linux machines, identical configs, different performance
  • From: Mark Steben
• Re: Performance issue - 2 linux machines, identical configs, different performance
  • From: Dave Dutcher
• Re: Performance issue - 2 linux machines, identical configs, different performance
  • From: Robert Haas
• Performance issue - 2 linux machines, identical configs, different performance
  • From: Mark Steben
• Re: performance with query
  • From: Kevin Grittner
• Re: Speeding up a query.
  • From: Hartman, Matthew
• Re: performance with query
  • From: Alberto Dalmaso
• Re: Speeding up a query.
  • From: Tom Lane
• Re: Speeding up a query.
  • From: Hartman, Matthew
• Re: Speeding up a query.
  • From: Hartman, Matthew
• Re: Speeding up a query.
  • From: Kevin Grittner
• Re: performance with query
  • From: Kevin Grittner
• Re: Index Scan taking long time
  • From: Tom Lane
• Re: Speeding up a query.
  • From: Merlin Moncure
• Re: GiST index performance
  • From: Heikki Linnakangas
• Re: Speeding up a query.
  • From: Alberto Dalmaso
• Re: Speeding up a query.
  • From: Grzegorz Jaśkiewicz
• Re: 8.4 COPY performance regression on Solaris
  • From: Stefan Kaltenbrunner
• Re: Speeding up a query.
  • From: Albe Laurenz
• Re: performance with query (OT)
  • From: Albe Laurenz
• Re: performance with query
  • From: Alberto Dalmaso
• 8.4 COPY performance regression on Solaris
  • From: Alan Li
• Re: Index Scan taking long time
  • From: Scott Marlowe
• Re: Yet another slow nested loop
  • From: Robert Haas
• Re: High cost of ... where ... not in (select ...)
  • From: Tom Lane
• Index Scan taking long time
  • From: Bryce Ewing
• Re: High cost of ... where ... not in (select ...)
  • From: Aaron Turner
• Re: High cost of ... where ... not in (select ...)
  • From: Aaron Turner
• Re: High cost of ... where ... not in (select ...)
  • From: Robert Haas
• Re: High cost of ... where ... not in (select ...)
  • From: Aaron Turner
• Re: High cost of ... where ... not in (select ...)
  • From: Robert Haas
• Re: High cost of ... where ... not in (select ...)
  • From: Aaron Turner
• Re: High cost of ... where ... not in (select ...)
  • From: Alvaro Herrera
• High cost of ... where ... not in (select ...)
  • From: Aaron Turner
• Performance discrepancy
  • From: Mark Steben
• Re: Speeding up a query.
  • From: Anthony Presley
• Speeding up a query.
  • From: Hartman, Matthew
• Re: performance with query
  • From: Alberto Dalmaso
• Re: performance with query
  • From: Alberto Dalmaso
• Re: performance with query
  • From: Tom Lane
• Re: performance with query
  • From: Kevin Grittner
• Re: performance with query
  • From: Alberto Dalmaso
• Re: performance with query
  • From: Kevin Grittner
• Re: performance with query
  • From: Alberto Dalmaso
• Re: performance with query
  • From: Kevin Grittner
• Re: performance with query
  • From: Tom Lane
• Re: Yet another slow nested loop
  • From: Alexander Staubo
• Re: performance with query
  • From: Alberto Dalmaso
• Re: performance with query
  • From: Kevin Grittner
• Re: performance with query
  • From: Matthew Wakeling
• Re: performance with query
  • From: Alberto Dalmaso
• Re: Yet another slow nested loop
  • From: Tom Lane
• Re: performance with query
  • From: Kevin Grittner
• Re: performance with query
  • From: Joshua Tolley
• Re: Yet another slow nested loop
  • From: Alexander Staubo
• Re: Yet another slow nested loop
  • From: Dave Dutcher
• performance with query
  • From: Alberto Dalmaso
• Yet another slow nested loop
  • From: Alexander Staubo
• Re: Postgres connection status as BIND
  • From: Alan Hodgson
• Re: Postgres connection status as BIND
  • From: Tom Lane
• Postgres connection status as BIND
  • From: Nimesh Satam
• Re: Censorship
  • From: Dan Langille
• Re: what server stats to track / monitor ?
  • From: Joshua Tolley
• Re: what server stats to track / monitor ?
  • From: Rauan Maemirov
• Re: what server stats to track / monitor ?
  • From: Alan McKay
• Re: what server stats to track / monitor ?
  • From: Alan McKay
• Re: what server stats to track / monitor ?
  • From: Joshua Tolley
• what server stats to track / monitor ?
  • From: Alan McKay
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Greg Sabino Mullane
• Re: GiST index performance
  • From: Adam Gundy
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Shaul Dar
• Re: Best way to load test a postgresql server
  • From: Erik Aronesty
• Re: GiST index performance
  • From: Tom Lane
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Joshua D. Drake
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Greg Sabino Mullane
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Joshua D. Drake
• Re: GiST index performance
  • From: Tom Lane
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Postgres replication: dump/restore, PITR, Slony,...?
  • From: Dimitri Fontaine
• Re: GiST index performance
  • From: Tom Lane
• Postgres replication: dump/restore, PITR, Slony,...?
  • From: Shaul Dar
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Hosted servers with good DB disk performance?
  • From: Dimitri Fontaine
• Re: Looking for installations with a large number of concurrent users
  • From: David Kerr
• Re: Why is my stats collector so busy?
  • From: Tom Lane
• Re: GiST index performance
  • From: Tom Lane
• Re: Looking for installations with a large number of concurrent users
  • From: Kevin Grittner
• Re: Explaining an EXPLAIN.
  • From: Matthew Wakeling
• Re: Explaining an EXPLAIN.
  • From: Tom Lane
• Re: EXPLAIN understanding? (restarted from Censorship)
  • From: Richard Huxton
• EXPLAIN understanding? (restarted from Censorship)
  • From: Richard Huxton
• Explaining an EXPLAIN.
  • From: Matthew Wakeling
• Re: Censorship
  • From: Tom Lane
• Re: Censorship
  • From: Matthew Wakeling
• Re: Censorship
  • From: Scott Mead
• Re: Censorship
  • From: Matthew Wakeling
• Re: Censorship
  • From: Gurjeet Singh
• Re: Censorship
  • From: Matthew Wakeling
• Re: Censorship
  • From: Guillaume Cottenceau
• Censorship
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: Hosted servers with good DB disk performance?
  • From: Markus Wanner
• Re: Why is my stats collector so busy?
  • From: Laszlo Nagy
• Looking for installations with a large number of concurrent users
  • From: David Kerr
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Best way to load test a postgresql server
  • From: Tom Lane
• Re: Best way to load test a postgresql server
  • From: Shaul Dar
• Re: Pointers needed on optimizing slow SQL statements
  • From: Dimitri Fontaine
• Re: Pointers needed on optimizing slow SQL statements
  • From: Віталій Тимчишин
• Re: Problems with autovacuum
  • From: Tom Lane
• Re: Problems with autovacuum
  • From: Alvaro Herrera
• Re: Why is my stats collector so busy?
  • From: Laszlo Nagy
• Re: Pointers needed on optimizing slow SQL statements
  • From: Robert Haas
• Re: Pointers needed on optimizing slow SQL statements
  • From: Dimitri Fontaine
• Postgres installation for Performance
  • From: S Arvind
• Re: Vacuum ALL FULL
  • From: S Arvind
• Re: Vacuum ALL FULL
  • From: Tom Lane
• Re: Vacuum ALL FULL
  • From: S Arvind
• Re: Vacuum ALL FULL
  • From: Tom Lane
• Re: Vacuum ALL FULL
  • From: S Arvind
• Re: Vacuum ALL FULL
  • From: S Arvind
• Re: Vacuum ALL FULL
  • From: Tom Lane
• Re: Vacuum ALL FULL
  • From: S Arvind
• Vacuum ALL FULL
  • From: S Arvind
• Re: Pointers needed on optimizing slow SQL statements
  • From: Simon Riggs
• Re: degenerate performance on one server of 3
  • From: Robert Haas
• Re: Bad Plan for Questionnaire-Type Query
  • From: Robert Haas
• Re: degenerate performance on one server of 3
  • From: Erik Aronesty
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Bad Plan for Questionnaire-Type Query
  • From: Josh Berkus
• Re: Bad Plan for Questionnaire-Type Query
  • From: David Blewett
• Re: Scalability in postgres
  • From: Robert Haas
• Re: GiST index performance
  • From: Robert Haas
• Re: Why is my stats collector so busy?
  • From: Robert Schnabel
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Craig James
• Re: Scalability in postgres
  • From: Robert Haas
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Why is my stats collector so busy?
  • From: Merlin Moncure
• Re: Why is my stats collector so busy?
  • From: Tom Lane
• Re: Why is my stats collector so busy?
  • From: Bruce Momjian
• Why is my stats collector so busy?
  • From: Laszlo Nagy
• Re: Scalability in postgres
  • From: Mark Mielke
• Re: Scalability in postgres
  • From: david
• Re: Scalability in postgres
  • From: david
• Re: Scalability in postgres
  • From: Greg Smith
• Re: Scalability in postgres
  • From: Mark Mielke
• Re: Scalability in postgres
  • From: Robert Haas
• Re: Scalability in postgres
  • From: david
• Re: Scalability in postgres
  • From: Scott Carey
• Re: Scalability in postgres
  • From: david
• Re: Scalability in postgres
  • From: Mark Mielke
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Scalability in postgres
  • From: Kevin Grittner
• Re: Scalability in postgres
  • From: James Mansion
• Re: Pointers needed on optimizing slow SQL statements
  • From: Josh Berkus
• Re: Scalability in postgres
  • From: Robert Haas
• Re: degenerate performance on one server of 3
  • From: Scott Carey
• Re: Scalability in postgres
  • From: Scott Carey
• Re: degenerate performance on one server of 3
  • From: Scott Carey
• Re: Query plan issues - volatile tables
  • From: Craig James
• GiST index performance
  • From: Matthew Wakeling
• Re: degenerate performance on one server of 3
  • From: Robert Haas
• Re: degenerate performance on one server of 3
  • From: Erik Aronesty
• Re: Scalability in postgres
  • From: Robert Haas
• Re: Scalability in postgres
  • From: Marc Cousin
• Re: Pointers needed on optimizing slow SQL statements
  • From: Scott Marlowe
• Re: degenerate performance on one server of 3
  • From: Reid Thompson
• Re: Pointers needed on optimizing slow SQL statements
  • From: Janine Sisk
• Query plan issues - volatile tables
  • From: Brian Herlihy
• Re: Pointers needed on optimizing slow SQL statements
  • From: Robert Haas
• Re: Best way to load test a postgresql server
  • From: Greg Smith
• Re: Pointers needed on optimizing slow SQL statements
  • From: Janine Sisk
• Re: Pointers needed on optimizing slow SQL statements
  • From: Tom Lane
• Pointers needed on optimizing slow SQL statements
  • From: Janine Sisk
• Re: degenerate performance on one server of 3
  • From: Tom Lane
• Re: Scalability in postgres
  • From: Scott Carey
• Re: degenerate performance on one server of 3
  • From: Erik Aronesty
• Re: Scalability in postgres
  • From: Robert Haas
• Re: Scalability in postgres
  • From: Scott Carey
• Re: Scalability in postgres
  • From: Dimitri