Postgres Performance Date Index

• Thread Index

• Any recent AMD purchases?
  • From: Greg Smith
• Re: Write performance
  • From: Scott Carey
• Re: Occasional giant spikes in CPU load
  • From: Craig James
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Greg Smith
• Re: Occasional giant spikes in CPU load
  • From: Tom Lane
• Re: Occasional giant spikes in CPU load
  • From: Greg Smith
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Kevin Grittner
• Re: Occasional giant spikes in CPU load
  • From: Kevin Grittner
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Tom Molesworth
• Re: Occasional giant spikes in CPU load
  • From: Craig James
• Re: Occasional giant spikes in CPU load
  • From: Rajesh Kumar Mallah
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Rajesh Kumar Mallah
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Rajesh Kumar Mallah
• Re: Occasional giant spikes in CPU load
  • From: Tom Lane
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Kevin Grittner
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Rajesh Kumar Mallah
• Re: Occasional giant spikes in CPU load
  • From: Craig James
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Yeb Havinga
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Devrim GÜNDÜZ
• sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Rajesh Kumar Mallah
• Re: requested shared memory size overflows size_t
  • From: Jim Montgomery
• Re: Occasional giant spikes in CPU load
  • From: Tom Lane
• Re: requested shared memory size overflows size_t
  • From: Robert Haas
• Re: Occasional giant spikes in CPU load
  • From: Greg Smith
• Re: Occasional giant spikes in CPU load
  • From: Joshua D. Drake
• Re: Occasional giant spikes in CPU load
  • From: Craig James
• Re: System tables screwed up? (WAS requested shared memory size overflows size_t)
  • From: Alvaro Herrera
• Re: System tables screwed up? (WAS requested shared memory size overflows size_t)
  • From: Craig James
• Re: requested shared memory size overflows size_t
  • From: Alvaro Herrera
• Re: requested shared memory size overflows size_t
  • From: Craig James
• Re: PostgreSQL as a local in-memory cache
  • From: Pavel Stehule
• Re: PostgreSQL as a local in-memory cache
  • From: Josh Berkus
• Re: PostgreSQL as a local in-memory cache
  • From: Pavel Stehule
• Re: PostgreSQL as a local in-memory cache
  • From: A.M.
• Re: PostgreSQL as a local in-memory cache
  • From: Pavel Stehule
• Re: PostgreSQL as a local in-memory cache
  • From: Joshua D. Drake
• Re: PostgreSQL as a local in-memory cache
  • From: Pavel Stehule
• Re: cpu bound postgresql setup.
  • From: Kevin Grittner
• Re: cpu bound postgresql setup.
  • From: Alvaro Herrera
• Re: PostgreSQL as a local in-memory cache
  • From: Josh Berkus
• Re: cpu bound postgresql setup.
  • From: Benjamin Krajmalnik
• Re: cpu bound postgresql setup.
  • From: Rajesh Kumar Mallah
• Re: cpu bound postgresql setup.
  • From: Rajesh Kumar Mallah
• Re: Write performance
  • From: Jesper Krogh
• Re: Write performance
  • From: Janning Vygen
• Re: cpu bound postgresql setup.
  • From: Kevin Grittner
• Re: ALTER Table and CLUSTER does adding a new column rewrite clustered? (8.4.3)
  • From: Bruce Momjian
• Re: cpu bound postgresql setup.
  • From: Rajesh Kumar Mallah
• Re: WAL+Os on a single disk
  • From: Anj Adu
• Re: Write performance
  • From: Greg Smith
• Re: WAL+Os on a single disk
  • From: Scott Marlowe
• Re: Write performance
  • From: Janning
• Re: Write performance
  • From: Janning
• Re: Write performance
  • From: Matthew Wakeling
• Re: Write performance
  • From: Kenneth Marshall
• Write performance
  • From: Janning
• Re: PostgreSQL as a local in-memory cache
  • From: Robert Haas
• Re: Small Queries Really Fast, Large Queries Really Slow...
  • From: tv
• Small Queries Really Fast, Large Queries Really Slow...
  • From: Tom Wilcox
• Re: WAL+Os on a single disk
  • From: Matthew Wakeling
• Re: PostgreSQL as a local in-memory cache
  • From: Rob Wultsch
• Re: PostgreSQL as a local in-memory cache
  • From: Dimitri Fontaine
• Re: PostgreSQL as a local in-memory cache
  • From: Bruce Momjian
• Re: PostgreSQL as a local in-memory cache
  • From: Tom Lane
• Re: PostgreSQL as a local in-memory cache
  • From: Bruce Momjian
• Re: PostgreSQL as a local in-memory cache
  • From: Dave Page
• Re: PostgreSQL as a local in-memory cache
  • From: Robert Haas
• Re: PostgreSQL as a local in-memory cache
  • From: Bruce Momjian
• Re: PostgreSQL as a local in-memory cache
  • From: Pavel Stehule
• Re: PostgreSQL as a local in-memory cache
  • From: Bruce Momjian
• Re: PostgreSQL as a local in-memory cache
  • From: Bruce Momjian
• Re: WAL+Os on a single disk
  • From: Scott Marlowe
• WAL+Os on a single disk
  • From: Anj Adu
• Re: Aggressive autovacuuming ?
  • From: Robert Haas
• Re: Aggressive autovacuuming ?
  • From: Scott Marlowe
• Re: Aggressive autovacuuming ?
  • From: Robert Haas
