Postgres Performance Date Index

• Thread Index

• Re: Hyperthreading (was: Two identical systems, radically different performance)
  • From: Jeff Janes
• Re: Hyperthreading (was: Two identical systems, radically different performance)
  • From: Josh Berkus
• Re: Hyperthreading (was: Two identical systems, radically different performance)
  • From: Tom Lane
• Hyperthreading (was: Two identical systems, radically different performance)
  • From: Craig James
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Two identical systems, radically different performance
  • From: David Thomas
• Re: Two identical systems, radically different performance
  • From: Shaun Thomas
• Re: Two identical systems, radically different performance
  • From: Yeb Havinga
• Re: Two identical systems, radically different performance
  • From: Tomas Vondra
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Two identical systems, radically different performance
  • From: Evgeny Shishkin
• Re: Two identical systems, radically different performance
  • From: Tomas Vondra
• Re: Two identical systems, radically different performance
  • From: Claudio Freire
• Re: Two identical systems, radically different performance
  • From: Mark Kirkwood
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Scaling 10 million records in PostgreSQL table
  • From: Samuel Gendler
• Re: Two identical systems, radically different performance
  • From: Claudio Freire
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Two identical systems, radically different performance
  • From: Evgeny Shishkin
• Re: Two identical systems, radically different performance
  • From: Claudio Freire
• Re: Two identical systems, radically different performance
  • From: Evgeny Shishkin
• Re: Two identical systems, radically different performance
  • From: Evgeny Shishkin
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Two identical systems, radically different performance
  • From: Steve Crawford
• Re: Two identical systems, radically different performance
  • From: Imre Samu
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Two identical systems, radically different performance
  • From: Evgeny Shishkin
• Re: Two identical systems, radically different performance
  • From: Claudio Freire
• Two identical systems, radically different performance
  • From: Craig James
• Re: Scaling 10 million records in PostgreSQL table
  • From: Craig Ringer
• Re: Scaling 10 million records in PostgreSQL table
  • From: Julien Cigar
• Re: Scaling 10 million records in PostgreSQL table
  • From: Steve Crawford
• Re: Scaling 10 million records in PostgreSQL table
  • From: Larry Rosenman
• Re: Scaling 10 million records in PostgreSQL table
  • From: Merlin Moncure
• Scaling 10 million records in PostgreSQL table
  • From: Navaneethan R
• Re: Strange behavior after upgrade from 9.0 to 9.2
  • From: Andrzej Zawadzki
• Re: Strange behavior after upgrade from 9.0 to 9.2
  • From: Tom Lane
• Re: Strange behavior after upgrade from 9.0 to 9.2
  • From: Andrzej Zawadzki
• Re: Strange behavior after upgrade from 9.0 to 9.2
  • From: Tom Lane
• Re: Guide to Posting Slow Query Questions
  • From: Ants Aasma
• Re: [repost] Help me develop new commit_delay advice
  • From: Peter Geoghegan
• Re: Same query doing slow then quick
  • From: Ants Aasma
• Re: UPDATE execution time is increasing
  • From: Valentine Gogichashvili
• UPDATE execution time is increasing
  • From: virag
• Re: Strange behavior after upgrade from 9.0 to 9.2
  • From: Andrzej Zawadzki
• Re: Strange behavior after upgrade from 9.0 to 9.2
  • From: Craig Ringer
• Re: Same query doing slow then quick
  • From: Undertaker Rude
• Strange behavior after upgrade from 9.0 to 9.2
  • From: Andrzej Zawadzki
• hash aggregation speedup
  • From: Korisk
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Anibal David Acosta
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Andres Freund
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Tom Lane
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Claudio Freire
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Merlin Moncure
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Tom Lane
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Andres Freund
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Tom Lane
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Maciek Sakrejda
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Claudio Freire
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Igor Neyman
• Re: A Tale of 2 algorithms
  • From: Colin Taylor
• Re: how to avoid deadlock on masive update with multiples delete
  • From: Jeff Janes
• how to avoid deadlock on masive update with multiples delete
  • From: Anibal David Acosta
• Re: Inserts in 'big' table slowing down the database
  • From: Jeff Janes
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kiriakos Tsourapas
• Re: hardware advice
  • From: Glyn Astill
• Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
  • From: Andrea Suisani
• Re: suboptimal query plan
  • From: Nick Hofstede
• Re: suboptimal query plan
  • From: Tom Lane
• suboptimal query plan
  • From: Nick Hofstede
• Re: hardware advice - opinions about HP?
  • From: Scott Marlowe
• Re: hardware advice - opinions about HP?
  • From: Bruce Momjian
• Re: hardware advice
  • From: David Boreham
• Re: Inserts in 'big' table slowing down the database
  • From: Shaun Thomas
• Re: hardware advice - opinions about HP?
  • From: Franklin, Dan (FEN)
• Re: deadlock_timeout affect on performance
  • From: Heikki Linnakangas
• Re: hardware advice
  • From: Glyn Astill
• deadlock_timeout affect on performance
  • From: pg noob
• Re: Spurious failure to obtain row lock possible in PG 9.1?
  • From: henk de wit
• Re: A Tale of 2 algorithms
  • From: Craig Ringer
• Re: Inserts in 'big' table slowing down the database
  • From: Greg Williamson
• Re: Inserts in 'big' table slowing down the database
  • From: Stefan Keller
• Re: NestedLoops over BitmapScan question
  • From: Виктор Егоров
• A Tale of 2 algorithms
  • From: Colin Taylor
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Igor Neyman
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Scott Marlowe
• wrong join result set estimate
  • From: Evgeny Shishkin
