Postgres Performance Date Index

• Thread Index

• Re: moving data between tables causes the db to overwhelm the system
  • From: Pierre Frédéric Caillaud
• Re: moving data between tables causes the db to overwhelm the system
  • From: tv
• Re: moving data between tables causes the db to overwhelm the system
  • From: Kevin Kempter
• Re: moving data between tables causes the db to overwhelm the system
  • From: Pierre Frédéric Caillaud
• Re: moving data between tables causes the db to overwhelm the system
  • From: tv
• moving data between tables causes the db to overwhelm the system
  • From: Kevin Kempter
• Re: Number of tables
  • From: Mike Ivanov
• Re: Number of tables
  • From: Greg Stark
• Re: Number of tables
  • From: Mike Ivanov
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Scott Marlowe
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Kevin Grittner
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Jeff Janes
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Aidan Van Dyk
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Merlin Moncure
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Greg Stark
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Merlin Moncure
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Joseph S
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Mark Mielke
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Greg Stark
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Merlin Moncure
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Jeff Janes
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Greg Stark
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Tom Lane
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Jean-Michel Pouré
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: David Rees
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Tom Lane
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Jean-Michel Pouré
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Bruce Momjian
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Scott Marlowe
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Merlin Moncure
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Greg Stark
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Luke Koops
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Jeff Janes
• Re: Memory monitoring tool
  • From: Josh Berkus
• Memory monitoring tool
  • From: Jean-Michel Pouré
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Joseph S
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Joseph S
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Scott Marlowe
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Greg Smith
• Re: What exactly is postgres doing during INSERT/UPDATE ?
  • From: Pierre Frédéric Caillaud
• What exactly is postgres doing during INSERT/UPDATE ?
  • From: Joseph S
• Re: Vacuum duration + hint bits?
  • From: bricklen
• Re: Vacuum duration + hint bits?
  • From: Tom Lane
• Vacuum duration + hint bits?
  • From: bricklen
• Re: Performance issues with large amounts of time-series data
  • From: Greg Smith
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Jean-Michel Pouré
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Jean-Michel Pouré
• Re: Performance regression between 8.3 and 8.4 on heavy text indexing
  • From: Guillaume Smet
• Re: Performance regression between 8.3 and 8.4 on heavy text indexing
  • From: Gaël Le Mignot
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Tom Lane
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Robert Haas
• Re: PostgreSQL
  • From: Jean-Michel Pouré
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Kevin Grittner
• Re: PostgreSQL does CAST implicitely between int andadomain derived from int
  • From: Jean-Michel Pouré
• Re: PostgreSQL does CAST implicitely between int andadomain derived from int
  • From: Kevin Grittner
• Re: PostgreSQL does CAST implicitely between int and adomain derived from int
  • From: Jean-Michel Pouré
• Re: PostgreSQL does CAST implicitely between int and adomain derived from int
  • From: Kevin Grittner
• Re: PostgreSQL does CAST implicitely between int and adomain derived from int
  • From: Jean-Michel Pouré
• Re: PostgreSQL does CAST implicitely between int and adomain derived from int
  • From: Kevin Grittner
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Jean-Michel Pouré
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Jean-Michel Pouré
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Kevin Grittner
• Re: PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Kevin Grittner
• Re: Performance regression between 8.3 and 8.4 on heavy text indexing
  • From: Guillaume Smet
• Re: Performance issues with large amounts of time-series data
  • From: Greg Stark
• Re: Performance issues with large amounts of time-series data
  • From: Tom Lane
• Re: Performance issues with large amounts of time-series data
  • From: Hrishikesh (हृषीकेश मेहेंदळे)
• Re: Performance issues with large amounts of time-series data
  • From: Tom Lane
• Performance issues with large amounts of time-series data
  • From: Hrishikesh (हृषीकेश मेहेंदळे)
• Re: Performance regression between 8.3 and 8.4 on heavy text indexing
  • From: Tom Lane
• Re: Performance regression between 8.3 and 8.4 on heavy text indexing
  • From: Gaël Le Mignot