• Re: cpu bound postgresql setup.
  • From: Kevin Grittner
• Re: cpu bound postgresql setup. Firstly many thanks for responding. I am concerned because the load averages have increased and users complaining of slowness. I do not change settings frequenly. I was curious if there is any half dead component in th
  • From: Rajesh Kumar Mallah
• Re: slow index lookup
  • From: Kevin Grittner
• Re: slow index lookup
  • From: Anj Adu
• Re: cpu bound postgresql setup.
  • From: Kevin Grittner
• Re: cpu bound postgresql setup.
  • From: Rajesh Kumar Mallah
• Re: raid10 write performance
  • From: Scott Marlowe
• Re: raid10 write performance
  • From: Scott Marlowe
• Re: raid10 write performance
  • From: Matthew Wakeling
• Re: raid10 write performance
  • From: Ivan Voras
• Re: raid10 write performance
  • From: Florian Weimer
• Re: Low perfomance SUM and Group by large databse
  • From: Sergio Charpinel Jr.
• Re: raid10 write performance
  • From: Ivan Voras
• Re: Query about index usage
  • From: Jayadevan M
• Re: Query about index usage
  • From: Greg Smith
• Re: Query about index usage
  • From: Jayadevan M
• Re: slow index lookup
  • From: Anj Adu
• Re: slow index lookup
  • From: Tom Lane
• Re: slow index lookup
  • From: Anj Adu
• Re: slow index lookup
  • From: Joshua D. Drake
• Re: slow index lookup
  • From: Anj Adu
• Re: slow index lookup
  • From: Alvaro Herrera
• slow index lookup
  • From: Anj Adu
• ALTER Table and CLUSTER does adding a new column rewrite clustered? (8.4.3)
  • From: Scott Carey
• Re: raid10 write performance
  • From: Scott Carey
• Re: raid10 write performance
  • From: Dave Crooke
• Re: raid10 write performance
  • From: Karl Denninger
• Re: raid10 write performance
  • From: Greg Smith
• Re: raid10 write performance
  • From: Justin Graf
• Re: Low perfomance SUM and Group by large databse
  • From: Russell Smith
• raid10 write performance
  • From: Grzegorz Jaśkiewicz
• Re: PostgreSQL as a local in-memory cache
  • From: Robert Haas
• Re: Low perfomance SUM and Group by large databse
  • From: Craig Ringer
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Thom Brown
• Re: Aggressive autovacuuming ?
  • From: Kevin Grittner
• Re: Aggressive autovacuuming ?
  • From: Alvaro Herrera
• Re: Slow function in queries SELECT clause.
  • From: Davor J.
• Low perfomance SUM and Group by large databse
  • From: Sergio Charpinel Jr.
• Re: HashAggregate slower than sort?
  • From: Kevin Grittner
• Re: HashAggregate slower than sort?
  • From: Jatinder Sangha
• Re: Obtaining the exact size of the database.
  • From: Scott Marlowe
• Re: Aggressive autovacuuming ?
  • From: Scott Marlowe
• Re: Obtaining the exact size of the database.
  • From: Greg Smith
• Re: B-Heaps
  • From: Greg Smith
• Aggressive autovacuuming ?
  • From: Jesper Krogh
• Re: Obtaining the exact size of the database.
  • From: Tom Lane
• Re: Slow function in queries SELECT clause.
  • From: Tom Lane
• Re: join vs exists
  • From: Kevin Grittner
• Re: Obtaining the exact size of the database.
  • From: Dave Crooke
• Re: Slow function in queries SELECT clause.
  • From: Davor J.
• Re: Slow function in queries SELECT clause.
  • From: Szymon Guz
• Slow function in queries SELECT clause.
  • From: Davor J.
• HashAggregate slower than sort?
  • From: Jatinder Sangha
• Obtaining the exact size of the database.
  • From: venu madhav
• join vs exists
  • From: AI Rumman
• Re: B-Heaps
  • From: Robert Haas
• Re: requested shared memory size overflows size_t
  • From: Scott Carey
• Re: PostgreSQL as a local in-memory cache
  • From: Josh Berkus
• Re: PostgreSQL as a local in-memory cache
  • From: Josh Berkus
• Re: B-Heaps
  • From: Yeb Havinga
• Re: B-Heaps
  • From: Tom Lane
• Re: B-Heaps
  • From: Kevin Grittner
• Re: B-Heaps
  • From: Yeb Havinga
• Re: requested shared memory size overflows size_t
  • From: Greg Smith
• Re: HashAggregate slower than sort?
  • From: Kevin Grittner
• Re: B-Heaps
  • From: Greg Smith
• Re: B-Heaps
  • From: Matthew Wakeling
• HashAggregate slower than sort?
  • From: Jatinder Sangha
• Re: requested shared memory size overflows size_t
  • From: Kenneth Marshall
• Re: B-Heaps
  • From: Robert Haas
• Re: PostgreSQL as a local in-memory cache
  • From: Pierre C
• Re: PostgreSQL as a local in-memory cache
  • From: Matthew Wakeling
• Re: wal_synch_method = open_sync safe on RHEL 5.5?
  • From: Greg Smith
• Re: wal_synch_method = open_sync safe on RHEL 5.5?
  • From: Mark Kirkwood
• Re: Add slowdown after conversion to UTF8
  • From: Peter Eisentraut
