Postgres Performance Date Index

• Thread Index

• Re: Database design - best practice
  • From: Kevin Grittner
• Re: Optimize update query
  • From: Marcin Mirosław
• Re: Optimize update query
  • From: Shaun Thomas
• Re: Database design - best practice
  • From: Bèrto ëd Sèra
• Re: Database design - best practice
  • From: Willem Leenen
• Re: Database design - best practice
  • From: Niels Kristian Schjødt
• Re: Database design - best practice
  • From: Willem Leenen
• Optimize update query
  • From: Niels Kristian Schjødt
• Database design - best practice
  • From: Niels Kristian Schjødt
• Re: pgsql_tmp( Temporary tablespace)
  • From: Albe Laurenz
• Re: pgsql_tmp( Temporary tablespace)
  • From: suhas.basavaraj12
• Re: pgsql_tmp( Temporary tablespace)
  • From: Albe Laurenz
• pgsql_tmp( Temporary tablespace)
  • From: suhas.basavaraj12
• Re: Savepoints in transactions for speed?
  • From: Willem Leenen
• Re: Savepoints in transactions for speed?
  • From: Franklin, Dan
• Re: Hints (was Poor performance using CTE)
  • From: Scott Marlowe
• Re: Hints (was Poor performance using CTE)
  • From: Craig Ringer
• Re: Savepoints in transactions for speed?
  • From: Claudio Freire
• Re: Savepoints in transactions for speed?
  • From: Mike Blackwell
• Re: Postgres configuration for 8 CPUs, 6 GB RAM
  • From: Dave Crooke
• Re: Savepoints in transactions for speed?
  • From: Bob Lunney
• Re: Hints (was Poor performance using CTE)
  • From: Scott Marlowe
• Re: Query that uses lots of memory in PostgreSQL 9.2.1 in Windows 7
  • From: Merlin Moncure
• Re: Savepoints in transactions for speed?
  • From: Steve Atkins
• Re: How to keep queries low latency as concurrency increases
  • From: Scott Marlowe
• Re: Savepoints in transactions for speed?
  • From: Richard Huxton
• Savepoints in transactions for speed?
  • From: Mike Blackwell
• Re: Postgres configuration for 8 CPUs, 6 GB RAM
  • From: Scott Marlowe
• Re: Postgres configuration for 8 CPUs, 6 GB RAM
  • From: Andrew Dunstan
• Re: Postgres configuration for 8 CPUs, 6 GB RAM
  • From: Heikki Linnakangas
• Postgres configuration for 8 CPUs, 6 GB RAM
  • From: Syed Asif Tanveer
• Re: How to keep queries low latency as concurrency increases
  • From: Heikki Linnakangas
• Re: How to keep queries low latency as concurrency increases
  • From: Catalin Iacob
• Re: SOLVED - RE: Poor performance using CTE
  • From: Bruce Momjian
• Re: Hints (was Poor performance using CTE)
  • From: Cédric Villemain
• Re: Hints (was Poor performance using CTE)
  • From: Gavin Flower
• Re: Poor performance using CTE
  • From: Gavin Flower
• Re: Poor performance using CTE
  • From: Gavin Flower
• Re: Poor performance using CTE
  • From: Gavin Flower
• Re: Poor performance using CTE
  • From: Gavin Flower
• Re: SOLVED - RE: Poor performance using CTE
  • From: Vitalii Tymchyshyn
• Re: Poor performance using CTE
  • From: Jon Nelson
• Re: Poor performance using CTE
  • From: Jeremy Harris
• SQL performance question
  • From: Niklas Paulsson
• Re: PQconnectStart/PQconnectPoll
  • From: Craig Ringer
• Re: fast read of binary data
  • From: Heikki Linnakangas
• Re: Hints (was Poor performance using CTE)
  • From: Heikki Linnakangas
• Re: fast read of binary data
  • From: Eildert Groeneveld
• Re: Hints (was Poor performance using CTE)
  • From: Jeff Janes
• Re: Poor performance using CTE
  • From: Craig Ringer
• Re: Poor performance using CTE
  • From: Craig Ringer
• Re: Poor performance using CTE
  • From: Andrew Dunstan
• Re: Hints - experiences from other rdbms
  • From: Willem Leenen
• Re: Hints (was Poor performance using CTE)
  • From: Andreas Kretschmer
• Re: Hints (was Poor performance using CTE)
  • From: Tom Lane
• Re: Hints (was Poor performance using CTE)
  • From: Joe Conway
• Re: Hints (was Poor performance using CTE)
  • From: Craig James
• Re: Hints (was Poor performance using CTE)
  • From: Joe Conway
• Re: Poor performance using CTE
  • From: Andrew Dunstan
• Re: Poor performance using CTE
  • From: Tom Lane
• Re: Poor performance using CTE
  • From: Andres Freund
• Re: Hints (was Poor performance using CTE)
  • From: Craig James
• Re: Poor performance using CTE
  • From: Claudio Freire
• Re: Poor performance using CTE
  • From: Claudio Freire
• Re: Poor performance using CTE
  • From: Andres Freund
• Re: Poor performance using CTE
  • From: Claudio Freire