• Re: PostgreSQL does CAST implicitely between int and a domain derivedfrom int
  • From: Kevin Grittner
• PostgreSQL does CAST implicitely between int and a domain derived from int
  • From: Jean-Michel Pouré
• Re: Fwd: How to create a multi-column index with 2 dates using 'gist'?
  • From: Matthew Wakeling
• Re: [PERFORMANCE] how to set wal_buffers
  • From: Jaime Casanova
• Fwd: How to create a multi-column index with 2 dates using 'gist'?
  • From: Fred Janon
• Re: Indexing on a circle datatype
  • From: Gavin Love
• Re: Indexing on a circle datatype
  • From: Tom Lane
• Re: Indexing on a circle datatype
  • From: Matthew Wakeling
• Indexing on a circle datatype
  • From: Gavin Love
• Re: improving my query plan
  • From: Kevin Grittner
• Re: postgresql uses Hash-join, i need Nested-loop
  • From: Tom Lane
• Re: Number of tables
  • From: Kevin Grittner
• postgresql uses Hash-join, i need Nested-loop
  • From: Gábor Farkas
• Re: [PERFORMANCE] how to set wal_buffers
  • From: Jeff Janes
• Re: limiting results makes the query slower
  • From: Robert Haas
• Re: [PERFORMANCE] how to set wal_buffers
  • From: Jaime Casanova
• Re: Performance regression between 8.3 and 8.4 on heavy text indexing
  • From: Guillaume Smet
• Re: Number of tables
  • From: Robert Haas
• Re: number of rows estimation for bit-AND operation
  • From: Slava Moudry
• Re: Number of tables
  • From: Jerry Champlin
• Re: number of rows estimation for bit-AND operation
  • From: Alvaro Herrera
• Re: number of rows estimation for bit-AND operation
  • From: Robert Haas
• Performance regression between 8.3 and 8.4 on heavy text indexing
  • From: Gaël Le Mignot
• [PERFORMANCE] how to set wal_buffers
  • From: Jeff Janes
• Re: number of rows estimation for bit-AND operation
  • From: Slava Moudry
• Re: number of rows estimation for bit-AND operation
  • From: Scott Marlowe
• limiting results makes the query slower
  • From: Jaime Casanova
• Re: improving my query plan
  • From: Scott Carey
• Re: number of rows estimation for bit-AND operation
  • From: Scott Marlowe
• Re: improving my query plan
  • From: Chris
• Re: Number of tables
  • From: Greg Stark
• Re: Number of tables
  • From: Alvaro Herrera
• Re: Number of tables
  • From: Greg Stark
• improving my query plan
  • From: Kevin Kempter
• Re: Number of tables
  • From: Craig James
• Re: Number of tables
  • From: Greg Stark
• Re: Number of tables
  • From: Craig James
• Re: number of rows estimation for bit-AND operation
  • From: Robert Haas
• Re: PG 8.3 and server load
  • From: Ivan Voras
• Re: Query tuning
  • From: Віталій Тимчишин
• Re: Number of tables
  • From: Fabio La Farcioli
• Re: Number of tables
  • From: Craig Ringer
• Re: Number of tables
  • From: Jochen Erwied
• Number of tables
  • From: Fabio La Farcioli
• [PERFORMANCE] work_mem vs temp files issue
  • From: Jaime Casanova
• [PERFORMANCE] how to set wal_buffers
  • From: Jaime Casanova
• Re: Query tuning
  • From: Kevin Kempter
• Re: Query tuning
  • From: Kevin Kempter
• Re: Query tuning
  • From: Nikolas Everett
• Re: Query tuning
  • From: Scott Carey
• Re: Query tuning
  • From: Grzegorz Jaśkiewicz
• Query tuning
  • From: Kevin Kempter
• Re: PG 8.3 and server load
  • From: Scott Marlowe
• Re: PG 8.3 and server load
  • From: Guillaume Cottenceau
• Re: PG 8.3 and server load
  • From: Tom Lane
• Re: PG 8.3 and server load
  • From: Andy Colson
• Re: PG 8.3 and server load
  • From: Phoenix Kiula