• Re: wal_synch_method = open_sync safe on RHEL 5.5?
  • From: Mark Mielke
• Re: wal_synch_method = open_sync safe on RHEL 5.5?
  • From: Greg Smith
• wal_synch_method = open_sync safe on RHEL 5.5?
  • From: Mark Kirkwood
• Re: requested shared memory size overflows size_t
  • From: Tom Wilcox
• Re: PostgreSQL as a local in-memory cache
  • From: Tom Lane
• Re: Add slowdown after conversion to UTF8
  • From: Tom Lane
• Re: PostgreSQL as a local in-memory cache
  • From: Josh Berkus
• Add slowdown after conversion to UTF8
  • From: Brant Fitzsimmons
• Re: requested shared memory size overflows size_t
  • From: Greg Smith
• Re: PostgreSQL as a local in-memory cache
  • From: Pierre C
• Re: PostgreSQL as a local in-memory cache
  • From: Greg Smith
• Re: PostgreSQL as a local in-memory cache
  • From: Tom Lane
• Re: PostgreSQL as a local in-memory cache
  • From: Dimitri Fontaine
• Re: PostgreSQL as a local in-memory cache
  • From: Pierre C
• Re: PostgreSQL as a local in-memory cache
  • From: Josh Berkus
• Re: Query slow after analyse on postgresql 8.2
  • From: Kaufhold, Christian (LFD)
• Re: Query slow after analyse on postgresql 8.2
  • From: Tom Lane
• Re: Parallel queries for a web-application |performance testing
  • From: Pierre C
• Re: Parallel queries for a web-application |performance testing
  • From: Dimitri Fontaine
• Re: Parallel queries for a web-application |performance testing
  • From: Matthew Wakeling
• Re: Parallel queries for a web-application |performance testing
  • From: Dimitri Fontaine
• Query slow after analyse on postgresql 8.2
  • From: Kaufhold, Christian (LFD)
• Re: PostgreSQL as a local in-memory cache
  • From: jgardner@xxxxxxxxxxxxxxxxxxx
• Re: Parallel queries for a web-application |performance testing
  • From: Kevin Grittner
• Re: requested shared memory size overflows size_t
  • From: Tom Wilcox
• PostgreSQL as a local in-memory cache
  • From: jgardner@xxxxxxxxxxxxxxxxxxx
• Re: requested shared memory size overflows size_t
  • From: Alvaro Herrera
• Parallel queries for a web-application |performance testing
  • From: Balkrishna Sharma
• Re: Analysis Function
  • From: Tom Lane
• Re: PostgreSQL as a local in-memory cache
  • From: Pierre C
• Re: PostgreSQL as a local in-memory cache
  • From: Craig James
• Re: PostgreSQL as a local in-memory cache
  • From: Jonathan Gardner
• Re: Confirm calculus
  • From: Scott Marlowe
• Re: PostgreSQL as a local in-memory cache
  • From: Balkrishna Sharma
• Re: Confirm calculus
  • From: Kevin Grittner
• Re: PostgreSQL as a local in-memory cache
  • From: Jonathan Gardner
• Re: PostgreSQL as a local in-memory cache
  • From: Jonathan Gardner
• Re: PostgreSQL as a local in-memory cache
  • From: Jonathan Gardner
• Confirm calculus
  • From: Juan Pablo Sandoval Rivera
• Confirm calculus
  • From: Juan Pablo Sandoval Rivera
• Re: PostgreSQL as a local in-memory cache
  • From: Josh Berkus
• Re: PostgreSQL as a local in-memory cache
  • From: Alvaro Herrera
• Re: PostgreSQL as a local in-memory cache
  • From: Pierre C
• Re: Analysis Function
  • From: David Jarvis
• Re: PostgreSQL as a local in-memory cache
  • From: Greg Smith
• Re: PostgreSQL as a local in-memory cache
  • From: Pierre C
• Re: PostgreSQL as a local in-memory cache
  • From: Pierre C
• Re: PostgreSQL as a local in-memory cache
  • From: Mark Kirkwood
• Re: PostgreSQL as a local in-memory cache
  • From: jgardner@xxxxxxxxxxxxxxxxxxx
• Re: Analysis Function
  • From: Magnus Hagander
• Re: PostgreSQL as a local in-memory cache
  • From: Josh Berkus
• Re: PostgreSQL as a local in-memory cache
  • From: Jaime Casanova
• Re: B-Heaps
  • From: Yeb Havinga
• Re: PostgreSQL as a local in-memory cache
  • From: Chris Browne
• Re: PostgreSQL as a local in-memory cache
  • From: jgardner@xxxxxxxxxxxxxxxxxxx
• Re: PostgreSQL as a local in-memory cache
  • From: Craig James
• Re: PostgreSQL as a local in-memory cache
  • From: Steve Wampler
• Re: PostgreSQL as a local in-memory cache
  • From: Chris Browne
• Re: B-Heaps
  • From: Matthew Wakeling
• Re: B-Heaps
  • From: A. Kretschmer
• Re: B-Heaps
  • From: Greg Smith
• Re: B-Heaps
  • From: Heikki Linnakangas
• Re: requested shared memory size overflows size_t
  • From: Tom Lane
• Re: requested shared memory size overflows size_t
  • From: Scott Carey
• Re: requested shared memory size overflows size_t
  • From: Scott Carey
• B-Heaps
  • From: Eliot Gable