• Re: Hints (was Poor performance using CTE)
  • From: Heikki Linnakangas
• Re: Poor performance using CTE
  • From: Heikki Linnakangas
• Re: Poor performance using CTE
  • From: Peter Geoghegan
• Re: Poor performance using CTE
  • From: Andres Freund
• Re: Poor performance using CTE
  • From: Andrew Dunstan
• Re: Poor performance using CTE
  • From: Tom Lane
• Re: Poor performance using CTE
  • From: Andrew Dunstan
• Re: Hints (was Poor performance using CTE)
  • From: Kevin Grittner
• Re: Hints (was Poor performance using CTE)
  • From: Shaun Thomas
• Re: Poor performance using CTE
  • From: Peter Geoghegan
• Re: Poor performance using CTE
  • From: Heikki Linnakangas
• Re: Hints (was Poor performance using CTE)
  • From: Craig Ringer
• Hints (was Poor performance using CTE)
  • From: Craig James
• Re: Poor performance using CTE
  • From: Tom Lane
• Re: Poor performance using CTE
  • From: Claudio Freire
• Re: Poor performance using CTE
  • From: Craig Ringer
• Re: SOLVED - RE: Poor performance using CTE
  • From: Craig Ringer
• Re: SOLVED - RE: Poor performance using CTE
  • From: Tom Lane
• Re: SOLVED - RE: Poor performance using CTE
  • From: Claudio Freire
• Re: SOLVED - RE: Poor performance using CTE
  • From: Merlin Moncure
• Re: SOLVED - RE: Poor performance using CTE
  • From: Jon Nelson
• Re: SOLVED - RE: Poor performance using CTE
  • From: Claudio Freire
• Re: SOLVED - RE: Poor performance using CTE
  • From: Merlin Moncure
• Poor performance using CTE
  • From: David Greco
• PostgreSQL strange query plan for my query
  • From: David Popiashvili
• Re: Poor performance using CTE
  • From: Claudio Freire
• Re: Poor performance using CTE
  • From: Merlin Moncure
• Re: Poor performance using CTE
  • From: Claudio Freire
• Re: Poor performance using CTE
  • From: Merlin Moncure
• help on slow query using postgres 8.4
  • From: Maria L. Wilson
• Re: PQconnectStart/PQconnectPoll
  • From: Kevin Grittner
• slow query on postgres 8.4
  • From: Maria L. Wilson
• Re: help on slow query using postgres 8.4
  • From: Kevin Grittner
• Re: postgres 8.4, COPY, and high concurrency
  • From: Strange, John W
• Query that uses lots of memory in PostgreSQL 9.2.1 in Windows 7
  • From: Antti Jokipii
• PQconnectStart/PQconnectPoll
  • From: Sergio Mayoral
• FW: slow query on postgres 8.4
  • From: Russell Keane
• Re: SOLVED - RE: Poor performance using CTE
  • From: Gavin Flower
• partitioning versus clustering
  • From: Andrew W. Gibbs
• Re: Query that uses lots of memory in PostgreSQL 9.2.1 in Windows 7
  • From: Pavel Stehule
• Re: PostgreSQL strange query plan for my query
  • From: Craig James
• Re: PostgreSQL strange query plan for my query
  • From: Julien Cigar
• Re: PostgreSQL strange query plan for my query
  • From: David Popiashvili
• Re: intercepting where clause on a view or other performance tweak
  • From: Tom Lane
• Re: intercepting where clause on a view or other performance tweak
  • From: Russell Keane
• Re: intercepting where clause on a view or other performance tweak
  • From: Russell Keane
• Re: intercepting where clause on a view or other performance tweak
  • From: Tom Lane
• intercepting where clause on a view or other performance tweak
  • From: Russell Keane
• Re: PostgreSQL strange query plan for my query
  • From: Julien Cigar
• Re: PostgreSQL strange query plan for my query
  • From: David Popiashvili
• Re: PostgreSQL strange query plan for my query
  • From: Albe Laurenz
• PostgreSQL strange query plan for my query
  • From: David Popiashvili
• Re: performance regression with 9.2
  • From: Tom Lane
• Re: Thousands databases or schemas
  • From: Bruce Momjian
• Re: SOLVED - RE: Poor performance using CTE
  • From: Peter Geoghegan
• Re: SOLVED - RE: Poor performance using CTE
  • From: Andrew Dunstan
• Re: SOLVED - RE: Poor performance using CTE
  • From: Tom Lane
• Re: SOLVED - RE: Poor performance using CTE
  • From: Craig Ringer
• Re: postgres 8.4, COPY, and high concurrency
  • From: Jeff Janes
• Re: Setting Statistics on Functional Indexes
  • From: Tom Lane
• Re: Setting Statistics on Functional Indexes
  • From: Claudio Freire
• Re: Setting Statistics on Functional Indexes
  • From: Robert Haas
• Re: postgres 8.4, COPY, and high concurrency
  • From: Jon Nelson
• Re: postgres 8.4, COPY, and high concurrency
  • From: Jeff Janes
• Re: SOLVED - RE: Poor performance using CTE
  • From: Tom Lane
• SOLVED - RE: Poor performance using CTE
  • From: David Greco