• Re: PG 8.3 and server load
  • From: Matthew Wakeling
• Re: PG 8.3 and server load
  • From: Andy Colson
• Re: PG 8.3 and server load
  • From: Kevin Grittner
• Re: PG 8.3 and server load
  • From: Phoenix Kiula
• Re: PG 8.3 and server load
  • From: Andy Colson
• Re: PG 8.3 and server load
  • From: Karl Denninger
• Re: PG 8.3 and server load
  • From: Andy Colson
• Re: PG 8.3 and server load
  • From: Guillaume Cottenceau
• Re: PG 8.3 and server load
  • From: Ivan Voras
• PG 8.3 and server load
  • From: Phoenix Kiula
• Re: Weird index or sort behaviour
  • From: Matthew Wakeling
• Re: SQL Query Performance - what gives?
  • From: Ivan Voras
• Re: [SQL] SQL Query Performance - what gives?
  • From: Pierre Frédéric Caillaud
• Re: [SQL] SQL Query Performance - what gives?
  • From: Karl Denninger
• Re: [SQL] SQL Query Performance - what gives?
  • From: Tom Lane
• Re: SQL Query Performance - what gives?
  • From: Karl Denninger
• Re: number of rows estimation for bit-AND operation
  • From: Slava Moudry
• Re: number of rows estimation for bit-AND operation
  • From: Slava Moudry
• Re: number of rows estimation for bit-AND operation
  • From: Scott Marlowe
• Re: SQL Query Performance - what gives?
  • From: Kevin Grittner
• Re: number of rows estimation for bit-AND operation
  • From: Scott Marlowe
• Re: SQL Query Performance - what gives?
  • From: Karl Denninger
• Re: SQL Query Performance - what gives?
  • From: Kevin Grittner
• SQL Query Performance - what gives?
  • From: Karl Denninger
• Re: Weird index or sort behaviour
  • From: Matthew Wakeling
• Re: Weird index or sort behaviour
  • From: Tom Lane
• Re: Weird index or sort behaviour
  • From: Tom Lane
• Re: Weird index or sort behaviour
  • From: Greg Stark
• Re: Weird index or sort behaviour
  • From: Tom Lane
• Re: Weird index or sort behaviour
  • From: Tom Lane
• Re: Weird index or sort behaviour
  • From: Matthew Wakeling
• Re: Weird index or sort behaviour
  • From: Tom Lane
• Re: Need suggestions on kernel settings for dedicated FreeBSD/Postgresql machine
  • From: Ivan Voras
• Weird index or sort behaviour
  • From: Matthew Wakeling
• Re: Getting time of a postgresql-request
  • From: Pierre Frédéric Caillaud
• Re: number of rows estimation for bit-AND operation
  • From: Scott Marlowe
• Re: Memory reporting on CentOS Linux
  • From: Greg Smith
• Re: Getting time of a postgresql-request
  • From: Russell Smith
• Re: Memory reporting on CentOS Linux
  • From: Scott Carey
• Re: Memory reporting on CentOS Linux
  • From: Scott Carey
• number of rows estimation for bit-AND operation
  • From: Slava Moudry
• Re: Memory reporting on CentOS Linux
  • From: Jeremy Carroll
• Getting time of a postgresql-request
  • From: Kai Behncke
• Re: Memory reporting on CentOS Linux
  • From: Matthew Wakeling
• Re: Scalability in postgres
  • From: Jeff Janes
• Re: Less expensive proprietary or Open source ETL tools
  • From: Jean-Max Reymond
• Re: Scalability in postgres
  • From: simon@xxxxxxxxxxxxxxx
• Re: Per-database warm standby?
  • From: Nickolay
• Re: Memory reporting on CentOS Linux
  • From: Robert Haas
• Re: Memory reporting on CentOS Linux
  • From: Mark Mielke
• Re: Memory reporting on CentOS Linux
  • From: Jeremy Carroll
• Re: Memory reporting on CentOS Linux
  • From: Tom Lane
• Re: Memory reporting on CentOS Linux
  • From: Jeremy Carroll
• Re: Scalability in postgres
  • From: Tom Lane