• Re: requested shared memory size overflows size_t
  • From: Greg Smith
• Re: requested shared memory size overflows size_t
  • From: Tom Wilcox
• Re: requested shared memory size overflows size_t
  • From: Dave Crooke
• Re: requested shared memory size overflows size_t
  • From: Tom Wilcox
• Re: requested shared memory size overflows size_t
  • From: Dave Crooke
• Re: requested shared memory size overflows size_t
  • From: Robert Haas
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Lacey Powers
• Re: requested shared memory size overflows size_t
  • From: Tom Wilcox
• Re: Fwd: Dead lock
  • From: Merlin Moncure
• Re: query hangs
  • From: Scott Marlowe
• RE: [PERFORM] Dbt2 with postgres issues on CentOS-5.3‏
  • From: MUHAMMAD ASIF
• Re: Fwd: Dead lock
  • From: Dave Crooke
• Fwd: Dead lock
  • From: Elias Ghanem
• Re: query hangs
  • From: Kevin Grittner
• Re: Dead lock
  • From: Andy Colson
• Re: Analysis Function
  • From: Tom Lane
• Re: query tuning help
  • From: Andy Colson
• Re: Dead lock
  • From: Tom Molesworth
• Dead lock
  • From: Elias Ghanem
• Re: Analysis Function
  • From: David Jarvis
• query tuning help
  • From: AI Rumman
• Re: Analysis Function
  • From: Magnus Hagander
• Re: Analysis Function
  • From: Magnus Hagander
• Re: Query about index usage
  • From: Jayadevan M
• Re: out of memory
  • From: Kenichiro Tanaka
• Re: Analysis Function
  • From: David Jarvis
• Re: Analysis Function
  • From: Tom Lane
• Re: Analysis Function
  • From: Magnus Hagander
• Re: Analysis Function
  • From: Tom Lane
• Re: Analysis Function
  • From: Tom Lane
• Re: out of memory
  • From: Anj Adu
• out of memory
  • From: AI Rumman
• Re: query hangs
  • From: AI Rumman
• Re: Analysis Function
  • From: Magnus Hagander
• Re: Analysis Function
  • From: David Jarvis
• Re: Analysis Function
  • From: Heikki Linnakangas
• Re: ~400 TPS - good or bad?
  • From: Greg Smith
• Re: ~400 TPS - good or bad?
  • From: Merlin Moncure
• Re: ~400 TPS - good or bad?
  • From: Szymon Kosok
• ~400 TPS - good or bad?
  • From: Szymon Kosok
• Re: Analysis Function
  • From: David Jarvis
• Re: Analysis Function
  • From: David Jarvis
• Re: Analysis Function
  • From: Tom Lane
• Re: Analysis Function
  • From: Tim Landscheidt
• Re: Query about index usage
  • From: Bob Lunney
• Re: Analysis Function
  • From: David Jarvis
• Re: Analysis Function
  • From: David Jarvis
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: John Reeve
• O/T: performance tuning cars
  • From: Dave Crooke
• Re: Query about index usage
  • From: Greg Smith
• Re: Query about index usage
  • From: Kevin Grittner
• Re: slow query performance
  • From: Matthew Wakeling
• Re: slow query performance
  • From: Kenneth Marshall
• Re: slow query performance
  • From: Anj Adu
• Re: slow query performance
  • From: Kenneth Marshall
• Re: Analysis Function
  • From: Tim Landscheidt
• Query about index usage
  • From: Jayadevan M
• Re: Analysis Function
  • From: Heikki Linnakangas
• Re: Analysis Function
  • From: David Jarvis
• Re: Analysis Function
  • From: Tim Landscheidt
• Re: Analysis Function
  • From: David Jarvis
• Re: requested shared memory size overflows size_t
  • From: Bob Lunney
• Re: query hangs
  • From: Amit Khandekar
• Re: Analysis Function
  • From: David Jarvis
• Re: slow query performance
  • From: Anj Adu
• Re: Analysis Function
  • From: Andy Colson
• Re: slow query performance
  • From: Robert Haas
• Re: Analysis Function
  • From: David Jarvis
• Re: Need to increase performance of a query
  • From: Anne Rosset
• Re: Need to increase performance of a query
  • From: Joe Conway
• Re: Need to increase performance of a query
  • From: Heikki Linnakangas
• Re: Need to increase performance of a query
  • From: Anne Rosset
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Greg Smith
• Re: Need to increase performance of a query
  • From: Joe Conway
• Re: Need to increase performance of a query
  • From: Joe Conway
• Re: Need to increase performance of a query
  • From: Anne Rosset
• Re: Need to increase performance of a query
  • From: Heikki Linnakangas
• Re: Need to increase performance of a query
  • From: Anne Rosset
• Re: Need to increase performance of a query
  • From: Craig James
• Re: Need to increase performance of a query
  • From: Anne Rosset
• Re: Need to increase performance of a query
  • From: Anne Rosset
• Re: Need to increase performance of a query
  • From: Jochen Erwied
• Re: Need to increase performance of a query
  • From: Jochen Erwied
• Re: Need to increase performance of a query
  • From: Kenneth Marshall
• Re: Need to increase performance of a query
  • From: Anne Rosset
• Re: Need to increase performance of a query
  • From: Anne Rosset
• Re: Need to increase performance of a query
  • From: hubert depesz lubaczewski
• Re: Need to increase performance of a query
  • From: Jesper Krogh
