Postgres Performance Date Index

• Thread Index

• Question of using COPY on a table with triggers
  • From: Benjamin Krajmalnik
• Re: Identical query slower on 8.4 vs 8.3
  • From: Joshua D. Drake
• Re: Identical query slower on 8.4 vs 8.3
  • From: Merlin Moncure
• Re: Identical query slower on 8.4 vs 8.3
  • From: Kevin Grittner
• Re: Identical query slower on 8.4 vs 8.3
  • From: Jon Nelson
• Re: Identical query slower on 8.4 vs 8.3
  • From: Andy Colson
• Re: Identical query slower on 8.4 vs 8.3
  • From: Alvaro Herrera
• Re: Identical query slower on 8.4 vs 8.3
  • From: Patrick Donlin
• Re: Identical query slower on 8.4 vs 8.3
  • From: Kevin Grittner
• Re: Identical query slower on 8.4 vs 8.3
  • From: Thom Brown
• Identical query slower on 8.4 vs 8.3
  • From: Patrick Donlin
• Re: Query optimization problem
  • From: Yeb Havinga
• Re: performance on new linux box
  • From: Ben Chobot
• Re: performance on new linux box
  • From: Ryan Wexler
• Query optimization problem
  • From: Zotov
• Re: performance on new linux box
  • From: Scott Carey
• Re: Understanding tsearch2 performance
  • From: Ivan Voras
• Re: Need help in performance tuning.
  • From: Hannu Krosing
• Re: Understanding tsearch2 performance
  • From: Kevin Grittner
• Re: Queries with conditions using bitand operator
  • From: valgog
• Re: Understanding tsearch2 performance
  • From: Oleg Bartunov
• Re: Understanding tsearch2 performance
  • From: Ivan Voras
• Re: Understanding tsearch2 performance
  • From: Kevin Grittner
• Re: Need help in performance tuning.
  • From: Kevin Grittner
• Re: Understanding tsearch2 performance
  • From: Ivan Voras
• Re: Understanding tsearch2 performance
  • From: Stephen Frost
• Re: Understanding tsearch2 performance
  • From: Ivan Voras
• Re: Understanding tsearch2 performance
  • From: Oleg Bartunov
• Re: Understanding tsearch2 performance
  • From: Ivan Voras
• Re: Understanding tsearch2 performance
  • From: Oleg Bartunov
• Understanding tsearch2 performance
  • From: Ivan Voras
• Re: Need help in performance tuning.
  • From: Scott Marlowe
• Re: Need help in performance tuning.
  • From: Hannu Krosing
• Re: Queries with conditions using bitand operator
  • From: Joe Conway
• Re: performance on new linux box
  • From: Andy Colson
• Re: Queries with conditions using bitand operator
  • From: Andy Colson
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Magnus Hagander
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Dimitri Fontaine
• Queries with conditions using bitand operator
  • From: Elias Ghanem
• Re: Slow query with planner row strange estimation
  • From: damien hostin
• Who are you voting for?
  • From: kangayarkanni
• Re: partition queries hitting all partitions even though check key is specified
  • From: Joshua D. Drake
• Re: partition queries hitting all partitions even though check key is specified
  • From: Josh Berkus
• Re: Slow query with planner row strange estimation
  • From: phb07
• Re: Need help in performance tuning.
  • From: Bruce Momjian
• Re: performance on new linux box
  • From: Greg Smith
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Hannu Krosing
• Re: Exists, limit and alternate plans
  • From: Tom Lane
• Exists, limit and alternate plans
  • From: Віталій Тимчишин
• Re: now() gives same time within the session
  • From: Kenneth Marshall
• Re: now() gives same time within the session
  • From: A. Kretschmer
• Re: now() gives same time within the session
  • From: Thom Brown
• Re: now() gives same time within the session
  • From: Rob Wultsch
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Kevin Grittner
• Re: PostgreSQL PITR - more doubts
  • From: Kevin Grittner
• Re: now() gives same time within the session
  • From: Atul.Goel
• Re: PostgreSQL PITR - more doubts
  • From: Jayadevan M
• Re: PostgreSQL PITR - more doubts
  • From: Jesper Krogh