• Re: Scalability in postgres
  • From: Jeff Janes
• Re: Memory usage of writer process
  • From: Alex Neth
• Re: Per-database warm standby?
  • From: Alvaro Herrera
• Re: Per-database warm standby?
  • From: Tom Lane
• Per-database warm standby?
  • From: Craig James
• Re: Memory reporting on CentOS Linux
  • From: Scott Carey
• Re: Memory reporting on CentOS Linux
  • From: Scott Marlowe
• Re: Memory reporting on CentOS Linux
  • From: Scott Marlowe
• Re: Memory reporting on CentOS Linux
  • From: Jeremy Carroll
• Re: Memory reporting on CentOS Linux
  • From: Reid Thompson
• Memory reporting on CentOS Linux
  • From: Jeremy Carroll
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Robert Haas
• Re: Under the hood of views
  • From: Greg Stark
• Re: Under the hood of views
  • From: David Kerr
• Re: Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
  • From: Josh Berkus
• Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
  • From: Robert Haas
• Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age100m? )
  • From: Kevin Grittner
• Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
  • From: Alvaro Herrera
• Re: Memory usage of writer process
  • From: Scott Carey
• freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
  • From: Jeff Davis
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Josh Berkus
• Re: Memory usage of writer process
  • From: Alvaro Herrera
• Memory usage of writer process
  • From: Alex
• Less expensive proprietary or Open source ETL tools
  • From: Rstat
• Re: Under the hood of views
  • From: Richard Huxton
• Under the hood of views
  • From: David Kerr
• Re: How to run this in reasonable time:
  • From: Matthew Wakeling
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Kevin Grittner
• Re: How to run this in reasonable time:
  • From: Greg Stark
• How to run this in reasonable time:
  • From: Matthew Wakeling
• Re: transaction delays to apply
  • From: Nickolay
• Re: transaction delays to apply
  • From: Nickolay
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Torsten Zühlsdorff
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Robert Haas
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Tom Lane
• Re: transaction delays to apply
  • From: Tom Lane
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Kevin Grittner
• Re: transaction delays to apply
  • From: Pierre Frédéric Caillaud
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Tom Lane
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Kevin Grittner
• transaction delays to apply
  • From: Nickolay
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Robert Haas
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Tom Lane
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Josh Berkus
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Robert Haas
• Re: Why is vacuum_freeze_min_age 100m?
  • From: Josh Berkus
• Why is vacuum_freeze_min_age 100m?
  • From: Josh Berkus
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: Devin Ben-Hur
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: Robert Haas
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: Kevin Grittner
• Re: Bottleneck?
  • From: Robert Haas
• Re: Bottleneck?
  • From: Scott Marlowe
• Re: Bottleneck?
  • From: Ip Wing Kin John
• Re: ORDER BY ... LIMIT and JOIN
  • From: Robert Haas
• Re: ORDER BY ... LIMIT and JOIN
  • From: Michael Andreen
• Re: ORDER BY ... LIMIT and JOIN
  • From: Fizu
• Re: Need suggestions on kernel settings for dedicated FreeBSD/Postgresql machine
  • From: Culley Harrelson