• Need to increase performance of a query
  • From: Anne Rosset
• Re: slow query performance
  • From: Anj Adu
• Re: Performance tuning for postgres
  • From: Robert Haas
• Re: slow query performance
  • From: Robert Haas
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Alvaro Herrera
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Tom Lane
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Max Williams
• Re: slow query performance
  • From: Anj Adu
• Re: Autovaccum settings while Bulk Loading data
  • From: Heikki Linnakangas
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Tom Lane
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Kevin Grittner
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Max Williams
• Re: requested shared memory size overflows size_t
  • From: Bob Lunney
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Tom Lane
• Re: slow query performance
  • From: Robert Haas
• Re: query hangs
  • From: AI Rumman
• Re: query hangs
  • From: Amit Khandekar
• Re: query hangs
  • From: AI Rumman
• Re: query hangs
  • From: Kevin Grittner
• Re: Autovaccum settings while Bulk Loading data
  • From: Heikki Linnakangas
• Re: query hangs
  • From: Szymon Guz
• Re: query hangs
  • From: AI Rumman
• Re: query hangs
  • From: Szymon Guz
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Max Williams
• query hangs
  • From: AI Rumman
• Autovaccum settings while Bulk Loading data
  • From: Ambarish Bhattacharya
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Devrim GÜNDÜZ
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Max Williams
• Re: slow query performance
  • From: Anj Adu
• Re: slow query performance
  • From: Tom Lane
• Re: slow query performance
  • From: Robert Haas
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Robert Haas
• Re: requested shared memory size overflows size_t
  • From: Robert Haas
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: No hash join across partitioned tables?
  • From: Robert Haas
• Re: Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Pierre C
• Large (almost 50%!) performance drop after upgrading to 8.4.4?
  • From: Max Williams
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Pierre C
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Torsten Zühlsdorff
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Pierre C
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Torsten Zühlsdorff
• Re: performance of temporary vs. regular tables
  • From: Pierre C
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Pierre C
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Scott Marlowe
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Torsten Zühlsdorff
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Torsten Zühlsdorff
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Andy Colson
• Re: How filesystems matter with PostgreSQL
  • From: Craig Ringer
• Re: How filesystems matter with PostgreSQL
  • From: Ron Mayer
• Re: How filesystems matter with PostgreSQL
  • From: Scott Marlowe
• Re: How filesystems matter with PostgreSQL
  • From: Jon Schewe
• Re: How filesystems matter with PostgreSQL
  • From: Scott Marlowe
• Re: How filesystems matter with PostgreSQL
  • From: Jon Schewe
• Re: How filesystems matter with PostgreSQL
  • From: Scott Marlowe
• Re: How filesystems matter with PostgreSQL
  • From: Jon Schewe
• Re: How filesystems matter with PostgreSQL
  • From: Greg Smith
• Re: Weird XFS WAL problem
  • From: Greg Smith
• Re: How filesystems matter with PostgreSQL
  • From: Jon Schewe
• Re: How filesystems matter with PostgreSQL
  • From: Greg Smith
• Re: slow query
  • From: Scott Marlowe
• Re: slow query
  • From: Anj Adu
• Re: slow query
  • From: Scott Marlowe
• Re: slow query
  • From: hubert depesz lubaczewski
• Re: PgAdmin iii - Explain.
  • From: Robert Haas
• Re: how to force hashaggregate plan?
  • From: Robert Haas
• Re: planner costs in "warm cache" tests
  • From: Robert Haas
• Re: How filesystems matter with PostgreSQL
  • From: Jon Schewe
• Re: How filesystems matter with PostgreSQL
  • From: Andres Freund
• Re: How filesystems matter with PostgreSQL
  • From: Jon Schewe
• Re: How filesystems matter with PostgreSQL
  • From: Bryan Hinton
• Re: How filesystems matter with PostgreSQL
  • From: Jon Schewe
• Re: How filesystems matter with PostgreSQL
  • From: Jon Schewe
• Re: slow query
  • From: Anj Adu
• Re: How filesystems matter with PostgreSQL
  • From: Bryan Hinton
• Re: Performance tuning for postgres
  • From: Bryan Hinton
• Re: slow query
  • From: Anj Adu
• Re: slow query
  • From: Anj Adu
• Re: slow query
  • From: Anj Adu
• Re: Weird XFS WAL problem
  • From: Bruce Momjian
• Re: Weird XFS WAL problem
  • From: Kevin Grittner
• Re: Weird XFS WAL problem
  • From: Bruce Momjian
• Re: performance regression with Linux 2.6.33 and glibc 2.12
  • From: Marc Cousin
• Re: performance regression with Linux 2.6.33 and glibc 2.12
  • From: Andres Freund
• Re: Weird XFS WAL problem
  • From: Kevin Grittner
• Re: Weird XFS WAL problem
  • From: Bruce Momjian
• Re: Weird XFS WAL problem
  • From: Kevin Grittner
• Re: Weird XFS WAL problem
  • From: Bruce Momjian
• Re: Performance tuning for postgres
  • From: Michael Gould
• Re: How filesystems matter with PostgreSQL
  • From: Andres Freund
• Re: How filesystems matter with PostgreSQL
  • From: Tom Lane
• Re: Performance tuning for postgres
  • From: Kevin Grittner
• Re: performance regression with Linux 2.6.33 and glibc 2.12
  • From: Tom Lane