• Re: [GENERAL] Inaccurate Explain Cost
  • From: Matthias
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Thomas Kellerer
• Re: hardware advice
  • From: Scott Marlowe
• NestedLoops over BitmapScan question
  • From: Виктор Егоров
• Re: Query plan, nested EXISTS
  • From: Matt Daw
• Re: Possible Performance Regression with Transitive Comparisons vs. Constants
  • From: Tom Lane
• Re: Query plan, nested EXISTS
  • From: Matt Daw
• Re: Query plan, nested EXISTS
  • From: Tom Lane
• Re: Possible Performance Regression with Transitive Comparisons vs. Constants
  • From: Shaun Thomas
• Query plan, nested EXISTS
  • From: Matt Daw
• Re: Possible Performance Regression with Transitive Comparisons vs. Constants
  • From: Tom Lane
• Possible Performance Regression with Transitive Comparisons vs. Constants
  • From: Shaun Thomas
• Re: hardware advice
  • From: M. D.
• Re: hardware advice
  • From: David Boreham
• Re: hardware advice
  • From: Craig James
• Re: hardware advice
  • From: ktm@xxxxxxxx
• Re: "Select * " on 12-18M row table from remote machine thru JDBC - Performance nose-dives after 10M-ish records
  • From: Deron
• "Select * " on 12-18M row table from remote machine thru JDBC - Performance nose-dives after 10M-ish records
  • From: antthelimey
• Re: [PERFORM] Re: [PERFORM] exponentia​l performanc​e decrease, problem with version postgres + RHEL?
  • From: John Nash
• RE: [PERFORM] exponentia​l performanc​e decrease, problem with version postgres + RHEL?
  • From: Albe Laurenz
• Re: [PERFORM] exponentia​l performanc​e decrease, problem with version postgres + RHEL?
  • From: Nikolay Ulyanitsky
• exponentia​l performanc​e decrease, problem with version postgres + RHEL?
  • From: John Nash
• Re: hardware advice
  • From: Jeremy Harris
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kiriakos Tsourapas
• Re: hardware advice
  • From: Scott Marlowe
• Re: hardware advice
  • From: Scott Marlowe
• Re: hardware advice
  • From: Scott Marlowe
• Re: hardware advice
  • From: David Boreham
• Re: hardware advice
  • From: Evgeny Shishkin
• Re: hardware advice
  • From: Shaun Thomas
• Re: hardware advice
  • From: Evgeny Shishkin
• Re: hardware advice
  • From: Scott Marlowe
• Re: hardware advice
  • From: Scott Marlowe
• Re: hardware advice
  • From: Scott Marlowe
• Re: hardware advice
  • From: M. D.
• Re: hardware advice
  • From: Evgeny Shishkin
• Re: hardware advice
  • From: Shaun Thomas
• Re: hardware advice
  • From: Alan Hodgson
• Re: hardware advice
  • From: Claudio Freire
• Re: hardware advice
  • From: David Boreham
• Re: hardware advice
  • From: David Boreham
• Re: hardware advice
  • From: M. D.
• Re: hardware advice
  • From: Shaun Thomas
• Re: hardware advice
  • From: Scott Marlowe
• Re: hardware advice
  • From: Scott Marlowe
• Re: hardware advice
  • From: Shaun Thomas
• Re: hardware advice
  • From: Shaun Thomas
• Re: hardware advice
  • From: Scott Marlowe
• Re: hardware advice
  • From: Alan Hodgson
• Re: hardware advice
  • From: David Boreham
• Re: hardware advice
  • From: M. D.
• Re: hardware advice
  • From: David Boreham
• Re: hardware advice
  • From: David Boreham
• Re: hardware advice
  • From: M. D.
• Re: hardware advice
  • From: Craig James
• Re: hardware advice
  • From: Claudio Freire
• hardware advice
  • From: M. D.
• Re: Same query doing slow then quick
  • From: Undertaker Rude
• Re: Same query doing slow then quick
  • From: Undertaker Rude
• Re: [GENERAL] Inaccurate Explain Cost
  • From: Jeff Janes
• Re: Inaccurate Explain Cost
  • From: Samuel Gendler
• Re: [GENERAL] Memory issues
  • From: Shiran Kleiderman
• Re: [GENERAL] Memory issues
  • From: Shiran Kleiderman
• Re: [GENERAL] Memory issues
  • From: Scott Marlowe
• Re: [GENERAL] Memory issues
  • From: Scott Marlowe
• Re: [GENERAL] Memory issues
  • From: Shiran Kleiderman
• Re: Inaccurate Explain Cost
  • From: hubert depesz lubaczewski
• Re: Inaccurate Explain Cost
  • From: Shaun Thomas
• Re: Guide to Posting Slow Query Questions
  • From: Jeff Janes
• Inaccurate Explain Cost
  • From: Robert Sosinski
• Re: Same query doing slow then quick
  • From: Nikolay Ulyanitsky
• Re: Same query doing slow then quick
  • From: FFW_Rude
• Re: Same query doing slow then quick
  • From: Undertaker Rude
• Re: Same query doing slow then quick
  • From: Nikolay Ulyanitsky
• Re: Same query doing slow then quick
  • From: FFW_Rude
• Re: Same query doing slow then quick
  • From: Nikolay Ulyanitsky
• Re: Same query doing slow then quick
  • From: FFW_Rude
• Re: Same query doing slow then quick
  • From: Julien Cigar
• Re: Same query doing slow then quick
  • From: FFW_Rude
• Re: Same query doing slow then quick
  • From: FFW_Rude
• Re: Same query doing slow then quick
  • From: Julien Cigar