• Re: Poor performance using CTE
  • From: Andrew Dunstan
• Re: Poor performance using CTE
  • From: David Greco
• Re: Poor performance using CTE
  • From: Andrew Dunstan
• Poor performance using CTE
  • From: David Greco
• Re: postgres 8.4, COPY, and high concurrency
  • From: Jon Nelson
• Re: PostreSQL v9.2 uses a lot of memory in Windows XP
  • From: Peter Geoghegan
• Re: PostreSQL v9.2 uses a lot of memory in Windows XP
  • From: Craig Ringer
• Re: PostreSQL v9.2 uses a lot of memory in Windows XP
  • From: Wu Ming
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Andrew Dunstan
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Jeff Janes
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Denis
• Re: postgres 8.4, COPY, and high concurrency
  • From: Jon Nelson
• Re: PostreSQL v9.2 uses a lot of memory in Windows XP
  • From: Craig Ringer
• Re: postgres 8.4, COPY, and high concurrency
  • From: Jeff Janes
• Re: postgres 8.4, COPY, and high concurrency
  • From: Jon Nelson
• Re: postgres 8.4, COPY, and high concurrency
  • From: Jeff Janes
• Re: postgres 8.4, COPY, and high concurrency
  • From: Heikki Linnakangas
• postgres 8.4, COPY, and high concurrency
  • From: Jon Nelson
• Re: Planner sometimes doesn't use a relevant index with IN (subquery) condition
  • From: Gavin Flower
• Re: PostreSQL v9.2 uses a lot of memory in Windows XP
  • From: Craig Ringer
• Re: performance regression with 9.2
  • From: Dave Cramer
• Re: performance regression with 9.2
  • From: Tom Lane
• Re: performance regression with 9.2
  • From: Willem Leenen
• Re: performance regression with 9.2
  • From: Tom Lane
• performance regression with 9.2
  • From: Dave Cramer
• Re: Planner sometimes doesn't use a relevant index with IN (subquery) condition
  • From: Rafał Rzepecki
• Re: fast read of binary data
  • From: Merlin Moncure
• Re: PostreSQL v9.2 uses a lot of memory in Windows XP
  • From: Merlin Moncure
• Re: PostreSQL v9.2 uses a lot of memory in Windows XP
  • From: Albe Laurenz
• PostreSQL v9.2 uses a lot of memory in Windows XP
  • From: Wu Ming
• Re: fast read of binary data
  • From: Arjen van der Meijden
• Re: fast read of binary data
  • From: Albe Laurenz
• fast read of binary data
  • From: Eildert Groeneveld
• Re: Index is not using
  • From: Albe Laurenz
• Re: Index is not using
  • From: K P Manoj
• Re: Index is not using
  • From: Albe Laurenz
• Index is not using
  • From: K P Manoj
• Planner sometimes doesn't use a relevant index with IN (subquery) condition
  • From: Rafał Rzepecki
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: aasat
• parallel query evaluation
  • From: Oliver Seidel
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• Re: parallel query evaluation
  • From: Tom Lane
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Jeff Janes
• Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Andres Freund
• Re: Thousands databases or schemas
  • From: Merlin Moncure
• Re: HT on or off for E5-26xx ?
  • From: David Boreham
• Re: Thousands databases or schemas
  • From: Magnus Hagander
• Re: Thousands databases or schemas
  • From: Craig Ringer
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Alvaro Herrera
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: HT on or off for E5-26xx ?
  • From: David Boreham
• Re: HT on or off for E5-26xx ?
  • From: Shaun Thomas
• Re: Thousands databases or schemas
  • From: Mark Thornton
• Re: Thousands databases or schemas
  • From: Pavel Stehule
• Re: Thousands databases or schemas
  • From: Denis
• Re: Thousands databases or schemas
  • From: Samuel Gendler
• Thousands databases or schemas
  • From: Denis
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Denis
• Re: HT on or off for E5-26xx ?
  • From: David Boreham
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Tom Lane
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Bruce Momjian
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Claudio Freire
• Re: HT on or off for E5-26xx ?
  • From: Mark Kirkwood
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Claudio Freire
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Bruce Momjian
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Tom Lane
• Re: Unique values across a table of arrays - documents and tags
  • From: Florent Guillaume
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Merlin Moncure
• Re: Unique values across a table of arrays - documents and tags
  • From: Ivan Voras
• Re: Unique values across a table of arrays - documents and tags
  • From: Florent Guillaume
• Re: Unique values across a table of arrays - documents and tags
  • From: Ivan Voras
• Re: Unique values across a table of arrays - documents and tags
  • From: François Beausoleil
• Unique values across a table of arrays - documents and tags
  • From: Ivan Voras
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Tom Lane
• Re: HT on or off for E5-26xx ?
  • From: David Boreham
• Re: HT on or off for E5-26xx ?
  • From: Devrim GÜNDÜZ
• Re: HT on or off for E5-26xx ?
  • From: David Boreham
• Re: dbt2 performance regresses from 9.1.6 to 9.2.1
  • From: Heikki Linnakangas
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Denis
• Re: HT on or off for E5-26xx ?
  • From: Mark Kirkwood