• PostgreSQL PITR - more doubts
  • From: Jayadevan M
• Re: now() gives same time within the session
  • From: A. Kretschmer
• now() gives same time within the session
  • From: Atul.Goel
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Craig Ringer
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Matthew Wakeling
• Re: [Fwd: Re: Slow query with planner row strange estimation]
  • From: damien hostin
• [Fwd: Re: Slow query with planner row strange estimation]
  • From: damien hostin
• Re: Slow query with planner row strange estimation
  • From: Dimitri
• Re: Need help in performance tuning.
  • From: Pierre C
• Re: performance on new linux box
  • From: Ryan Wexler
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Tom Lane
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Josh Berkus
• Re: Need help in performance tuning.
  • From: Greg Smith
• Re: Need help in performance tuning.
  • From: Jesper Krogh
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Samuel Gendler
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Robert Haas
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Craig Ringer
• Re: Pooling in Core WAS: Need help in performance tuning.
  • From: Josh Berkus
• Re: Need help in performance tuning.
  • From: Mark Kirkwood
• Re: Need help in performance tuning.
  • From: Kevin Grittner
• Re: Index usage with functions in where condition
  • From: Jeremy Palmer
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Greg Smith
• Re: Index usage with functions in where condition
  • From: Tom Lane
• Re: Need help in performance tuning.
  • From: Greg Smith
• Index usage with functions in where condition
  • From: Jeremy Palmer
• Re: Need help in performance tuning.
  • From: Robert Haas
• Re: Slow query with planner row strange estimation
  • From: Robert Haas
• Re: Need help in performance tuning.
  • From: Kevin Grittner
• Re: Need help in performance tuning.
  • From: Jorge Montero
• Re: Need help in performance tuning.
  • From: Kevin Grittner
• Re: Need help in performance tuning.
  • From: Matthew Wakeling
• Re: Need help in performance tuning.
  • From: Jorge Montero
• Re: Need help in performance tuning.
  • From: Kevin Grittner
• Re: Need help in performance tuning.
  • From: Matthew Wakeling
• Re: Need help in performance tuning.
  • From: Kevin Grittner
• Re: Need help in performance tuning.
  • From: Harpreet singh Wadhwa
• Re: Need help in performance tuning.
  • From: Brad Nicholson
• Re: Slow query with planner row strange estimation
  • From: damien hostin
• Re: Need help in performance tuning.
  • From: Craig Ringer
• Re: performance on new linux box
  • From: Samuel Gendler
• Re: Need help in performance tuning.
  • From: Harpreet singh Wadhwa
• Re: performance on new linux box
  • From: Russell Smith
• Re: Need help in performance tuning.
  • From: Craig Ringer
• Re: Need help in performance tuning.
  • From: Tom Lane
• Re: Need help in performance tuning.
  • From: Samuel Gendler
• Re: Need help in performance tuning.
  • From: Craig Ringer
• Re: performance on new linux box
  • From: David Boreham
• Re: performance on new linux box
  • From: Craig James
• Re: performance on new linux box
  • From: Jochen Erwied
• Re: performance on new linux box
  • From: Timothy.Noonan
• Re: performance on new linux box
  • From: Ryan Wexler
• Re: performance on new linux box
  • From: Craig James
• Re: Need help in performance tuning.
  • From: Kevin Grittner
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Kevin Grittner
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Richard Yen
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Richard Yen
• Re: performance on new linux box
  • From: Kevin Grittner
• Re: performance on new linux box
  • From: David Boreham
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Tom Lane
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Kevin Grittner
• Re: performance on new linux box
  • From: Ryan Wexler
• Re: performance on new linux box
  • From: Kevin Grittner
• Re: performance on new linux box
  • From: Ben Chobot
• Re: performance on new linux box
  • From: Ryan Wexler
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Richard Yen
• Re: performance on new linux box
  • From: Jochen Erwied
• Re: performance on new linux box
  • From: Kevin Grittner
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Tom Lane
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Richard Yen
• Need help in performance tuning.
  • From: Harpreet singh Wadhwa
• Re: performance on new linux box
  • From: Ryan Wexler
• Re: performance on new linux box
  • From: Jochen Erwied
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Kevin Grittner
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Robert Haas
• Re: Slow query with planner row strange estimation
  • From: Robert Haas