• Re: Same query doing slow then quick
  • From: FFW_Rude
• Re: Same query doing slow then quick
  • From: Julien Cigar
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kiriakos Tsourapas
• Re: Same query doing slow then quick
  • From: FFW_Rude
• Re: Same query doing slow then quick
  • From: Julien Cigar
• Re: Same query doing slow then quick
  • From: FFW_Rude
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kevin Grittner
• Same query doing slow then quick
  • From: FFW_Rude
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kiriakos Tsourapas
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Ondrej Ivanič
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kevin Grittner
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kiriakos Tsourapas
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kiriakos Tsourapas
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kiriakos Tsourapas
• Re: Spurious failure to obtain row lock possible in PG 9.1?
  • From: Albe Laurenz
• Spurious failure to obtain row lock possible in PG 9.1?
  • From: henk de wit
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Mark Kirkwood
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Ondrej Ivanič
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: MirrorX
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kiriakos Tsourapas
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Julien Cigar
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Andres Freund
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Julien Cigar
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Andres Freund
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Julien Cigar
• Re: Postgres becoming slow, only full vacuum fixes it
  • From: Kiriakos Tsourapas
• Postgres becoming slow, only full vacuum fixes it
  • From: Kiriakos Tsourapas
• Re: Cost of opening and closing an empty transaction
  • From: Albe Laurenz
• Memory issues
  • From: Shiran Kleiderman
• Re: Newbie performance problem - semop taking most of time ?
  • From: Tom Lane
• Re: Newbie performance problem - semop taking most of time ?
  • From: mal.oracledba
• Re: wal_sync_method on FreeBSD 9.0 - ZFS
  • From: Sébastien Lorion
• Re: Newbie performance problem - semop taking most of time ?
  • From: Daniel Farina
• Re: Cost of opening and closing an empty transaction
  • From: Claudio Freire
• Re: wal_sync_method on FreeBSD 9.0 - ZFS
  • From: Ivan Voras
• PostgreSQL performance on 64 bit as compared to 32 bit
  • From: Umesh Kirdat
• Re: PostgreSQL performance on 64 bit as compared to 32 bit
  • From: Claudio Freire
• Cost of opening and closing an empty transaction
  • From: Jon Leighton
• Newbie performance problem - semop taking most of time ?
  • From: mal.oracledba
• Query Planner Optimization?
  • From: Brandon
• Re: problems with large objects dump
  • From: Tom Lane
• Re: problems with large objects dump
  • From: Sergio Gabriel Rodriguez
• Re: problems with large objects dump
  • From: Tom Lane
• problems with large objects dump
  • From: Sergio Gabriel Rodriguez
• Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
  • From: Andrea Suisani
• Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
  • From: Merlin Moncure
• Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
  • From: Andrea Suisani
• Re: Planner selects different execution plans depending on limit
  • From: Bill Martin
• Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
  • From: McKinzie, Alan (Alan)
• Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
  • From: Craig Ringer
• Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
  • From: Tom Lane
• Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
  • From: Craig Ringer
• Re: Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
  • From: Craig Ringer
• Re: Remote access to Postgresql slow
  • From: Scott Marlowe
• Re: Remote access to Postgresql slow
  • From: Andrew Barnham
• Remote access to Postgresql slow
  • From: Manoj Agarwal
• Re: Setting autovacuum_vacuum_scale_factor to 0 a good idea ?
  • From: Sébastien Lorion
• Re: Setting autovacuum_vacuum_scale_factor to 0 a good idea ?
  • From: Josh Berkus
• Setting autovacuum_vacuum_scale_factor to 0 a good idea ?
  • From: Sébastien Lorion
• wal_sync_method on FreeBSD 9.0 - ZFS
  • From: Sébastien Lorion
• Are there known performance issues with defining all Foreign Keys as deferrable initially immediate
  • From: McKinzie, Alan (Alan)
• Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
  • From: Nikolay Ulyanitsky
• Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
  • From: Craig James
• Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
  • From: Nikolay Ulyanitsky
• Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
  • From: Marcos Ortiz
• Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
  • From: Daniel Farina
• Re: Guide to Posting Slow Query Questions
  • From: Ants Aasma
• 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets
  • From: Nikolay Ulyanitsky
• Re: AppScale backend datastore (NoSQL again kind of)
  • From: Mark Kirkwood
• Re: Linux machine aggressively clearing cache
  • From: Ross Reedstrom
• Re: AppScale backend datastore (NoSQL again kind of)
  • From: Marcos Ortiz
• AppScale backend datastore (NoSQL again kind of)
  • From: Ross Reedstrom
• Re: Planner selects different execution plans depending on limit
  • From: Tom Lane
• Re: Planner selects different execution plans depending on limit
  • From: Bill Martin
• Re: Planner selects different execution plans depending on limit
  • From: Tom Lane
• Re: Planner selects different execution plans depending on limit
  • From: Jesper Krogh
• Re: Planner selects different execution plans depending on limit
  • From: Bill Martin
• Re: Planner selects different execution plans depending on limit
  • From: Tom Lane
• Re: : PostgreSQL Index behavior
  • From: Tomas Vondra
• Re: : PostgreSQL Index behavior
  • From: Venkat Balaji
• Re: Planner selects different execution plans depending on limit
  • From: Bill Martin
• Guide to Posting Slow Query Questions
  • From: Jeff Janes
• Re: : PostgreSQL Index behavior
  • From: Scott Marlowe
• Re: : PostgreSQL Index behavior
  • From: Venkat Balaji
• Re: Planner selects different execution plans depending on limit
  • From: Tom Lane