• HT on or off for E5-26xx ?
  • From: David Boreham
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Merlin Moncure
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Tom Lane
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Merlin Moncure
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Gunnar "Nick" Bluth
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Gunnar "Nick" Bluth
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Tom Lane
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Gunnar "Nick" Bluth
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Tom Lane
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Gunnar "Nick" Bluth
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Merlin Moncure
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: ktm@xxxxxxxx
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Tom Lane
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Tom Lane
• Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Merlin Moncure
• Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2
  • From: Rodrigo Rosenfeld Rosas
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Denis
• Re: help with too slow query
  • From: Willem Leenen
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Tom Lane
• Re: help with too slow query
  • From: Виктор Егоров
• Re: help with too slow query
  • From: Willem Leenen
• Re: [HACKERS] pg_dump and thousands of schemas
  • From: Denis
• Re: help with too slow query
  • From: Виктор Егоров
• Re: help with too slow query
  • From: Pedro Jiménez Pérez
• Re: How to keep queries low latency as concurrency increases
  • From: Jeff Janes
• Re: How to keep queries low latency as concurrency increases
  • From: Marko Kreen
• Re: How to keep queries low latency as concurrency increases
  • From: Jeff Janes
• Re: How to keep queries low latency as concurrency increases
  • From: Marko Kreen
• Re: How to keep queries low latency as concurrency increases
  • From: Merlin Moncure
• Re: Constraint exclusion in views
  • From: Claudio Freire
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Claudio Freire
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Claudio Freire
• Re: [HACKERS] out of memory
  • From: Robert Haas
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Jeff Janes
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Claudio Freire
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Jeff Janes
• Re: dbt2 performance regresses from 9.1.6 to 9.2.1
  • From: Claudio Freire
• freebsd or linux
  • From: list, mailing
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• help with too slow query
  • From: Pedro Jiménez Pérez
• Re: dbt2 performance regresses from 9.1.6 to 9.2.1
  • From: Dong Ye
• Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• Re: help with too slow query
  • From: Albe Laurenz
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• Re: help with too slow query
  • From: Виктор Егоров
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• DBT-1
  • From: Revagade, Samrat
• DBT-1
  • From: Samrat
• Re: Suggested test points for a performance tool?
  • From: Claudio Freire
• Suggested test points for a performance tool?
  • From: Christoffer Lernö
• Re: Constraint exclusion in views
  • From: Claudio Freire
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Gunnar "Nick" Bluth
• Re: How to keep queries low latency as concurrency increases
  • From: Jeff Janes
• Re: Constraint exclusion in views
  • From: Tom Lane
• Re: Constraint exclusion in views
  • From: Josh Berkus
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Gunnar "Nick" Bluth
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Gunnar "Nick" Bluth
• Constraint exclusion in views
  • From: Claudio Freire
• Re: dbt2 performance regresses from 9.1.6 to 9.2.1
  • From: Ants Aasma
• Re: High %SYS CPU usage
  • From: Cesar Martin
• Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Scott Marlowe
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Gunnar "Nick" Bluth
• Re: pg_buffercache
  • From: Merlin Moncure
• dbt2 performance regresses from 9.1.6 to 9.2.1
  • From: Dong Ye
• pg_buffercache
  • From: pg noob
• Re: Replaying 48 WAL files takes 80 minutes
  • From: Jeff
• Re: Prepared statements slow in 9.2 still (bad query plan)
  • From: Daniel Burbridge
• Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Marcos Ortiz
• Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  • From: Petr Praus
• Re: Replaying 48 WAL files takes 80 minutes
  • From: Jeff Trout
• dbt2 performance regresses from 9.1.6 to 9.2.1
  • From: Dong Ye
• Re: How to keep queries low latency as concurrency increases
  • From: Merlin Moncure
• Re: How to keep queries low latency as concurrency increases
  • From: Jeff Janes
• Re: Slow query, where am I going wrong?
  • From: AndyG
• Re: Slow query, where am I going wrong?
  • From: Albe Laurenz
• Re: Seq scan on big table, episode 2
  • From: Shaun Thomas
• Re: Seq scan on big table, episode 2
  • From: Vincenzo Melandri
• Re: Slow query, where am I going wrong?
  • From: AndyG
• Seq scan on big table, episode 2
  • From: Vincenzo Melandri
• Re: Invalid memory alloc request size
  • From: Samuel Gendler
• Re: Invalid memory alloc request size
  • From: Pavel Stehule
• Invalid memory alloc request size
  • From: Mahavir Trivedi
• Re: Slow query, where am I going wrong?
  • From: AndyG
• Re: Slow query, where am I going wrong?
  • From: Albe Laurenz
• Re: Slow query, where am I going wrong?
  • From: AndyG
• Re: How to keep queries low latency as concurrency increases
  • From: Scott Marlowe
• Re: How to keep queries low latency as concurrency increases
  • From: Greg Williamson
• Re: How to keep queries low latency as concurrency increases
  • From: Jeff Janes
• Re: set-returning calls and overhead
  • From: Jon Nelson
• Re: How to keep queries low latency as concurrency increases
  • From: Kevin Grittner