• Fwd: performance on new linux box
  • From: Ryan Wexler
• Re: performance on new linux box
  • From: Craig James
• Re: performance on new linux boxeradmin(11983)i: STATEMENT: update license set expires= '2010-06-15' where lic
  • From: John Rouillard
• Re: performance on new linux box
  • From: Joshua D. Drake
• Re: performance on new linux box
  • From: Ryan Wexler
• Re: performance on new linux box
  • From: Kevin Grittner
• Re: performance on new linux box
  • From: Eliot Gable
• Re: performance on new linux box
  • From: Kevin Grittner
• Re: performance on new linux box
  • From: Eliot Gable
• Re: performance on new linux box
  • From: Pierre C
• Re: performance on new linux box
  • From: Andy Colson
• Re: performance on new linux box
  • From: Rob Wultsch
• Re: performance on new linux box
  • From: Tom Lane
• performance on new linux box
  • From: Ryan Wexler
• Re: Logarithmic data frequency distributions and the query planner
  • From: Tom Lane
• Logarithmic data frequency distributions and the query planner
  • From: Jerry Gamache
• Re: big data - slow select (speech search)
  • From: Robert Haas
• Re: Highly Efficient Custom Sorting
  • From: Kenneth Marshall
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Richard Yen
• Re: Highly Efficient Custom Sorting
  • From: Eliot Gable
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Richard Yen
• Re: Weird XFS WAL problem
  • From: Bruce Momjian
• Re: Slow query with planner row strange estimation
  • From: damien hostin
• Re: big data - slow select (speech search)
  • From: Michal Fapso
• Re: Two "equivalent" WITH RECURSIVE queries, one of them slow.
  • From: Merlin Moncure
• Re: Two different execution plan for the same request
  • From: Matthew Wakeling
• Re: WAL partition overloaded--by autovacuum?
  • From: Kevin Grittner
• Re: Two different execution plan for the same request
  • From: JOUANIN Nicolas (44)
• Re: Two different execution plan for the same request
  • From: Guillaume Smet
• Re: [Slony1-general] WAL partition overloaded--by autovacuum?
  • From: Mark Kirkwood
• Re: Two different execution plan for the same request
  • From: Yeb Havinga
• Re: Two different execution plan for the same request
  • From: JOUANIN Nicolas (44)
• Re: Two different execution plan for the same request
  • From: Yeb Havinga
• Two different execution plan for the same request
  • From: JOUANIN Nicolas (44)
• Invitation to connect on LinkedIn
  • From: Gourish Singbal
• Re: WAL partition overloaded--by autovacuum?
  • From: Scott Marlowe
• Re: WAL partition overloaded--by autovacuum?
  • From: Scott Marlowe
• Re: WAL partition overloaded--by autovacuum?
  • From: Scott Marlowe
• WAL partition overloaded--by autovacuum?
  • From: Richard Yen
• Re: using dbt2 postgresql 8.4 - rampup time issue
  • From: Mark Wong
• Re: Highly Efficient Custom Sorting
  • From: Tom Lane
• Re: Highly Efficient Custom Sorting
  • From: Eliot Gable
• Re: Question about partitioned query behavior
  • From: Ranga Gopalan
• Re: Question about partitioned query behavior
  • From: Stephen Frost
• Re: Highly Efficient Custom Sorting
  • From: Eliot Gable
• Re: Highly Efficient Custom Sorting
  • From: Joe Conway
• Re: Highly Efficient Custom Sorting
  • From: Eliot Gable
• Re: Question about partitioned query behavior
  • From: Robert Haas
• Re: Two "equivalent" WITH RECURSIVE queries, one of them slow.
  • From: Robert Haas
• Re: Highly Efficient Custom Sorting
  • From: Robert Haas
• Re: Extremely high CPU usage when building tables
  • From: Kevin Grittner
• Re: Extremely high CPU usage when building tables
  • From: Deborah Fuentes
• Re: Question about partitioned query behavior
  • From: Ranga Gopalan
• Re: Slow query with planner row strange estimation
  • From: damien hostin
• Re: SeqScans on boolen values / How to speed this up?
  • From: Scott Marlowe