• performance regression with Linux 2.6.33 and glibc 2.12
  • From: Marc Cousin
• Re: How filesystems matter with PostgreSQL
  • From: Andres Freund
• Re: How filesystems matter with PostgreSQL
  • From: J. Roeleveld
• How filesystems matter with PostgreSQL
  • From: Jon Schewe
• Re: Weird XFS WAL problem
  • From: Matthew Wakeling
• Re: slow query
  • From: Matthew Wakeling
• Re: slow query
  • From: tv
• Performance tuning for postgres
  • From: Yogesh Naik
• slow query
  • From: Anj Adu
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Cédric Villemain
• Re: slow query performance
  • From: Anj Adu
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Scott Marlowe
• Re: Weird XFS WAL problem
  • From: Kevin Grittner
• Re: Weird XFS WAL problem
  • From: Scott Marlowe
• Re: Weird XFS WAL problem
  • From: Greg Smith
• Re: Weird XFS WAL problem
  • From: Kevin Grittner
• Re: Weird XFS WAL problem
  • From: Scott Marlowe
• Re: slow query performance
  • From: Andy Colson
• Re: Weird XFS WAL problem
  • From: Kevin Grittner
• Re: Weird XFS WAL problem
  • From: Greg Smith
• Re: Weird XFS WAL problem
  • From: Greg Smith
• slow query performance
  • From: Anj Adu
• Re: Weird XFS WAL problem
  • From: Kevin Grittner
• Re: Weird XFS WAL problem
  • From: Matthew Wakeling
• Re: Weird XFS WAL problem
  • From: Craig James
• Re: Weird XFS WAL problem
  • From: Greg Smith
• Re: SELECT ignoring index even though ORDER BY and LIMIT present
  • From: Jori Jovanovich
• Re: Weird XFS WAL problem
  • From: Merlin Moncure
• Re: SELECT ignoring index even though ORDER BY and LIMIT present
  • From: Matthew Wakeling
• Re: requested shared memory size overflows size_t
  • From: Joshua Tolley
• Re: SELECT ignoring index even though ORDER BY and LIMIT present
  • From: Bob Lunney
• Re: requested shared memory size overflows size_t
  • From: Bob Lunney
• Re: Weird XFS WAL problem
  • From: Mark Kirkwood
• Weird XFS WAL problem
  • From: Craig James
• Re: SELECT ignoring index even though ORDER BY and LIMIT present
  • From: Tom Lane
• Re: SELECT ignoring index even though ORDER BY and LIMIT present
  • From: Szymon Guz
• Re: SELECT ignoring index even though ORDER BY and LIMIT present
  • From: Kevin Grittner
• SELECT ignoring index even though ORDER BY and LIMIT present
  • From: Jori Jovanovich
• Re: File system choice for Red Hat systems
  • From: Mark Kirkwood
• Re: Certain query eating up all free memory (out of memory error)
  • From: Robert Haas
• Re: requested shared memory size overflows size_t
  • From: Stephen Frost
• Re: requested shared memory size overflows size_t
  • From: Kevin Grittner
• Re: Autovacuum in postgres.
  • From: Scott Marlowe
• Re: How to insert a bulk of data with unique-violations very fast
  • From: Scott Marlowe
• Re: requested shared memory size overflows size_t
  • From: Tom Wilcox
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• PgAdmin iii - Explain.
  • From: Jeres Caldeira Gomes
• How to insert a bulk of data with unique-violations very fast
  • From: Torsten Zühlsdorff
• 答复: [PERFORM] About Tom Lane's Xeon CS test case
  • From: 黄永卫
• how to force hashaggregate plan?
  • From: Slava Moudry
• Re: [BUGS] Query causing explosion of temp space with join involving partitioning
  • From: Krzysztof Nienartowicz
• Re: Autovacuum in postgres.
  • From: venu madhav
• Re: File system choice for Red Hat systems
  • From: Wales Wang
• Re: File system choice for Red Hat systems
  • From: Alan Hodgson
• Re: Overusing 1 CPU
  • From: J. Roeleveld
• Re: performance of temporary vs. regular tables
  • From: Joachim Worringen
• Re: Overusing 1 CPU
  • From: Stephen Frost
• Re: Overusing 1 CPU
  • From: A. Kretschmer
• Re: Overusing 1 CPU
  • From: Mozzi
• Re: Overusing 1 CPU
  • From: Matthew Wakeling
• Overusing 1 CPU
  • From: Mozzi
• Re: performance of temporary vs. regular tables
  • From: Pierre C
• Re: File system choice for Red Hat systems
  • From: Greg Smith
• Re: File system choice for Red Hat systems
  • From: Mark Kirkwood
• Re: File system choice for Red Hat systems
  • From: Devrim GÜNDÜZ
• Re: File system choice for Red Hat systems
  • From: Mark Kirkwood
• Re: File system choice for Red Hat systems
  • From: Tom Lane
• File system choice for Red Hat systems
  • From: Mark Kirkwood
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Alvaro Herrera
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Alvaro Herrera
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Merlin Moncure
• Re: planner costs in "warm cache" tests
  • From: Tom Lane
• Re: Zeus IOPS
  • From: Brad Nicholson
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Matthew Wakeling
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Stephen Frost
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Matthew Wakeling
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Matthew Wakeling
• Re: Zeus IOPS
  • From: Mindaugas Riauba
• Re: planner costs in "warm cache" tests
  • From: Scott Carey