• Re: High %SYS CPU usage
  • From: Josh Berkus
• Re: Seq scan on 10million record table.. why?
  • From: Vincenzo Melandri
• Re: Slow query, where am I going wrong?
  • From: Albe Laurenz
• Re: PostgreSQL server failed to start
  • From: Maciek Sakrejda
• Re: Slow query, where am I going wrong?
  • From: AndyG
• Re: Seq scan on 10million record table.. why?
  • From: Віталій Тимчишин
• Re: How to keep queries low latency as concurrency increases
  • From: Shaun Thomas
• Re: Seq scan on 10million record table.. why?
  • From: Shaun Thomas
• Re: Seq scan on 10million record table.. why?
  • From: Gabriele Bartolini
• Re: Replaying 48 WAL files takes 80 minutes
  • From: ktm@xxxxxxxx
• Re: Replaying 48 WAL files takes 80 minutes
  • From: Albe Laurenz
• Re: Replaying 48 WAL files takes 80 minutes
  • From: Albe Laurenz
• Re: Replaying 48 WAL files takes 80 minutes
  • From: ktm@xxxxxxxx
• High %SYS CPU usage
  • From: Cesar Martin
• Seq scan on 10million record table.. why?
  • From: Vincenzo Melandri
• Re: How to keep queries low latency as concurrency increases
  • From: Kevin Grittner
• Re: out of memory
  • From: Tatsuo Ishii
• Re: Replaying 48 WAL files takes 80 minutes
  • From: Heikki Linnakangas
• Re: Slow query, where am I going wrong?
  • From: AndyG
• PostgreSQL server failed to start
  • From: vignesh
• out of memory
  • From: Mahavir Trivedi
• Re: Request for help with slow query
  • From: Albe Laurenz
• Re: Replaying 48 WAL files takes 80 minutes
  • From: Albe Laurenz
• Re: Slow query, where am I going wrong?
  • From: Albe Laurenz
• Slow query, where am I going wrong?
  • From: Andy
• How to keep queries low latency as concurrency increases
  • From: Catalin Iacob
• Re: Slower Performance on Postgres 9.1.6 vs 8.2.11
  • From: robcron
• Re: Request for help with slow query
  • From: Kevin Grittner
• Re: Request for help with slow query
  • From: Woolcock, Sean
• Re: Request for help with slow query
  • From: salah jubeh
• Re: Request for help with slow query
  • From: Shaun Thomas
• Re: Request for help with slow query
  • From: Joshua D. Drake
• Re: Request for help with slow query
  • From: Woolcock, Sean
• Re: Setting Statistics on Functional Indexes
  • From: Kevin Grittner
• Re: Request for help with slow query
  • From: salah jubeh
• Request for help with slow query
  • From: Woolcock, Sean
• Re: Replaying 48 WAL files takes 80 minutes
  • From: Jeff Janes
• Re: Tons of free RAM. Can't make it go away.
  • From: Shaun Thomas
• Re: Setting Statistics on Functional Indexes
  • From: Shaun Thomas
• Re: Replaying 48 WAL files takes 80 minutes
  • From: Albe Laurenz
• Re: Replaying 48 WAL files takes 80 minutes
  • From: Alvaro Herrera
• Re: Prepared statements slow in 9.2 still (bad query plan)
  • From: Shaun Thomas
• Re: Replaying 48 WAL files takes 80 minutes
  • From: ktm@xxxxxxxx
• Replaying 48 WAL files takes 80 minutes
  • From: Albe Laurenz
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Matheus de Oliveira
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Claudio Freire
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Matheus de Oliveira
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Claudio Freire
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Matheus de Oliveira
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Claudio Freire
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Karl Denninger
• Re: Prepared statements slow in 9.2 still (bad query plan)
  • From: Tom Lane
• Prepared statements slow in 9.2 still (bad query plan)
  • From: Daniel Burbridge
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: delongboy
• Re: Tons of free RAM. Can't make it go away.
  • From: Віталій Тимчишин
• Re: Slower Performance on Postgres 9.1.6 vs 8.2.11
  • From: Pavel Stehule
• Re: Setting Statistics on Functional Indexes
  • From: Claudio Freire
• Re: Setting Statistics on Functional Indexes
  • From: Claudio Freire
• Re: Setting Statistics on Functional Indexes
  • From: Tom Lane
• Re: Setting Statistics on Functional Indexes
  • From: Claudio Freire
• Re: Setting Statistics on Functional Indexes
  • From: Tom Lane
• Re: Slower Performance on Postgres 9.1.6 vs 8.2.11
  • From: robcron
• Re: Slower Performance on Postgres 9.1.6 vs 8.2.11
  • From: robcron
• Re: Query-Planer from 6seconds TO DAYS
  • From: Jeff Janes
• Re: Slower Performance on Postgres 9.1.6 vs 8.2.11
  • From: Tom Lane
• Re: Setting Statistics on Functional Indexes
  • From: Shaun Thomas
• Re: Setting Statistics on Functional Indexes
  • From: Tom Lane
• Slower Performance on Postgres 9.1.6 vs 8.2.11
  • From: robcron
• Re: Query-Planer from 6seconds TO DAYS
  • From: Böckler Andreas