• Re: add column with default value is very slow
  • From: hubert depesz lubaczewski
• Re: add column with default value is very slow
  • From: Andrew Dunstan
• Re: add column with default value is very slow
  • From: AI Rumman
• Re: add column with default value is very slow
  • From: hubert depesz lubaczewski
• Re: add column with default value is very slow
  • From: AI Rumman
• Re: add column with default value is very slow
  • From: hubert depesz lubaczewski
• Re: add column with default value is very slow
  • From: Albe Laurenz
• add column with default value is very slow
  • From: AI Rumman
• Re: Planner selects different execution plans depending on limit
  • From: Bill Martin
• Re: Slow Performance on a XEON E5504
  • From: Marcos Ortiz
• Re: Planner selects different execution plans depending on limit
  • From: Jesper Krogh
• Re: : PostgreSQL Index behavior
  • From: Jeff Janes
• force defaults
  • From: Willy-Bas Loos
• Planner selects different execution plans depending on limit
  • From: bill_martin
• : PostgreSQL Index behavior
  • From: Venkat Balaji
• Re: libpq or postgresql performance
  • From: Ireneusz Pluta
• Re: libpq or postgresql performance
  • From: Ireneusz Pluta
• Re: exponential performance decrease in ISD transaction
  • From: John Nash
• Re: exponential performance decrease in ISD transaction
  • From: John Nash
• Re: libpq or postgresql performance
  • From: Ireneusz Pluta
• Re: libpq or postgresql performance
  • From: Albe Laurenz
• Re: HELP!!!-----Need to Sql commands to monitoring Postgresql
  • From: Daniel Farina
• Re: libpq or postgresql performance
  • From: Andreas Kretschmer
• libpq or postgresql performance
  • From: Aryan Ariel Rodriguez Chalas
• Re: HELP!!!-----Need to Sql commands to monitoring Postgresql
  • From: charles_xie
• Re: HELP!!!-----Need to Sql commands to monitoring Postgresql
  • From: Steven Crandell
• Re: HELP!!!-----Need to Sql commands to monitoring Postgresql
  • From: Josh Berkus
• Re: HELP!!!-----Need to Sql commands to monitoring Postgresql
  • From: Daniel Farina
• Re: JDBC 5 million function insert returning Single Transaction Lock Access Exclusive Problem
  • From: Eileen
• HELP!!!-----Need to Sql commands to monitoring Postgresql
  • From: charles_xie
• Re: exponential performance decrease in ISD transaction
  • From: Greg Smith
• Re: [repost] Help me develop new commit_delay advice
  • From: Greg Smith
• Re: query performance, where goes time?
  • From: Craig Ringer
• query performance, where goes time?
  • From: Anibal David Acosta
• Re: exponential performance decrease in ISD transaction
  • From: Jeff Janes
• Re: exponential performance decrease in ISD transaction
  • From: John Nash
• Re: Inserts in 'big' table slowing down the database
  • From: Ivan Voras
• Inserts in 'big' table slowing down the database
  • From: Stefan Keller
• Re: Execution from java - slow
  • From: Jayadevan M
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Robert Haas
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Jeff Janes
• Re: Bad query plan when the wrong data type is used
  • From: Bruce Momjian
• Re: NOTIFY performance
  • From: Jeff Janes
• Re: JDBC 5 million function insert returning Single Transaction Lock Access Exclusive Problem
  • From: Craig Ringer
• Re: NOTIFY performance
  • From: Tom Lane
• Re: NOTIFY performance
  • From: Jeff Janes
• Re: exponential performance decrease in ISD transaction
  • From: Jeff Janes
• Re: JDBC 5 million function insert returning Single Transaction Lock Access Exclusive Problem
  • From: Scott Marlowe
• Re: JDBC 5 million function insert returning Single Transaction Lock Access Exclusive Problem
  • From: Albe Laurenz
• Re: JDBC 5 million function insert returning Single Transaction Lock Access Exclusive Problem
  • From: Dave Cramer
• Re: exponential performance decrease in ISD transaction
  • From: Heikki Linnakangas
• JDBC 5 million function insert returning Single Transaction Lock Access Exclusive Problem
  • From: Eileen
• exponential performance decrease in ISD transaction
  • From: John Nash
• Re: Question about caching on full table scans
  • From: Markus Innerebner
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Tom Lane
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Robert Haas
• Re: pg_dump and thousands of schemas
  • From: Bruce Momjian
• Re: pg_dump and thousands of schemas
  • From: Tom Lane
• Re: pg_dump and thousands of schemas
  • From: Bruce Momjian
• Re: Question about caching on full table scans
  • From: Scott Marlowe
• Re: Question about caching on full table scans
  • From: Jeff Janes
• Re: Question about caching on full table scans
  • From: Markus Innerebner
• Re: Question about caching on full table scans
  • From: Albe Laurenz
• Re: Investigating the reason for a very big TOAST table size
  • From: Daniel Farina
• Re: Investigating the reason for a very big TOAST table size
  • From: Liron Shiri
• Re: Investigating the reason for a very big TOAST table size
  • From: Daniel Farina
• Question about caching on full table scans
  • From: Markus Innerebner
• Re: NOTIFY performance
  • From: Merlin Moncure
• Re: Execution from java - slow
  • From: Merlin Moncure
• Re: pg_trgm and slow bitmap index scan plan
  • From: Merlin Moncure
• Re: Investigating the reason for a very big TOAST table size
  • From: Daniel Farina
• Re: Investigating the reason for a very big TOAST table size
  • From: Daniel Farina
• pg_trgm and slow bitmap index scan plan
  • From: Mathieu De Zutter