• Re: planner costs in "warm cache" tests
  • From: Tom Lane
• Re: planner costs in "warm cache" tests
  • From: Jesper Krogh
• Re: Zeus IOPS
  • From: Scott Marlowe
• Re: Zeus IOPS
  • From: Brad Nicholson
• Re: planner costs in "warm cache" tests
  • From: Tom Lane
• planner costs in "warm cache" tests
  • From: Jesper Krogh
• Re: Strange workaround for slow query
  • From: Sander Verhagen
• Re: Wildly inaccurate query plan
  • From: Kevin Grittner
• Re: shared_buffers advice
  • From: Merlin Moncure
• Re: shared_buffers advice
  • From: Dave Crooke
• Re: shared_buffers advice
  • From: Scott Marlowe
• Re: shared_buffers advice
  • From: Greg Smith
• Re: shared_buffers advice
  • From: Merlin Moncure
• Zeus IOPS
  • From: Scott Marlowe
• Re: Wildly inaccurate query plan
  • From: Thom Brown
• Re: shared_buffers advice
  • From: Greg Smith
• Re: Wildly inaccurate query plan
  • From: Tom Lane
• Wildly inaccurate query plan
  • From: Thom Brown
• Re: performance of temporary vs. regular tables
  • From: Rob Wultsch
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Merlin Moncure
• Re: performance of temporary vs. regular tables
  • From: Joachim Worringen
• Re: shared_buffers advice
  • From: Cédric Villemain
• Re: shared_buffers advice
  • From: Konrad Garus
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: merge join killing performance
  • From: Tom Lane
• Re: merge join killing performance
  • From: Scott Marlowe
• hp hpsa vs cciss driver
  • From: Mark Wong
• Re: merge join killing performance
  • From: Tom Lane
• Re: Random Page Cost and Planner
  • From: Bryan Hinton
• Re: Does FILTER in SEQSCAN short-circuit AND?
  • From: Craig James
• Re: Does FILTER in SEQSCAN short-circuit AND?
  • From: Kevin Grittner
• Re: Does FILTER in SEQSCAN short-circuit AND?
  • From: Thomas Kellerer
• Re: Does FILTER in SEQSCAN short-circuit AND?
  • From: Craig James
• Re: Does FILTER in SEQSCAN short-circuit AND?
  • From: Kevin Grittner
• Does FILTER in SEQSCAN short-circuit AND?
  • From: Carlo Stonebanks
• Re: Random Page Cost and Planner
  • From: Cédric Villemain
• Re: shared_buffers advice
  • From: Cédric Villemain
• Re: [BUGS] Query causing explosion of temp space with join involving partitioning
  • From: Tom Lane
• Re: Autovacuum in postgres.
  • From: alvherre
• Re: Query timing increased from 3s to 55s when used as function instead of select
  • From: Craig Ringer
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: shared_buffers advice
  • From: Konrad Garus
• Re: Query timing increased from 3s to 55s when used as function instead of select
  • From: Craig Ringer
• Re: shared_buffers advice
  • From: Cédric Villemain
• Re: shared_buffers advice
  • From: Konrad Garus
• Re: Autovacuum in postgres.
  • From: Bruce Momjian
• Re: Autovacuum in postgres.
  • From: Bruce Momjian
• Re: About Tom Lane's Xeon CS test case
  • From: Tom Lane
• About Tom Lane's Xeon CS test case
  • From: 黄永卫
• Re: [BUGS] Query causing explosion of temp space with join involving partitioning
  • From: Krzysztof Nienartowicz
• Certain query eating up all free memory (out of memory error)
  • From: Łukasz Dejneka
• Query timing increased from 3s to 55s when used as function instead of select
  • From: Tyler Hildebrandt
• Re: Autovacuum in postgres.
  • From: venu madhav
• Autovacuum in postgres.
  • From: venu madhav
• Query causing explosion of temp space with join involving partitioning
  • From: Krzysztof Nienartowicz
• Re: shared_buffers advice
  • From: Cédric Villemain
• Re: shared_buffers advice
  • From: Konrad Garus
• Re: Random Page Cost and Planner
  • From: Cédric Villemain
• Re: shared_buffers advice
  • From: Cédric Villemain
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: shared_buffers advice
  • From: Konrad Garus
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: Random Page Cost and Planner
  • From: tv
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Craig James
• Re: performance of temporary vs. regular tables
  • From: Grzegorz Jaśkiewicz
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Stephen Frost
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Eliot Gable
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Stephen Frost
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Eliot Gable
• Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Stephen Frost
• PostgreSQL Function Language Performance: C vs PL/PGSQL
  • From: Eliot Gable
• Re: performance of temporary vs. regular tables
  • From: Joachim Worringen
• Re: Random Page Cost and Planner
  • From: Kevin Grittner
• Re: Random Page Cost and Planner
  • From: tv
• Re: shared_buffers advice
  • From: Cédric Villemain
• Re: Random Page Cost and Planner
  • From: Alexey Klyukin
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: Performance issues when the number of records are around 10 Million
  • From: Robert Haas
• Re: Function scan/Index scan to nested loop
  • From: Robert Haas
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: Random Page Cost and Planner
  • From: Rob Wultsch
• Re: Random Page Cost and Planner
  • From: Tom Lane
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: shared_buffers advice
  • From: Merlin Moncure