• Re: Query-Planer from 6seconds TO DAYS
  • From: Jeff Janes
• PSA: New Kernels and intel_idle cpuidle Driver!
  • From: Shaun Thomas
• Re: Query-Planer from 6seconds TO DAYS
  • From: Jeff Janes
• Re: Query-Planer from 6seconds TO DAYS
  • From: Kevin Grittner
• Re: Query-Planer from 6seconds TO DAYS
  • From: Kevin Grittner
• Re: Query-Planer from 6seconds TO DAYS
  • From: Kevin Grittner
• Re: Query-Planer from 6seconds TO DAYS
  • From: Böckler Andreas
• Re: Query-Planer from 6seconds TO DAYS
  • From: ktm@xxxxxxxx
• BAD performance with enable_bitmapscan = on with Postgresql 9.0.X (X = 3 and 10)
  • From: Alberto Marchesini
• Re: Query-Planer from 6seconds TO DAYS
  • From: Böckler Andreas
• Re: Query-Planer from 6seconds TO DAYS
  • From: ktm@xxxxxxxx
• Re: Query-Planer from 6seconds TO DAYS
  • From: Böckler Andreas
• Re: Query-Planer from 6seconds TO DAYS
  • From: Kevin Grittner
• Re: Query-Planer from 6seconds TO DAYS
  • From: Jeff Janes
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Claudio Freire
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Shaun Thomas
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Kevin Grittner
• Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
  • From: Kevin Grittner
• Re: Setting Statistics on Functional Indexes
  • From: Shaun Thomas
• Re: Setting Statistics on Functional Indexes
  • From: Shaun Thomas
• Re: Setting Statistics on Functional Indexes
  • From: Tom Lane
• Re: Query-Planer from 6seconds TO DAYS
  • From: Böckler Andreas
• Setting Statistics on Functional Indexes
  • From: Shaun Thomas
• Query-Planer from 6seconds TO DAYS
  • From: Böckler Andreas
• Re: Query with limit goes from few ms to hours
  • From: Steve Crawford
• Re: Query with limit goes from few ms to hours
  • From: Kevin Grittner
• Re: Tons of free RAM. Can't make it go away.
  • From: Shaun Thomas
• Re: Tons of free RAM. Can't make it go away.
  • From: Claudio Freire
• Re: Tons of free RAM. Can't make it go away.
  • From: Shaun Thomas
• Re: Tons of free RAM. Can't make it go away.
  • From: Shaun Thomas
• Re: Tons of free RAM. Can't make it go away.
  • From: Shaun Thomas
• Re: Tons of free RAM. Can't make it go away.
  • From: Franklin, Dan (FEN)
• Re: Tons of free RAM. Can't make it go away.
  • From: Shaun Thomas
• Re: Tons of free RAM. Can't make it go away.
  • From: Claudio Freire
• Re: Tons of free RAM. Can't make it go away.
  • From: Marcus Larsson
• Re: Tons of free RAM. Can't make it go away.
  • From: Claudio Freire
• Re: Tons of free RAM. Can't make it go away.
  • From: Frank Lanitz
• Re: Tons of free RAM. Can't make it go away.
  • From: Claudio Freire
• Tons of free RAM. Can't make it go away.
  • From: Shaun Thomas
• Re: Connection Options -- SSL already uses compression?
  • From: Magnus Hagander
• Connection Options -- SSL already uses compression?
  • From: Karl Denninger
• How to upgrade from 9.1 to 9.2 with replication?
  • From: delongboy
• Re: Recursive query gets slower when adding an index
  • From: Thomas Kellerer
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Shaun Thomas
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Shaun Thomas
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Karl Denninger
• Re: Tablespace-derived stats?
  • From: Shaun Thomas
• Re: limit order by performance issue
  • From: Claudio Freire
• Re: Tablespace-derived stats?
  • From: Shaun Thomas
• Re: Tablespace-derived stats?
  • From: Tom Lane
• Re: Tablespace-derived stats?
  • From: Jeff Janes
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Karl Denninger
• Re: Tablespace-derived stats?
  • From: Jeff Janes
• Tablespace-derived stats?
  • From: Shaun Thomas
• Re: How to upgrade from 9.1 to 9.2 with replication?
  • From: Claudio Freire
• Re: limit order by performance issue
  • From: Pedro Jiménez Pérez
• Re: Recursive query gets slower when adding an index
  • From: Tom Lane
• Re: SELECT AND AGG huge tables
  • From: Ants Aasma
• Recursive query gets slower when adding an index
  • From: Thomas Kellerer
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Scott Marlowe
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Claudio Freire
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Jeff Janes
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Jeff Janes
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Jeff Janes
• Re: Unused index influencing sequential scan plan
  • From: Thom Brown
• Re: Unused index influencing sequential scan plan
  • From: Tom Lane
• Re: Unused index influencing sequential scan plan
  • From: Peter Geoghegan
• Re: Unused index influencing sequential scan plan
  • From: Thom Brown
• Re: Unused index influencing sequential scan plan
  • From: Tom Lane
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Unused index influencing sequential scan plan
  • From: Thom Brown