• Re: Execution from java - slow
  • From: Pavan Deolasee
• Re: Vacuum problems with 9.1
  • From: Craig Ringer
• Re: Vacuum problems with 9.1
  • From: Pavan Deolasee
• Re: Investigating the reason for a very big TOAST table size
  • From: Liron Shiri
• Vacuum problems with 9.1
  • From: Nimesh Satam
• Re: Investigating the reason for a very big TOAST table size
  • From: Daniel Farina
• Re: Execution from java - slow
  • From: Albe Laurenz
• Execution from java - slow
  • From: Jayadevan M
• Slow Performance on a XEON E5504
  • From: Felix Schubert
• Investigating the reason for a very big TOAST table size
  • From: Liron Shiri
• Investigating the reason for a very big TOAST table size
  • From: Liron Shiri
• Re: Slow Performance on a XEON E5504
  • From: Scott Marlowe
• Re: Slow Performance on a XEON E5504
  • From: Felix Schubert
• Re: Loose Index Scans by Planner?
  • From: Shaun Thomas
• Re: Slow Performance on a XEON E5504
  • From: Scott Marlowe
• Re: Slow Performance on a XEON E5504
  • From: Scott Marlowe
• Re: Slow Performance on a XEON E5504
  • From: Felix Schubert
• Re: Slow Performance on a XEON E5504
  • From: Scott Marlowe
• Slow Performance on a XEON E5504
  • From: Felix Schubert
• Re: Loose Index Scans by Planner?
  • From: Jeff Janes
• Re: Loose Index Scans by Planner?
  • From: Shaun Thomas
• Re: NOTIFY performance
  • From: Artur Zając
• Re: Loose Index Scans by Planner?
  • From: Kevin Grittner
• Re: NOTIFY performance
  • From: Merlin Moncure
• NOTIFY performance
  • From: Artur Zając
• Loose Index Scans by Planner?
  • From: Shaun Thomas
• Re: Increasing WAL usage followed by sudden drop
  • From: delongboy
• Re: Performance of Seq Scan from buffer cache
  • From: Merlin Moncure
• Re: Increasing WAL usage followed by sudden drop
  • From: Jeff Janes
• Re: average query performance measuring
  • From: Rick Otten
• Re: Performance of Seq Scan from buffer cache
  • From: Matt Daw
• Performance of Seq Scan from buffer cache
  • From: Matt Daw
• Re: average query performance measuring
  • From: Peter Geoghegan
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Scott Marlowe
• Re: average query performance measuring
  • From: Tomas Vondra
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Craig James
• Re: average query performance measuring
  • From: Stephen Frost
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Scott Marlowe
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Scott Marlowe
• Re: average query performance measuring
  • From: Karl Denninger
• Re: average query performance measuring
  • From: Stephen Frost
• average query performance measuring
  • From: Rick Otten
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Merlin Moncure
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Craig James
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Craig James
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Merlin Moncure
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Scott Marlowe
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Scott Marlowe
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Scott Marlowe
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Scott Marlowe
• Re: Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Tom Lane
• Does setval(nextval()+N) generate unique blocks of IDs?
  • From: Craig James
• Re: Increasing WAL usage followed by sudden drop
  • From: delongboy
• Re: 7k records into Sort node, 4.5m out?
  • From: Josh Berkus
• Re: 7k records into Sort node, 4.5m out?
  • From: Tom Lane
• Re: 7k records into Sort node, 4.5m out?
  • From: Josh Berkus
• Re: Index Bloat Problem
  • From: Greg Williamson
• Re: Index Bloat Problem
  • From: Jeff Janes
• Re: Increasing WAL usage followed by sudden drop
  • From: Jeff Janes
• Re: Increasing WAL usage followed by sudden drop
  • From: delongboy
• Re: Increasing WAL usage followed by sudden drop
  • From: Joshua Berkus
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Jim Vanns
• Re: High Disk write and space taken by PostgreSQL
  • From: Merlin Moncure
• Re: best practice to avoid table bloat?
  • From: Kevin Grittner
• Re: best practice to avoid table bloat?
  • From: Anibal David Acosta
• Re: best practice to avoid table bloat?
  • From: Kevin Grittner
• Re: best practice to avoid table bloat?
  • From: Andrew Dunstan
• best practice to avoid table bloat?
  • From: Anibal David Acosta
• Re: Index Bloat Problem
  • From: Strahinja Kustudić
• Re: cluster on conditional index?
  • From: Jeff Janes
• Re: High Disk write and space taken by PostgreSQL
  • From: anarazel@xxxxxxxxxxx
• Re: Increasing WAL usage followed by sudden drop
  • From: Kevin Grittner
• Re: Increasing WAL usage followed by sudden drop
  • From: delongboy
• Re: High Disk write and space taken by PostgreSQL
  • From: Bruce Momjian
• Re: cluster on conditional index?
  • From: Jeff Janes
• Re: High Disk write and space taken by PostgreSQL
  • From: Scott Marlowe
• Re: cluster on conditional index?
  • From: Doug Hunley
• Re: High Disk write and space taken by PostgreSQL
  • From: Bruce Momjian
• Re: High Disk write and space taken by PostgreSQL
  • From: Bruce Momjian
• Re: 7k records into Sort node, 4.5m out?
  • From: Tom Lane
• Re: High Disk write and space taken by PostgreSQL
  • From: Claudio Freire
• Re: High Disk write and space taken by PostgreSQL
  • From: Ondrej Ivanič
• Re: High Disk write and space taken by PostgreSQL
  • From: J Ramesh Kumar