• Re: SeqScans on boolen values / How to speed this up?
  • From: Craig Ringer
• Re: Performance issues with postgresql-8.4.0: Query gets stuck sometimes
  • From: Robert Haas
• Re: big data - slow select (speech search)
  • From: Robert Haas
• Re: using dbt2 postgresql 8.4 - rampup time issue
  • From: MUHAMMAD ASIF
• Re: SeqScans on boolen values / How to speed this up?
  • From: Stephen Frost
• SeqScans on boolen values / How to speed this up?
  • From: Jens Hoffrichter
• Re: how to (temporarily) disable/minimize benefits of disk block cache or postgresql shared buffer
  • From: Matthew Wakeling
• Two "equivalent" WITH RECURSIVE queries, one of them slow.
  • From: Octavio Alvarez
• Re: Slow query with planner row strange estimation
  • From: damien hostin
• Re: Performance issues with postgresql-8.4.0
  • From: Craig Ringer
• Re: Extremely high CPU usage when building tables
  • From: Deborah Fuentes
• Performance issues with postgresql-8.4.0
  • From: Sachin Kumar
• Re: Highly Efficient Custom Sorting
  • From: Alvaro Herrera
• Re: Highly Efficient Custom Sorting
  • From: Merlin Moncure
• Re: Highly Efficient Custom Sorting
  • From: Eliot Gable
• Re: Highly Efficient Custom Sorting
  • From: Merlin Moncure
• Re: Highly Efficient Custom Sorting
  • From: Eliot Gable
• Re: Highly Efficient Custom Sorting
  • From: Craig Ringer
• Re: using dbt2 postgresql 8.4 - rampup time issue
  • From: Mark Wong
• Re: No hash join across partitioned tables?
  • From: Bruce Momjian
• Re: No hash join across partitioned tables?
  • From: Robert Haas
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: No hash join across partitioned tables?
  • From: Bruce Momjian
• Re: Extremely high CPU usage when building tables
  • From: Rajesh Kumar Mallah
• Re: how to (temporarily) disable/minimize benefits of disk block cache or postgresql shared buffer
  • From: Rajesh Kumar Mallah
• Re: Low perfomance SUM and Group by large databse
  • From: Robert Haas
• Re: Question about partitioned query behavior
  • From: Benjamin Krajmalnik
• Re: Highly Efficient Custom Sorting
  • From: Craig James
• Question about partitioned query behavior
  • From: Ranga Gopalan
• Re: Highly Efficient Custom Sorting
  • From: Merlin Moncure
• Re: Highly Efficient Custom Sorting
  • From: Matthew Wakeling
• using dbt2 postgresql 8.4 - rampup time issue
  • From: MUHAMMAD ASIF
• Re: Highly Efficient Custom Sorting
  • From: Merlin Moncure
• Re: Highly Efficient Custom Sorting
  • From: Eliot Gable
• Slow query with planner row strange estimation
  • From: damien hostin
• Re: Performance issues with postgresql-8.4.0: Query gets stuck sometimes
  • From: Scott Marlowe
• Performance issues with postgresql-8.4.0: Query gets stuck sometimes
  • From: Sachin Kumar
• Re: big data - slow select (speech search)
  • From: Michal Fapso
• Re: Highly Efficient Custom Sorting
  • From: Tom Lane
• Re: No hash join across partitioned tables?
  • From: Tom Lane
• Re: Highly Efficient Custom Sorting
  • From: Craig Ringer
• Re: how to (temporarily) disable/minimize benefits of disk block cache or postgresql shared buffer
  • From: Craig Ringer
• Re: No hash join across partitioned tables?
  • From: Bruce Momjian
• Highly Efficient Custom Sorting
  • From: Eliot Gable
• big data - slow select (speech search)
  • From: Michal Fapso
• Re: how to (temporarily) disable/minimize benefits of disk block cache or postgresql shared buffer
  • From: Rajesh Kumar Mallah
• Re: how to (temporarily) disable/minimize benefits of disk block cache or postgresql shared buffer
  • From: Craig Ringer
• Re: optimal ZFS filesystem on JBOD layout
  • From: Greg Smith