• Re: Unused index influencing sequential scan plan
  • From: Thom Brown
• Re: Unused index influencing sequential scan plan
  • From: Tom Lane
• Re: Unused index influencing sequential scan plan
  • From: Peter Geoghegan
• Re: Unused index influencing sequential scan plan
  • From: Thom Brown
• Unused index influencing sequential scan plan
  • From: Thom Brown
• Re: Two identical systems, radically different performance
  • From: Andrea Suisani
• Re: LIKE op with B-Tree Index?
  • From: Albe Laurenz
• Re: LIKE op with B-Tree Index?
  • From: Sam Wong
• Re: LIKE op with B-Tree Index?
  • From: Merlin Moncure
• Re: Two identical systems, radically different performance
  • From: Scott Marlowe
• Re: Two identical systems, radically different performance
  • From: Andrea Suisani
• Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
  • From: Maciek Sakrejda
• Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
  • From: Tom Lane
• High cost estimates when n_distinct is set
  • From: Niko Kiirala
• Re: SELECT AND AGG huge tables
  • From: houmanb
• Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
  • From: Martin French
• Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
  • From: Maciek Sakrejda
• Re: have: seq scan - want: index scan
  • From: Samuel Gendler
• Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
  • From: Martin French
• Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6
  • From: Maciek Sakrejda
• have: seq scan - want: index scan
  • From: Chris Ruprecht
• pgbounce max_client_conn and default_pool_size
  • From: Yetkin Öztürk
• Re: Slow Delete : Seq scan instead of index scan
  • From: Craig Ringer
• Re: LIKE op with B-Tree Index?
  • From: Sam Wong
• Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong?
  • From: Chris Ruprecht
• Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong?
  • From: Bruce Momjian
• Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong?
  • From: Chris Ruprecht
• Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong?
  • From: Evgeny Shishkin
• Have: Seq Scan - Want: Index Scan - what am I doing wrong?
  • From: Chris Ruprecht
• Re: limit order by performance issue
  • From: Marti Raudsepp
• Re: LIKE op with B-Tree Index?
  • From: Merlin Moncure
• LIKE op with B-Tree Index?
  • From: Sam Wong
• Re: limit order by performance issue
  • From: Karl Denninger
• Re: limit order by performance issue
  • From: Pavel Stehule
• Re: limit order by performance issue
  • From: Shaun Thomas
• limit order by performance issue
  • From: Pedro Jiménez
• Re: Guide to Posting Slow Query Questions
  • From: Jeff Janes
• Re: Support Create package
  • From: ktm@xxxxxxxx
• Re: Support Create package
  • From: Pavel Stehule
• Support Create package
  • From: Alejandro Carrillo
• LIKE op with B-Tree Index?
  • From: Sam Wong
• Re: Slow Delete : Seq scan instead of index scan
  • From: Filippos Kalamidas
• Slow Delete : Seq scan instead of index scan
  • From: Sylvain CAILLET
• Re: Slow Delete : Seq scan instead of index scan
  • From: Sylvain CAILLET
• Re: Slow Delete : Seq scan instead of index scan
  • From: Sylvain CAILLET
• Re: Slow Delete : Seq scan instead of index scan
  • From: Craig Ringer
• Re: Slow Delete : Seq scan instead of index scan
  • From: Sékine Coulibaly
• Re: Two identical systems, radically different performance
  • From: Marinos Yannikos
• Re: SELECT AND AGG huge tables
  • From: Craig Ringer
• Re: SELECT AND AGG huge tables
  • From: Jeff Janes
• Re: SELECT AND AGG huge tables
  • From: Bob Lunney
• Re: SELECT AND AGG huge tables
  • From: Ondrej Ivanič
• Re: SELECT AND AGG huge tables
  • From: Matheus de Oliveira
• Re: SELECT AND AGG huge tables
  • From: Merlin Moncure
• SELECT AND AGG huge tables
  • From: houmanb
• Re: Query with limit goes from few ms to hours
  • From: henk de wit
• Re: Two identical systems, radically different performance
  • From: Andrea Suisani
• Re: Two identical systems, radically different performance
  • From: Andrea Suisani
• Re: Two identical systems, radically different performance
  • From: Andrea Suisani
• Re: Two identical systems, radically different performance
  • From: Claudio Freire
• Re: Two identical systems, radically different performance
  • From: Scott Marlowe
• Re: Two identical systems, radically different performance
  • From: Claudio Freire
• Re: Two identical systems, radically different performance
  • From: Scott Marlowe
• Re: Two identical systems, radically different performance
  • From: Andrea Suisani
• Re: Two identical systems, radically different performance
  • From: Craig James
• Re: Query with limit goes from few ms to hours
  • From: Robert Klemme
• Re: problems with large objects dump
  • From: Sergio Gabriel Rodriguez
• WebSphere Application Server support for postgres
  • From: John Nash
• Re: Two identical systems, radically different performance
  • From: Andrea Suisani
• Re: Query with limit goes from few ms to hours
  • From: Tom Lane
• Re: Index over all partitions (aka global index)?
  • From: Stefan Keller
• Re: Query with limit goes from few ms to hours
  • From: henk de wit