• Re: High Disk write and space taken by PostgreSQL
  • From: Claudio Freire
• Re: High Disk write and space taken by PostgreSQL
  • From: Scott Marlowe
• Re: High Disk write and space taken by PostgreSQL
  • From: J Ramesh Kumar
• Re: High Disk write and space taken by PostgreSQL
  • From: David Barton
• High Disk write and space taken by PostgreSQL
  • From: J Ramesh Kumar
• Re: 7k records into Sort node, 4.5m out?
  • From: Josh Berkus
• Re: 7k records into Sort node, 4.5m out?
  • From: Tom Lane
• Re: 7k records into Sort node, 4.5m out?
  • From: Tom Lane
• Re: cluster on conditional index?
  • From: Bosco Rama
• Re: cluster on conditional index?
  • From: Josh Berkus
• Re: 7k records into Sort node, 4.5m out?
  • From: Josh Berkus
• Re: 7k records into Sort node, 4.5m out?
  • From: Christophe Pettus
• Re: cluster on conditional index?
  • From: Doug Hunley
• Re: cluster on conditional index?
  • From: ktm@xxxxxxxx
• Re: cluster on conditional index?
  • From: Jeff Janes
• cluster on conditional index?
  • From: Doug Hunley
• Re: Index Bloat Problem
  • From: Jeff Janes
• Re: 7k records into Sort node, 4.5m out?
  • From: Tom Lane
• Re: 7k records into Sort node, 4.5m out?
  • From: Christophe Pettus
• Re: 7k records into Sort node, 4.5m out?
  • From: Tomas Vondra
• 7k records into Sort node, 4.5m out?
  • From: Christophe Pettus
• Re: Increasing WAL usage followed by sudden drop
  • From: Josh Berkus
• Re: Index Bloat Problem
  • From: Mark Kirkwood
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: Jeff Janes
• Re: Deferred constraints performance impact ?
  • From: Robert Klemme
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: David Barton
• Re: Deferred constraints performance impact ?
  • From: Jeff Davis
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: Jeff Janes
• Improve DB Size / Performance with Table Refactoring
  • From: Anthony Presley
• Re: Is drop/restore trigger transactional?
  • From: Matheus de Oliveira
• Increasing WAL usage followed by sudden drop
  • From: Joseph Marlin
• Re: Index Bloat Problem
  • From: hubert depesz lubaczewski
• Index Bloat Problem
  • From: Strahinja Kustudić
• Re: query overhead
  • From: Jeff Janes
• Re: DELETE vs TRUNCATE explanation
  • From: Jeff Janes
• Re: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m
  • From: Jeff Janes
• Re: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m
  • From: Stefan Keller
• Re: Postgresql - performance of using array in big database
  • From: Ondrej Ivanič
• Re: Postgres Upgrade from 8.4 to 9.1
  • From: Craig Ringer
• Re: Postgresql - performance of using array in big database
  • From: Craig Ringer
• Postgres Upgrade from 8.4 to 9.1
  • From: Rajiv Kasera
• Postgresql - performance of using array in big database
  • From: roberthanco
• Re: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m
  • From: Jeff Janes
• Re: Is drop/restore trigger transactional?
  • From: Merlin Moncure
• Re: Is drop/restore trigger transactional?
  • From: Craig Ringer
• Re: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m
  • From: Stefan Keller
• Re: Is drop/restore trigger transactional?
  • From: Craig James
• Re: Is drop/restore trigger transactional?
  • From: Jeff Janes
• Re: Is drop/restore trigger transactional?
  • From: Merlin Moncure
• Re: Is drop/restore trigger transactional?
  • From: Samuel Gendler
• Re: Is drop/restore trigger transactional?
  • From: Craig James
• Re: Is drop/restore trigger transactional?
  • From: Merlin Moncure
• Re: Is drop/restore trigger transactional?
  • From: Jeff Janes
• Re: Is drop/restore trigger transactional?
  • From: Scott Marlowe
• Re: Is drop/restore trigger transactional?
  • From: Merlin Moncure
• Is drop/restore trigger transactional?
  • From: Craig James
• Re: Sequential scan instead of index scan
  • From: Jeff Janes
• Re: Sequential scan instead of index scan
  • From: Ioannis Anagnostopoulos
• Re: Sequential scan instead of index scan
  • From: Jeff Janes
• Re: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m
  • From: Craig James
• Re: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m
  • From: Tomas Vondra
• Re: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m
  • From: Stefan Keller
• Re: Sequential scan instead of index scan
  • From: Ioannis Anagnostopoulos
• Re: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m
  • From: Tomas Vondra
• Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m
  • From: Stefan Keller
• Re: Sequential scan instead of index scan
  • From: Tom Lane
• Re: Sequential scan instead of index scan
  • From: Ioannis Anagnostopoulos
• Re: slow query, different plans
  • From: Midge Brown
• Re: slow query, different plans
  • From: Midge Brown
• Re: Sequential scan instead of index scan
  • From: Tom Lane
• Re: Sequential scan instead of index scan
  • From: Ioannis Anagnostopoulos
• Re: Sequential scan instead of index scan
  • From: David Barton
• Sequential scan instead of index scan
  • From: Ioannis Anagnostopoulos
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: Pavel Stehule
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: Magnus Hagander
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: Pavel Stehule
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: Magnus Hagander
• Re: slow query, different plans
  • From: Tom Lane
• Re: slow query, different plans
  • From: Greg Williamson
• slow query, different plans
  • From: Midge Brown
• Re: Linux memory zone reclaim
  • From: Josh Berkus
• Re: Linux memory zone reclaim
  • From: Scott Marlowe