• Re: prepared query performs much worse than regular query
  • From: Joshua Tolley
• Re: Random Page Cost and Planner
  • From: Kevin Grittner
• Re: prepared query performs much worse than regular query
  • From: Scott Carey
• Re: which hardware setup
  • From: Pedro Axelrud
• Re: Query timing increased from 3s to 55s when used as a function instead of select
  • From: Jorge Montero
• Re: Query timing increased from 3s to 55s when used as a function instead of select
  • From: Merlin Moncure
• Re: Query timing increased from 3s to 55s when used as a function instead of select
  • From: Merlin Moncure
• Re: tunning pgsql 7.3.7 over RHEL 4.0 32 x86 (2.6.9-5ELsmp)
  • From: Joshua Tolley
• tunning pgsql 7.3.7 over RHEL 4.0 32 x86 (2.6.9-5ELsmp)
  • From: Juan Pablo Sandoval Rivera
• Re: Query timing increased from 3s to 55s when used as a function instead of select
  • From: Tyler Hildebrandt
• Re: performance of temporary vs. regular tables
  • From: Andres Freund
• Re: Query timing increased from 3s to 55s when used as a function instead of select
  • From: A. Kretschmer
• Re: performance of temporary vs. regular tables
  • From: Joachim Worringen
• Query timing increased from 3s to 55s when used as a function instead of select
  • From: Tyler Hildebrandt
• Re: shared_buffers advice
  • From: Konrad Garus
• Re: performance of temporary vs. regular tables
  • From: Grzegorz Jaśkiewicz
• Re: performance of temporary vs. regular tables
  • From: Joachim Worringen
• Re: performance of temporary vs. regular tables
  • From: Thom Brown
• Re: performance of temporary vs. regular tables
  • From: Joachim Worringen
• Re: performance of temporary vs. regular tables
  • From: Grzegorz Jaśkiewicz
• performance of temporary vs. regular tables
  • From: Joachim Worringen
• Re: Random Page Cost and Planner
  • From: David Jarvis
• Re: Certain query eating up all free memory (out of memory error)
  • From: Łukasz Dejneka
• Re: which hardware setup
  • From: Jesper Krogh
• Certain query eating up all free memory (out of memory error)
  • From: Łukasz Dejneka
• Random Page Cost and Planner
  • From: David Jarvis
• which hardware setup
  • From: Pedro Axelrud
• Re: shared_buffers advice
  • From: Merlin Moncure
• [SPAM] Re: shared_buffers advice
  • From: Ben Chobot
• Re: shared_buffers advice
  • From: Konrad Garus
• Re: pg_dump and pg_restore
  • From: Jayadevan M
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: pg_dump and pg_restore
  • From: Peter Koczan
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: pg_dump and pg_restore
  • From: Robert Haas
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: prepared query performs much worse than regular query
  • From: Matthew Wakeling
• Re: prepared query performs much worse than regular query
  • From: Rosser Schwarz
• prepared query performs much worse than regular query
  • From: Richard Yen
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Stephen Frost
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Matthew Wakeling
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Yeb Havinga
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Yeb Havinga
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Matthew Wakeling
• Re: old server, new server, same performance
  • From: Piotr Legiecki
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Yeb Havinga
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Yeb Havinga
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Matthew Wakeling
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Stephen Frost
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Stephen Frost
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Yeb Havinga
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Stephen Frost
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Tom Lane
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Tom Lane
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Tom Lane
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: [BUGS] Query causing explosion of temp space with join involving partitioning
  • From: Tom Lane
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Thom Brown
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Tom Lane
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Thom Brown
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Thom Brown
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: merge join killing performance
  • From: Scott Marlowe
• Re: merge join killing performance
  • From: Tom Lane
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Tom Lane
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Matthew Wakeling
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Thom Brown
• Re: Optimize date query for large child tables: GiST or GIN?
  • From: Yeb Havinga
• Optimize date query for large child tables: GiST or GIN?
  • From: David Jarvis
• Re: merge join killing performance
  • From: Scott Marlowe
• Re: merge join killing performance
  • From: Scott Marlowe
• Re: merge join killing performance
  • From: Scott Marlowe
• Re: merge join killing performance
  • From: Matthew Wakeling
• Re: merge join killing performance
  • From: Scott Marlowe
• Re: merge join killing performance
  • From: Scott Marlowe
• Re: merge join killing performance
  • From: Scott Marlowe
• Re: merge join killing performance
  • From: Tom Lane
• Re: merge join killing performance
  • From: Scott Marlowe
• Re: merge join killing performance
  • From: Matthew Wakeling
• merge join killing performance
  • From: Scott Marlowe
• Re: Slow Bulk Delete
  • From: Jon Nelson
• Re: Slow Bulk Delete
  • From: Grzegorz Jaśkiewicz
• Re: Slow Bulk Delete
  • From: Jon Nelson
• Re: Slow Bulk Delete
  • From: A. Kretschmer
• Re: Slow Bulk Delete
  • From: Grzegorz Jaśkiewicz
• Re: Slow Bulk Delete
  • From: Віталій Тимчишин
• Re: Slow Bulk Delete
  • From: Jon Nelson
• Re: old server, new server, same performance
  • From: Scott Marlowe
• Re: Slow Bulk Delete
  • From: Pierre C
• Re: old server, new server, same performance
  • From: Piotr Legiecki
• Re: old server, new server, same performance
  • From: Scott Marlowe