• Query with limit goes from few ms to hours
  • From: henk de wit
• Re: Index over all partitions (aka global index)?
  • From: Jeff Janes
• Index over all partitions (aka global index)?
  • From: Stefan Keller
• Re: Do cast affects index usage?
  • From: Tom Lane
• Re: problems with large objects dump
  • From: Tom Lane
• Re: Do cast affects index usage?
  • From: Anibal David Acosta
• Re: problems with large objects dump
  • From: Tom Lane
• Re: problems with large objects dump
  • From: Sergio Gabriel Rodriguez
• Re: hash aggregation
  • From: Tomas Vondra
• Re: hash aggregation
  • From: Tomas Vondra
• Re: Do cast affects index usage?
  • From: Scott Marlowe
• Re: Do cast affects index usage?
  • From: Tom Lane
• Do cast affects index usage?
  • From: Anibal David Acosta
• Re: hash aggregation
  • From: Korisk
• Re: hash aggregation
  • From: Sergey Konoplev
• Re: hash aggregation
  • From: Ondrej Ivanič
• Re: hash aggregation
  • From: Korisk
• Re: hash aggregation
  • From: Sergey Konoplev
• Re: hash aggregation
  • From: Korisk
• Re: problems with large objects dump
  • From: Marcos Ortiz
• Re: Drawbacks of create index where is not null ?
  • From: Sergey Konoplev
• Re: problems with large objects dump
  • From: Tom Lane
• Re: problems with large objects dump
  • From: Sergio Gabriel Rodriguez
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Josh Berkus
• Re: hash aggregation
  • From: Sergey Konoplev
• Re: hash aggregation
  • From: Korisk
• Re: Two identical systems, radically different performance
  • From: Andrea Suisani
• Re: Two identical systems, radically different performance
  • From: Claudio Freire
• Re: Two identical systems, radically different performance
  • From: Andrea Suisani
• Re: Drawbacks of create index where is not null ?
  • From: Franck Routier
• Re: hash aggregation
  • From: Sergey Konoplev
• Re: Drawbacks of create index where is not null ?
  • From: Scott Marlowe
• Re: Drawbacks of create index where is not null ?
  • From: Scott Marlowe
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Scott Marlowe
• Re: Drawbacks of create index where is not null ?
  • From: Craig Ringer
• Re: hash aggregation
  • From: Craig Ringer
• Re: hash aggregation
  • From: Korisk
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Claudio Freire
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Jeff Janes
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Claudio Freire
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Ondrej Ivanič
• Re: hash aggregation
  • From: Sergey Konoplev
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Bruce Momjian
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Claudio Freire
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Strahinja Kustudić
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Jeff Janes
• Re: Ways to speed up ts_rank
  • From: Shane Hathaway
• Re: Ways to speed up ts_rank
  • From: Shane Hathaway
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Claudio Freire
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Shaun Thomas
• Re: Hyperthreading (was: Two identical systems, radically different performance)
  • From: Claudio Freire
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Bruce Momjian
• Re: Hyperthreading (was: Two identical systems, radically different performance)
  • From: Craig James
• Drawbacks of create index where is not null ?
  • From: Franck Routier
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Claudio Freire
• hash aggregation
  • From: Korisk
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Bruce Momjian
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Bruce Momjian
• Re: Hyperthreading (was: Two identical systems, radically different performance)
  • From: Bruce Momjian
• Re: Hyperthreading (was: Two identical systems, radically different performance)
  • From: Claudio Freire
• Re: Ways to speed up ts_rank
  • From: Oleg Bartunov
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Strahinja Kustudić
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Shaun Thomas
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Strahinja Kustudić
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Shaun Thomas
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Shaun Thomas
• Re: Hyperthreading (was: Two identical systems, radically different performance)
  • From: Shaun Thomas
• Re: Ways to speed up ts_rank
  • From: François Beausoleil
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Strahinja Kustudić
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Julien Cigar
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Strahinja Kustudić
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Julien Cigar
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Tomas Vondra
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Albe Laurenz
• Re: shared_buffers/effective_cache_size on 96GB server
  • From: Strahinja Kustudić
• shared_buffers/effective_cache_size on 96GB server
  • From: Strahinja Kustudić
• Re: Why am I getting great/terrible estimates with these CTE queries?
  • From: Tomas Vondra
• Re: Hyperthreading (was: Two identical systems, radically different performance)
  • From: Craig James
• Re: Why am I getting great/terrible estimates with these CTE queries?
  • From: Tom Lane
• Ways to speed up ts_rank
  • From: Shane Hathaway
• Why am I getting great/terrible estimates with these CTE queries?
  • From: Tomas Vondra
• Re: Two identical systems, radically different performance
  • From: Ants Aasma
• Re: Hyperthreading (was: Two identical systems, radically different performance)
  • From: Shaun Thomas
• Re: Scaling 10 million records in PostgreSQL table
  • From: Daniel Farina
• Re: Scaling 10 million records in PostgreSQL table
  • From: Samuel Gendler
• Re: Scaling 10 million records in PostgreSQL table
  • From: Navaneethan R
• Re: Two identical systems, radically different performance
  • From: Gavin Flower
• 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