• Re: Need suggestions on kernel settings for dedicated FreeBSD/Postgresql machine
  • From: Robert Haas
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Bruce Momjian
• 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: [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: [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: Tom Lane
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Alvaro Herrera
• Re: ORDER BY ... LIMIT and JOIN
  • From: Michael Andreen
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Tom Lane
• Re: PG-related ACM Article: "The Pathologies of Big Data"
  • From: Pierre Frédéric Caillaud
• ORDER BY ... LIMIT and JOIN
  • From: Fizu
• Re: [BUGS] BUG #4919: CREATE USER command slows down system performance
  • From: Bruce Momjian
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: Robert Haas
• Re: PG-related ACM Article: "The Pathologies of Big Data"
  • From: Scott Marlowe
• Re: PG-related ACM Article: "The Pathologies of Big Data"
  • From: Scott Carey
• Re: PG-related ACM Article: "The Pathologies of Big Data"
  • From: Scott Marlowe
• Re: PG-related ACM Article: "The Pathologies of Big Data"
  • From: Scott Marlowe
• Re: PG-related ACM Article: "The Pathologies of Big Data"
  • From: Greg Stark
• PG-related ACM Article: "The Pathologies of Big Data"
  • From: Josh Kupershmidt
• Need suggestions on kernel settings for dedicated FreeBSD/Postgresql machine
  • From: Culley Harrelson
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: Scott Carey
• Re: postgresql and syslog
  • From: Alvaro Herrera
• Re: postgresql and syslog
  • From: Michael Nacos
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: Robert Haas
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: Kees van Dieren
• Re: Best settings to load a fresh database
  • From: Euler Taveira de Oliveira
• Re: postgresql and syslog
  • From: Robert Haas
• Re: Best settings to load a fresh database
  • From: Kenneth Marshall
• Re: Best settings to load a fresh database
  • From: Scott Marlowe
• Best settings to load a fresh database
  • From: Campbell, Lance
• Re: Bottleneck?
  • From: Joshua D. Drake
• Re: Bottleneck?
  • From: Ray Stell
• Re: Bottleneck?
  • From: Joshua D. Drake
• Re: Bottleneck?
  • From: Kenneth Cox
• Re: Bottleneck?
  • From: Ray Stell
• Re: Bottleneck?
  • From: Tom Lane
• Re: Bottleneck?
  • From: Ray Stell
• Re: Bottleneck?
  • From: Scott Marlowe
• Re: Bottleneck?
  • From: Ip Wing Kin John
• Re: Bottleneck?
  • From: Scott Marlowe
• Re: Bottleneck?
  • From: wkipjohn
• Re: Bottleneck?
  • From: wkipjohn
• Re: Bottleneck?
  • From: Scott Marlowe
• Re: Bottleneck?
  • From: wkipjohn
• Re: Bottleneck?
  • From: Scott Marlowe
• Bottleneck?
  • From: Ip Wing Kin John
• Re: Query help
  • From: Kevin Grittner
• Re: Query help
  • From: Scott Carey
• Re: Query help
  • From: Subbiah Stalin-XCGF84
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Merlin Moncure
• Re: GiST, caching, and consistency
  • From: Tom Lane
• Re: GiST, caching, and consistency
  • From: Matthew Wakeling
• Re: GiST, caching, and consistency
  • From: Robert Haas
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: Russell Smith
• Re: GiST, caching, and consistency
  • From: Matthew Wakeling
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: Kees van Dieren
• CHECK constraint fails when it's not supposed to
  • From: richyen
• Re: CHECK constraint fails when it's not supposed to
  • From: Greg Stark
• Re: GiST, caching, and consistency
  • From: Greg Stark
• CHECK constraint fails when it's not supposed to
  • From: Richard Yen
• Re: GiST, caching, and consistency
  • From: Robert Haas
• postgresql and syslog
  • From: Ibrahim Harrani
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Tom Lane
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: Query help
  • From: Subbiah Stalin-XCGF84
• GiST, caching, and consistency
  • From: Matthew Wakeling
• Re: Query help
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Alvaro Herrera
• Re: select count(idn) is slow (Seq Scan) instead of Bitmap Heap.. why?
  • From: Robert Haas
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Merlin Moncure
• Re: Greenplum MapReduce
  • From: Suvankar Roy
• Re: Greenplum MapReduce
  • From: Suvankar Roy
• Re: PostgreSQL 8.4 performance tuning questions
  • From: PFC
• Re: Query help
  • From: Subbiah Stalin-XCGF84
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Merlin Moncure
• Re: Query help
  • From: Kevin Grittner
• Re: Query help
  • From: Subbiah Stalin-XCGF84
• Re: PostgreSQL 8.4 performance tuning questions
  • From: PFC
• Re: Query help
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Tom Lane
• Query help
  • From: Subbiah Stalin-XCGF84
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: Why is PostgreSQL so slow on Windows ( Postgres 8.3.7) version
  • From: Marc Cousin
• Re: Why is PostgreSQL so slow on Windows ( Postgres 8.3.7) version
  • From: Grzegorz Jaśkiewicz
• Re: Greenplum MapReduce
  • From: Richard Huxton
• Re: Greenplum MapReduce
  • From: Richard Huxton
• Re: FW: Performance 8.4.0
  • From: Robert Haas
• Re: Greenplum MapReduce
  • From: Chris
• FW: Performance 8.4.0
  • From: Chris Dunn
• Re: Why is PostgreSQL so slow on Windows ( Postgres 8.3.7) version
  • From: Euler Taveira de Oliveira
• Re: Why is PostgreSQL so slow on Windows ( Postgres 8.3.7) version
  • From: PFC
• Re: Performance Monitoring tool
  • From: Frits Hoogland
• Re: Performance 8.4.0
  • From: Stephen Frost
• Why is PostgreSQL so slow on Windows ( Postgres 8.3.7) version
  • From: pari krishnan
• Performance Monitoring tool
  • From: mukeshp
• SQL select query becomes slow when using limit (with no offset)
  • From: Kees van Dieren
• Why is PostgreSQL so slow on Windows ( Postgres 8.3.7) version
  • From: parimala
• Greenplum MapReduce
  • From: Suvankar Roy
• select count(idn) is slow (Seq Scan) instead of Bitmap Heap.. why?
  • From: Adam PAPAI
• Re: Performance 8.4.0
  • From: Robert Haas
• Re: load / stress testing
  • From: Dimitri Fontaine
• Re: PostgreSQL 8.4 performance tuning questions
  • From: PFC
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Tom Lane
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Merlin Moncure
• Re: load / stress testing
  • From: Jerry Champlin
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: PFC
• Re: SQL select query becomes slow when using limit (with no offset)
  • From: Greg Stark
• SQL select query becomes slow when using limit (with no offset)
  • From: Kees van Dieren
• load / stress testing
  • From: Chris
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Rauan Maemirov
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Stefan Kaltenbrunner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Marlowe
• Re: Performance 8.4.0
  • From: Greg Smith
• Performance 8.4.0
  • From: Chris Dunn
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Greg Smith
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Greg Stark
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Tom Lane
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Rauan Maemirov
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Tom Lane
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Tom Lane
• Re: autovacuum 'stuck' ?
  • From: Robert Haas
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Tom Lane
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Arjen van der Meijden
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Scott Carey
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Stefan Kaltenbrunner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Stefan Kaltenbrunner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Tom Lane
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Matthew Wakeling
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Steve Crawford
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Kevin Grittner
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Steve Crawford
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Rauan Maemirov
• Re: PostgreSQL 8.4 performance tuning questions
  • From: Rauan Maemirov
• Re: PostgreSQL 8.4 performance tuning questions
  • From: tv
• Re: PostgreSQL 8.4 performance tuning questions
  • From: tv
• PostgreSQL 8.4 performance tuning questions
  • From: Rauan Maemirov
• autovacuum 'stuck' ?
  • From: Doug Hunley
• Re: Full text search with ORDER BY performance issue
  • From: Robert Haas
• Re: Full text search with ORDER BY performance issue
  • From: Tom Lane
• Re: Full text search with ORDER BY performance issue
  • From: Robert Haas
• Re: Full text search with ORDER BY performance issue
  • From: PFC
• Re: Full text search with ORDER BY performance issue
  • From: Tom Lane
• Re: Full text search with ORDER BY performance issue
  • From: Robert Haas
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Merlin Moncure
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Matthew Wakeling
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Matthew Wakeling
• Re: select query performance question
  • From: Thomas Zaksek
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Greg Smith
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Stefan Kaltenbrunner
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Greg Smith
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Stefan Kaltenbrunner
• Re: really stupid question about checkpointing
  • From: Greg Smith
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Jon Nelson
• really stupid question about checkpointing
  • From: Doug Hunley
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Scott Marlowe
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Greg Smith
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Scott Carey
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Scott Carey
• Re: Will Postgres ever lock with read only queries?
  • From: Chris
• Re: hyperthreaded cpu still an issue in 8.4?
  • From: Scott Marlowe
• 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