• Re: Linux memory zone reclaim
  • From: Josh Berkus
• Re: [ADMIN] Messed up time zones
  • From: Laszlo Nagy
• Re: [ADMIN] Messed up time zones
  • From: Steve Crawford
• Re: [ADMIN] Messed up time zones
  • From: Laszlo Nagy
• Re: query using incorrect index
  • From: Russell Keane
• Re: query using incorrect index
  • From: Kevin Grittner
• Re: query using incorrect index
  • From: Russell Keane
• Re: query using incorrect index
  • From: Russell Keane
• Re: query using incorrect index
  • From: Robert Klemme
• Re: query using incorrect index
  • From: Kevin Grittner
• [repost] Help me develop new commit_delay advice
  • From: Peter Geoghegan
• query using incorrect index
  • From: Russell Keane
• Re: Using ctid column changes plan drastically
  • From: Kevin Grittner
• Re: pg_dump and thousands of schemas
  • From: Hugo <Nabble>
• Re: ZFS vs. UFS
  • From: Craig James
• Re: ZFS vs. UFS
  • From: Laszlo Nagy
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: Mark Kirkwood
• Re: Linux memory zone reclaim
  • From: Bruce Momjian
• Re: Linux memory zone reclaim
  • From: Scott Marlowe
• Re: Linux memory zone reclaim
  • From: Kevin Grittner
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: David Barton
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: David Barton
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: Tom Lane
• Re: Postgres 9.1.4 - high stats collector IO usage
  • From: Pavel Stehule
• Postgres 9.1.4 - high stats collector IO usage
  • From: David Barton
• Re: pgstat wait timeout
  • From: Anibal David Acosta
• pgstat wait timeout
  • From: Anibal David Acosta
• Re: ZFS vs. UFS
  • From: Greg Smith
• Re: Linux memory zone reclaim
  • From: Bruce Momjian
• Re: planner, *_collapse_limit
  • From: Merlin Moncure
• planner, *_collapse_limit
  • From: Marcus Engene
• Re: Geoserver-PostGIS performance problems
  • From: Merlin Moncure
• Re: Geoserver-PostGIS performance problems
  • From: Maciek Sakrejda
• Re: Geoserver-PostGIS performance problems
  • From: Maciek Sakrejda
• Re: Geoserver-PostGIS performance problems
  • From: Rural Hunter
• Re: Geoserver-PostGIS performance problems
  • From: Vinicius Abrahao
• Re: Geoserver-PostGIS performance problems
  • From: Vinicius Abrahao
• Re: Geoserver-PostGIS performance problems
  • From: Merlin Moncure
• Re: Geoserver-PostGIS performance problems
  • From: Merlin Moncure
• Re: Geoserver-PostGIS performance problems
  • From: Merlin Moncure
• Re: odd planner again, pg 9.0.8
  • From: Marcus Engene
• Re: transactions start time
  • From: Andres Freund
• Re: odd planner again, pg 9.0.8
  • From: Tom Lane
• Re: odd planner again, pg 9.0.8
  • From: Pavel Stehule
• odd planner again, pg 9.0.8
  • From: Marcus Engene
• Re: transactions start time
  • From: Tom Lane
• Re: Why do I need more time with partition table?
  • From: Jeff Janes
• Re: Why do I need more time with partition table?
  • From: Jan Otto
• Re: Why do I need more time with partition table?
  • From: AI Rumman
• Re: Using ctid column changes plan drastically
  • From: Thomas Kellerer
• Re: transactions start time
  • From: Aleksei Arefjev
• Re: ZFS vs. UFS
  • From: Torsten Zuehlsdorff
• Re: transactions start time
  • From: Aleksei Arefjev
• Re: Linux memory zone reclaim
  • From: Claudio Freire
• Re: Linux memory zone reclaim
  • From: Scott Marlowe
• Re: Linux memory zone reclaim
  • From: Claudio Freire
• Re: Linux memory zone reclaim
  • From: John Lister
• Re: Linux memory zone reclaim
  • From: Claudio Freire
• Re: Linux memory zone reclaim
  • From: Claudio Freire
• Re: ZFS vs. UFS
  • From: Craig James
• Re: Linux memory zone reclaim
  • From: Claudio Freire
• Re: Linux memory zone reclaim
  • From: John Lister
• Re: ZFS vs. UFS
  • From: Laszlo Nagy
• Re: ZFS vs. UFS
  • From: Laszlo Nagy
• Re: transactions start time
  • From: Richard Huxton
• Re: Using ctid column changes plan drastically
  • From: Tom Lane
• Re: Using ctid column changes plan drastically
  • From: Thomas Kellerer
• Re: Using ctid column changes plan drastically
  • From: Tom Lane
• Re: Geoserver-PostGIS performance problems
  • From: Maciek Sakrejda
• Re: Using ctid column changes plan drastically
  • From: Thomas Kellerer
• Re: Heavy inserts load wile querying...
  • From: Ioannis Anagnostopoulos
• Re: ZFS vs. UFS
  • From: Craig James
• Re: Heavy inserts load wile querying...
  • From: Craig James
• Re: ZFS vs. UFS
  • From: Torsten Zuehlsdorff
• Re: Using ctid column changes plan drastically
  • From: Tom Lane
• Heavy inserts load wile querying...
  • From: Ioannis Anagnostopoulos
• Re: ZFS vs. UFS
  • From: Ivan Voras
• Re: ZFS vs. UFS
  • From: Georgi Naplatanov
• ZFS vs. UFS
  • From: Laszlo Nagy
• Re: Why do I need more time with partition table?
  • From: Jan Otto