• optimal ZFS filesystem on JBOD layout
  • From: Joachim Worringen
• Re: What is the best way to optimize this query
  • From: Thom Brown
• Re: What is the best way to optimize this query
  • From: Rajesh Kumar Mallah
• What is the best way to optimize this query
  • From: Srikanth Kata
• Re: Extremely high CPU usage when building tables
  • From: Rajesh Kumar Mallah
• how to (temporarily) disable/minimize benefits of disk block cache or postgresql shared buffer
  • From: Rajesh Kumar Mallah
• Extremely high CPU usage when building tables
  • From: Deborah Fuentes
• Re: PostgreSQL as a local in-memory cache
  • From: Greg Smith
• Re: Analysis Function
  • From: Bruce Momjian
• Re: Architecting a database
  • From: Ben Chobot
• Re: PostgreSQL as a local in-memory cache
  • From: Jignesh Shah
• Re: Architecting a database
  • From: tony
• Re: PostgreSQL as a local in-memory cache
  • From: Craig James
• Re: PostgreSQL as a local in-memory cache
  • From: Dave Crooke
• Re: PostgreSQL as a local in-memory cache
  • From: Bruce Momjian
• Re: PostgreSQL as a local in-memory cache
  • From: Brad Nicholson
• Re: ideal storage configuration
  • From: Greg Smith
• Re: ideal storage configuration
  • From: Matthew Wakeling
• Re: PostgreSQL as a local in-memory cache
  • From: Bruce Momjian
• Re: pgbench results on a new server
  • From: Greg Smith
• Re: PostgreSQL as a local in-memory cache
  • From: Jignesh Shah
• Re: ideal storage configuration
  • From: Kevin Grittner
• ideal storage configuration
  • From: Samuel Gendler
• 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: Robert Haas
• Re: cpu bound postgresql setup.
  • From: Bruce Momjian
• Re: cpu bound postgresql setup.
  • From: Benjamin Krajmalnik
• Re: PostgreSQL as a local in-memory cache
  • From: Kevin Grittner
• Re: PostgreSQL as a local in-memory cache
  • From: Bruce Momjian
• Re: pgbench results on a new server
  • From: Merlin Moncure
• Re: Low perfomance SUM and Group by large databse
  • From: Sergio Charpinel Jr.
• Re: PostgreSQL as a local in-memory cache
  • From: Robert Haas
• Re: PostgreSQL as a local in-memory cache
  • From: Bruce Momjian
• Re: cpu bound postgresql setup.
  • From: Bruce Momjian
• Re: order by slowing down a query by 80 times
  • From: Tom Lane
• Re: order by slowing down a query by 80 times
  • From: Rajesh Kumar Mallah
• Re: order by slowing down a query by 80 times
  • From: Rajesh Kumar Mallah
• Re: pgbench results on a new server
  • From: Craig James
• Re: order by slowing down a query by 80 times
  • From: Tom Lane
• Re: order by slowing down a query by 80 times
  • From: Kevin Grittner
• Re: order by slowing down a query by 80 times
  • From: Rajesh Kumar Mallah
• Re: order by slowing down a query by 80 times
  • From: Andres Freund
• Re: order by slowing down a query by 80 times
  • From: Yeb Havinga
• order by slowing down a query by 80 times
  • From: Rajesh Kumar Mallah
• Re: Architecting a database
  • From: Dimitri Fontaine
• Re: Architecting a database
  • From: Merlin Moncure
• 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: Architecting a database
  • From: Craig Ringer
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Rajesh Kumar Mallah
• Re: Architecting a database
  • From: Bryan Hinton
• Re: WAL+Os on a single disk
  • From: Robert Haas
• Re: Architecting a database
  • From: Greg Smith
• Re: Architecting a database
  • From: Craig James
• Re: Architecting a database
  • From: Kevin Grittner
• Re: Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Tom Molesworth
• Architecting a database
  • From: tony
• Re: pgbench results on a new server
  • From: Greg Smith
• Re: pgbench results on a new server
  • From: Scott Marlowe
• Re: sudden spurt in swap utilization (was:cpu bound postgresql setup.)
  • From: Rajesh Kumar Mallah
• pgbench results on a new server
  • From: Craig James
• 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