• Re: Why do I need more time with partition table?
  • From: AI Rumman
• transactions start time
  • From: Aleksei Arefjev
• Why do I need more time with partition table?
  • From: AI Rumman
• Using ctid column changes plan drastically
  • From: Thomas Kellerer
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Jim Vanns
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Martin French
• Re: Shards + hash = forever running queries
  • From: Daniele Varrazzo
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Jim Vanns
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Jim Vanns
• Re: Geoserver-PostGIS performance problems
  • From: Riaan van den Dool
• Re: Geoserver-PostGIS performance problems
  • From: Brett Walker
• Geoserver-PostGIS performance problems
  • From: Riaan van den Dool
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Martin French
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Craig Ringer
• Re: Efficiency of EXISTS?
  • From: Kenneth Tilton
• Re: Efficiency of EXISTS?
  • From: Merlin Moncure
• Efficiency of EXISTS?
  • From: Kenneth Tilton
• Re: High CPU Usage
  • From: Robert Haas
• Re: postgres clustering interactions with pg_dump
  • From: Robert Haas
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Jim Vanns
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Tom Lane
• Re: Shards + hash = forever running queries
  • From: Tom Lane
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Jim Vanns
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Jim Vanns
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Andrew Dunstan
• Re: Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Martin French
• Re: Shards + hash = forever running queries
  • From: Daniele Varrazzo
• Shards + hash = forever running queries
  • From: Daniele Varrazzo
• Odd blocking (or massively latent) issue - even with EXPLAIN
  • From: Jim Vanns
• Re: A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: A very long running query....
  • From: Claudio Freire
• Re: A very long running query....
  • From: Claudio Freire
• Re: A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: A very long running query....
  • From: Claudio Freire
• Re: A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: A very long running query....
  • From: Tom Lane
• Re: A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: A very long running query....
  • From: Marc Mamin
• Re: query overhead
  • From: Craig Ringer
• Re: A very long running query....
  • From: Craig Ringer
• Re: A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: A very long running query....
  • From: Tom Lane
• Re: A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: A very long running query....
  • From: Claudio Freire
• Re: A very long running query....
  • From: Rosser Schwarz
• Re: A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: A very long running query....
  • From: Claudio Freire
• A very long running query....
  • From: Ioannis Anagnostopoulos
• Re: queries are fast after dump->restore but slow again after some days dispite vacuum
  • From: Laszlo Nagy
• Deferred constraints performance impact ?
  • From: mark
• Re: queries are fast after dump->restore but slow again after some days dispite vacuum
  • From: mandavi
• Re: queries are fast after dump->restore but slow again after some days dispite vacuum
  • From: Scott Marlowe
• Re: queries are fast after dump->restore but slow again after some days dispite vacuum
  • From: Jeff Janes
• Re: queries are fast after dump->restore but slow again after some days dispite vacuum
  • From: Andrew Dunstan
• Re: queries are fast after dump->restore but slow again after some days dispite vacuum
  • From: Felix Scheicher
• Re: queries are fast after dump->restore but slow again after some days dispite vacuum
  • From: Andrew Dunstan
• Re: optimizing queries using IN and EXISTS
  • From: Nick Hofstede
• queries are fast after dump->restore but slow again after some days dispite vacuum
  • From: Felix Scheicher
• Re: Process 11812 still waiting for ExclusiveLock on extension of relation
  • From: David Kerr
• Re: optimizing queries using IN and EXISTS
  • From: Tom Lane
• Re: optimizing queries using IN and EXISTS
  • From: Nick Hofstede
• Re: Sequencial scan in a JOIN
  • From: Robert Haas
• Re: Array fundamentals
  • From: Robert Haas
• Re: optimizing queries using IN and EXISTS
  • From: Peter Geoghegan
• optimizing queries using IN and EXISTS
  • From: Nick Hofstede
• Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
  • From: Merlin Moncure
• monitoring suggestions
  • From: Campbell, Lance
• postgresql query cost values/estimates
  • From: John Lister
• Re: Process 11812 still waiting for ExclusiveLock on extension of relation
  • From: Sergey Konoplev
• Re: Linux memory zone reclaim
  • From: Claudio Freire
• Re: Linux memory zone reclaim
  • From: Dave Crooke
• Re: Linux memory zone reclaim
  • From: Scott Marlowe
• Linux memory zone reclaim
  • From: Greg Smith
• Re: Slow application response on lightly loaded server?
  • From: Scott Marlowe
• Re: Slow application response on lightly loaded server?
  • From: Mike Blackwell
• Re: Slow application response on lightly loaded server?
  • From: Scott Marlowe
• Re: Slow application response on lightly loaded server?
  • From: Mike Blackwell
• Re: Slow application response on lightly loaded server?
  • From: Scott Marlowe
• Re: Slow application response on lightly loaded server?
  • From: Mike Blackwell
• Re: very very slow inserts into very large table
  • From: Claudio Freire
• Re: Slow application response on lightly loaded server?
  • From: Scott Marlowe
• Slow application response on lightly loaded server?
  • From: Mike Blackwell
• Re: very very slow inserts into very large table
  • From: Jeff Janes
• Re: very very slow inserts into very large table
  • From: Ants Aasma
• Process 11812 still waiting for ExclusiveLock on extension of relation
  • From: David Kerr
• Re: very very slow inserts into very large table
  • From: Satoshi Nagayasu
• Re: very very slow inserts into very large table
  • From: Craig Ringer
• Re: very very slow inserts into very large table
  • From: Claudio Freire
• Re: very very slow inserts into very large table
  • From: Mark Thornton