Postgres Performance Date Index

• Thread Index

• Re: What happens between end of explain analyze and end of query execution ?
  • From: nik9000
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Tom Lane
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Nikolas Everett
• What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: Postgres upgrade, security release, where?
  • From: Ian Lawrence Barwick
• Re: Postgres upgrade, security release, where?
  • From: Mark Kirkwood
• Re: Planner is getting wrong row count
  • From: Kevin Grittner
• Re: Join between 2 tables always executes a sequential scan on the larger table
  • From: Vasilis Ventirozos
• Re: Join between 2 tables always executes a sequential scan on the larger table
  • From: Dieter Rehbein
• Re: Join between 2 tables always executes a sequential scan on the larger table
  • From: Dieter Rehbein
• Planner is getting wrong row count
  • From: AI Rumman
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Re: Join between 2 tables always executes a sequential scan on the larger table
  • From: Tom Lane
• Re: Join between 2 tables always executes a sequential scan on the larger table
  • From: Igor Neyman
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Join between 2 tables always executes a sequential scan on the larger table
  • From: Dieter Rehbein
• Re: Postgres upgrade, security release, where?
  • From: Mark Kirkwood
• Re: Postgres upgrade, security release, where?
  • From: Dave Page
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Problems with pg_locks explosion
  • From: Mark Kirkwood
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Problems with pg_locks explosion
  • From: Mark Kirkwood
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Problems with pg_locks explosion
  • From: Jeff Janes
• Re: Problems with pg_locks explosion
  • From: Jeff Janes
• Re: Postgres upgrade, security release, where?
  • From: Mark Kirkwood
• Re: Fwd: Problems with pg_locks explosion
  • From: Mark Kirkwood
• Re: Postgres upgrade, security release, where?
  • From: Tory M Blue
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Problems with pg_locks explosion
  • From: Steven Crandell
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Postgres upgrade, security release, where?
  • From: Bruce Momjian
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Postgres upgrade, security release, where?
  • From: Ian Lawrence Barwick
• Fwd: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Postgres upgrade, security release, where?
  • From: Bruce Momjian
• Re: Problems with pg_locks explosion
  • From: Jeff Janes
• Re: Problems with pg_locks explosion
  • From: Mark Kirkwood
• Postgres upgrade, security release, where?
  • From: Tory M Blue
• Re: Problems with pg_locks explosion
  • From: Vasilis Ventirozos
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Fwd: Problems with pg_locks explosion
  • From: Vasilis Ventirozos
• Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Question about postmaster's CPU usage
  • From: Merlin Moncure
• Re: query plan estimate
  • From: Tom Lane
• query plan estimate
  • From: pg noob
• Re: 9.2.3 upgrade reduced pgbench performance by 60%
  • From: Jeff Janes
• Re: Question about postmaster's CPU usage
  • From: Kelphet Xiong
• Re: Question about postmaster's CPU usage
  • From: Ants Aasma
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Jeff Janes
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Cédric Villemain
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Guillaume Cottenceau
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Jeff Janes
• Re: how to help the planner
  • From: Igor Neyman
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Franck Routier
• Re: [OT] linux 3.10 kernel will improve ipc,sysv semaphore scalability
  • From: Andrea Suisani
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Guillaume Cottenceau
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Julien Cigar
• Postgresql performance degrading... how to diagnose the root cause
  • From: Franck Routier
• Re: how to help the planner
  • From: Stephen Frost
• Re: Question about postmaster's CPU usage
  • From: ktm@xxxxxxxx
• Re: Question about postmaster's CPU usage
  • From: Kevin Grittner
• Re: how to help the planner
  • From: Marty Frasier
• Question about postmaster's CPU usage
  • From: kelphet xiong
• Re: how to help the planner
  • From: Tom Lane
• how to help the planner
  • From: Marty Frasier
• Re: 9.2.3 upgrade reduced pgbench performance by 60%
  • From: Josh Berkus
• Re: Reg: Slow query
  • From: Vasilis Ventirozos
• Reg: Slow query
  • From: Prakash Chinnakannan
• 9.2.3 upgrade reduced pgbench performance by 60%
  • From: Colin Currie
• Re: Performance of query
  • From: Jeff Janes
• Re: Performance of query
  • From: Cindy Makarowsky
• Proof of concept: Evolving postgresql.conf using genetic algorithm
  • From: Greg Jaskiewicz
• Setting vacuum_freeze_min_age really low
  • From: Josh Berkus
• Re: 9.2.3 upgrade reduced pgbench performance by 60%
  • From: Josh Berkus
• [OT] linux 3.10 kernel will improve ipc,sysv semaphore scalability
  • From: Andrea Suisani
• Re: [OT] linux 3.10 kernel will improve ipc,sysv semaphore scalability
  • From: Shaun Thomas
• Re: 9.2.3 upgrade reduced pgbench performance by 60%
  • From: Nicholson, Brad (Toronto, ON, CA)
• Re: Performance of query
  • From: Roman Konoval
• PostgreSQL planner
  • From: Misa Simic
• Re: Performance of query
  • From: Misa Simic
• Re: Performance of query
  • From: Jeff Janes
• Re: Index usage for tstzrange?
  • From: Tom Lane
• Re: Index usage for tstzrange?
  • From: Josh Berkus
• Performance of query
  • From: Cindy Makarowsky
• Re: Performance of query
  • From: Josh Berkus
• Re: Index usage for tstzrange?
  • From: Heikki Linnakangas
• Re: Performance of query
  • From: Cindy Makarowsky
• Re: Performance of query
  • From: Misa Simic
• Re: Performance of query
  • From: Cindy Makarowsky
• Re: Index usage for tstzrange?
  • From: Heikki Linnakangas
• Re: Index usage for tstzrange?
  • From: Josh Berkus
• Re: Index usage for tstzrange?
  • From: Heikki Linnakangas
• Re: Index usage for tstzrange?
  • From: Vasilis Ventirozos
• Re: Index usage for tstzrange?
  • From: Tom Lane
• Re: New server setup
  • From: Mark Kirkwood
• Re: New server setup
  • From: Scott Marlowe
• Re: New server setup
  • From: Karl Denninger
• Re: New server setup
  • From: David Boreham
• Re: New server setup
  • From: David Rees
• Index usage for tstzrange?
  • From: Josh Berkus
• Re: effective_cache_size on 32-bits postgres
  • From: Rodrigo Barboza
• Re: effective_cache_size on 32-bits postgres
  • From: Pavel Stehule
• Re: effective_cache_size on 32-bits postgres
  • From: Claudio Freire
• Re: effective_cache_size on 32-bits postgres
  • From: Kevin Grittner
• Re: effective_cache_size on 32-bits postgres
  • From: Pavel Stehule
• Re: effective_cache_size on 32-bits postgres
  • From: Rodrigo Barboza
• Re: effective_cache_size on 32-bits postgres
  • From: Pavel Stehule
• Re: effective_cache_size on 32-bits postgres
  • From: Rodrigo Barboza
• Re: effective_cache_size on 32-bits postgres
  • From: Pavel Stehule
• Re: effective_cache_size on 32-bits postgres
  • From: Rob Wultsch
• effective_cache_size on 32-bits postgres
  • From: Rodrigo Barboza
• Re: Why is my pg_xlog directory so huge?
  • From: Niels Kristian Schjødt
• Re: Why is my pg_xlog directory so huge?
  • From: Magnus Hagander
• Re: Why is my pg_xlog directory so huge?
  • From: Niels Kristian Schjødt
• Re: Why is my pg_xlog directory so huge?
  • From: Magnus Hagander
• Why is my pg_xlog directory so huge?
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Mark Kirkwood
• Re: New server setup
  • From: Scott Marlowe
• Re: New server setup
  • From: Bruce Momjian
• Re: Pre-sorting COPY FROM input
  • From: Heikki Linnakangas
• Re: New server setup
  • From: Rick Otten
• Pre-sorting COPY FROM input
  • From: Florian Weimer
• Re: Join the master table with other table is very slow (partitioning)
  • From: Ao Jianwang
• Re: Join the master table with other table is very slow (partitioning)
  • From: Tom Lane
• Re: Join the master table with other table is very slow (partitioning)
  • From: Ao Jianwang
• Re: Join the master table with other table is very slow (partitioning)
  • From: Ao Jianwang
• Re: Join the master table with other table is very slow (partitioning)
  • From: AI Rumman
• Re: Join the master table with other table is very slow (partitioning)
  • From: Ao Jianwang
• Join the master table with other table is very slow (partitioning)
  • From: Ao Jianwang
• Re: New server setup
  • From: David Boreham
• Re: New server setup
  • From: Mark Kirkwood
• Re: New server setup
  • From: Bruce Momjian
• Re: New server setup
  • From: Mark Kirkwood
• Re: New server setup
  • From: Mark Kirkwood
• Re: Speed of EXCECUTE in PL/PGSQL
  • From: Andrew Dunstan
• Re: Speed of EXCECUTE in PL/PGSQL
  • From: Merlin Moncure
• Speed of EXCECUTE in PL/PGSQL
  • From: Artur Zając
• Re: New server setup
  • From: Bruce Momjian
• Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Emre Hasegeli
• PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Jeff Janes
• Re: New server setup
  • From: David Boreham
• Re: New server setup
  • From: Mark Kirkwood
• Re: Risk of data corruption/loss?
  • From: Joshua Berkus
• Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Joshua Berkus
• Re: New server setup
  • From: David Boreham
• Re: New server setup
  • From: John Lister
• Re: New server setup
  • From: CSS
• Re: New server setup
  • From: Karl Denninger
• Re: Setup of four 15k SAS disk with LSI raid controller
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Steve Crawford
• Re: Setup of four 15k SAS disk with LSI raid controller
  • From: Joshua D. Drake
• Re: Setup of four 15k SAS disk with LSI raid controller
  • From: Vasilis Ventirozos
• Re: Setup of four 15k SAS disk with LSI raid controller
  • From: Niels Kristian Schjødt
• Re: Setup of four 15k SAS disk with LSI raid controller
  • From: Vasilis Ventirozos
• Setup of four 15k SAS disk with LSI raid controller
  • From: Niels Kristian Schjødt
• Re: Risk of data corruption/loss?
  • From: Niels Kristian Schjødt
• Re: Risk of data corruption/loss?
  • From: Jeff Janes
• Re: New server setup
  • From: John Lister
• Re: New server setup
  • From: Greg Jaskiewicz
• Re: New server setup
  • From: John Lister
• Risk of data corruption/loss?
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Gregg Jaskiewicz
• Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Emre Hasegeli
• Re: Slow concurrent processing
  • From: Misa Simic
• Re: Slow concurrent processing
  • From: Misa Simic
• Re: Slow concurrent processing
  • From: Jeff Janes
• Re: Slow concurrent processing
  • From: Steve Crawford
• Re: Slow concurrent processing
  • From: Misa Simic
• Re: Slow concurrent processing
  • From: Steve Crawford
• Re: Slow concurrent processing
  • From: Misa Simic
• Re: Slow query when used in a view
  • From: Shaun Thomas
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Victor Yegorov
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Jeff Adams - NOAA Affiliate
• Slow concurrent processing
  • From: Misa Simic
• Re: Slow query when used in a view
  • From: Tom Lane
• Slow query when used in a view
  • From: Shaun Thomas
• The dreaded semwait on FreeBSD
  • From: Benjamin Krajmalnik
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Jeff Adams - NOAA Affiliate
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Pavel Stehule
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Jeff Adams - NOAA Affiliate
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Pavel Stehule
• Re: sniff test on some PG 8.4 numbers
  • From: Jon Nelson
• Large Table - Slow Window Functions (Better Approach?)
  • From: Jeff Adams - NOAA Affiliate
• Re: sniff test on some PG 8.4 numbers
  • From: Greg Smith
• Re: sniff test on some PG 8.4 numbers
  • From: Scott Marlowe
• Re: sniff test on some PG 8.4 numbers
  • From: Jon Nelson
• Re: New server setup
  • From: Greg Smith
• Re: sniff test on some PG 8.4 numbers
  • From: Greg Smith
• Re: New server setup
  • From: Gregg Jaskiewicz
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Emre Hasegeli
• Re: Poor plan when joining against a union containing a join
  • From: David Leverton
• PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Emre Hasegeli
• Re: Anyone running Intel S3700 SSDs?
  • From: Yeb Havinga
• Anyone running Intel S3700 SSDs?
  • From: CSS
• Re: Poor plan when joining against a union containing a join
  • From: Tom Lane
• Re: Poor plan when joining against a union containing a join
  • From: David Leverton
• Re: Poor plan when joining against a union containing a join
  • From: Tom Lane
• Re: Poor plan when joining against a union containing a join
  • From: Josh Berkus
• Re: Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Jeff Janes
• Poor plan when joining against a union containing a join
  • From: David Leverton
• Re: Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Julien Cigar
• Re: sniff test on some PG 8.4 numbers
  • From: Jon Nelson
• Re: sniff test on some PG 8.4 numbers
  • From: Jon Nelson
• Re: sniff test on some PG 8.4 numbers
  • From: Josh Berkus
• Re: Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Joshua D. Drake
• Re: Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Jeff Janes
• Re: Are bitmap index scans slow to start?
  • From: Jeff Janes
• sniff test on some PG 8.4 numbers
  • From: Jon Nelson
• Re: New server setup
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Benjamin Krajmalnik
• Re: Are bitmap index scans slow to start?
  • From: Jeff Janes
• Re: New server setup
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Scott Marlowe
• Re: New server setup
  • From: Kevin Grittner
• Re: Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Julien Cigar
• Re: Poor performance after update from SLES11 SP1 to SP2
  • From: Mark Smith
• Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Niels Kristian Schjødt
• Re: hardware upgrade, performance degrade?
  • From: Steven Crandell
• Re: hardware upgrade, performance degrade?
  • From: Scott Marlowe
• Re: hardware upgrade, performance degrade?
  • From: Steven Crandell
• Re: hardware upgrade, performance degrade?
  • From: Scott Marlowe
• Re: hardware upgrade, performance degrade?
  • From: John Rouillard
• Re: hardware upgrade, performance degrade?
  • From: Sergey Konoplev
• Re: hardware upgrade, performance degrade?
  • From: Mark Kirkwood
• Re: hardware upgrade, performance degrade?
  • From: Steven Crandell
• Re: pgbench intriguing results: better tps figures for larger scale factor
  • From: Greg Smith
• Re: Schema obfuscator for performance question
  • From: Claudio Freire
• Re: Schema obfuscator for performance question
  • From: Victor Yegorov
• Schema obfuscator for performance question
  • From: Joseph Pravato
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: Niels Kristian Schjødt
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: Scott Marlowe
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: AJ Weber
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: Scott Marlowe
• Re: pgbench intriguing results: better tps figures for larger scale factor
  • From: Merlin Moncure
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: Richard Neill
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: AJ Weber
• What setup would you choose for postgresql 9.2 installation?
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Niels Kristian Schjødt
• Re: hardware upgrade, performance degrade?
  • From: Jean-David Beyer
• Re: hardware upgrade, performance degrade?
  • From: Josh Berkus
• Re: hardware upgrade, performance degrade?
  • From: Jesper Krogh
• Re: hardware upgrade, performance degrade?
  • From: Scott Marlowe
• Re: New server setup
  • From: Wales Wang
• Re: hardware upgrade, performance degrade?
  • From: Steven Crandell
• Re: hardware upgrade, performance degrade?
  • From: Craig James
• Re: New server setup
  • From: Craig James
• Re: xmlconcat performance
  • From: Merlin Moncure
• New server setup
  • From: Niels Kristian Schjødt
• Re: hardware upgrade, performance degrade?
  • From: Guillaume Smet
• hardware upgrade, performance degrade?
  • From: Steven Crandell
• Processing of subqueries in union
  • From: Markus Hervén
• Re: SELECT is slow on smaller table?
  • From: Ao Jianwang
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Wrong actual number of rows in the Query Plan
  • From: Tom Lane
• Re: xmlconcat performance
  • From: Merlin Moncure
• Re: pgbench intriguing results: better tps figures for larger scale factor
  • From: Pavan Deolasee
• xmlconcat performance
  • From: Davide Berra
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Glyn Astill
• Re: Are bitmap index scans slow to start?
  • From: Marc Mamin
• Bad query plan with high-cardinality column
  • From: Alexander Staubo
• Re: Are bitmap index scans slow to start?
  • From: Gavin Flower
• Using a window function in a view
  • From: Chris Hanks
• pgbench intriguing results: better tps figures for larger scale factor
  • From: Costin Oproiu
• Wrong actual number of rows in the Query Plan
  • From: Vahe Evoyan
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Scott Marlowe
• Re: Estimation question...
  • From: Matt Daw
• Re: SELECT is slow on smaller table?
  • From: Julien Cigar
• SELECT is slow on smaller table?
  • From: Ao Jianwang
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Server stalls, all CPU 100% system time
  • From: Josh Berkus
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Are bitmap index scans slow to start?
  • From: Jeff Janes
• Re: Estimation question...
  • From: Matt Daw
• Re: seqscan on UNION'ed views
  • From: Tom Lane
• Re: Server stalls, all CPU 100% system time
  • From: Andre
• seqscan on UNION'ed views
  • From: Dmitry Karasik
• Re: Server stalls, all CPU 100% system time
  • From: Scott Marlowe
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Server stalls, all CPU 100% system time
  • From: Josh Berkus
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Scott Marlowe
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Jeff Janes
• Estimation question...
  • From: Matt Daw
• Re: Are bitmap index scans slow to start?
  • From: Jeff Janes
• Re: Server stalls, all CPU 100% system time
  • From: Andre
• Re: Very slow update statement on 40mio rows
  • From: Florian Schröck
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Jeff Frost
• Re: Avoiding Recheck Cond when using Select Distinct
  • From: Jeff Janes
• Re: Avoiding Recheck Cond when using Select Distinct
  • From: Maciek Sakrejda
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Server stalls, all CPU 100% system time
  • From: Scott Marlowe
• Re: Server stalls, all CPU 100% system time
  • From: Tom Lane
• Re: Server stalls, all CPU 100% system time
  • From: Andre
• Re: Server stalls, all CPU 100% system time
  • From: Bèrto ëd Sèra
• Server stalls, all CPU 100% system time
  • From: Andre
• Re: Avoiding Recheck Cond when using Select Distinct
  • From: Jeff Janes
• Re: Are bitmap index scans slow to start?
  • From: Jeff Janes
• Are bitmap index scans slow to start?
  • From: Jeff Janes
• Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds
  • From: Tom Lane
• Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds
  • From: Heikki Linnakangas
• Re: Bad query plan with high-cardinality column
  • From: Tom Lane
• Re: Bad query plan with high-cardinality column
  • From: Kevin Grittner
• Re: Bad query plan with high-cardinality column
  • From: Alexander Staubo
• Re: Bad query plan with high-cardinality column
  • From: Alexander Staubo
• Re: Bad query plan with high-cardinality column
  • From: Kevin Grittner
• Re: Bad query plan with high-cardinality column
  • From: Tom Lane
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Are bitmap index scans slow to start?
  • From: Nikolas Everett
• Re: Avoiding Recheck Cond when using Select Distinct
  • From: Maciek Sakrejda
• Bad query plan with high-cardinality column
  • From: Alexander Staubo
• Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds
  • From: Markus Schulz
• Re: Avoiding Recheck Cond when using Select Distinct
  • From: Vitalii Tymchyshyn
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Avoiding Recheck Cond when using Select Distinct
  • From: Jeff Janes
• Avoiding Recheck Cond when using Select Distinct
  • From: jackrg
• Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds
  • From: Stephen Frost
• Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds
  • From: Heikki Linnakangas
• BUG: endless lseek(.., SEEK_END) from select queries on x64 builds
  • From: Markus Schulz
• Re: Are bitmap index scans slow to start?
  • From: Jeff Janes
• Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Poor performance after update from SLES11 SP1 to SP2
  • From: Sergey Konoplev
• Re: Poor performance after update from SLES11 SP1 to SP2
  • From: Scott Marlowe
• Re: Poor performance after update from SLES11 SP1 to SP2
  • From: Vasilis Ventirozos
• Poor performance after update from SLES11 SP1 to SP2
  • From: Mark Smith
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Scott Marlowe
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Mark Kirkwood
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Mark Kirkwood
• Re: Very slow update statement on 40mio rows
  • From: Merlin Moncure
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: Speed of exist
  • From: Bastiaan Olij
• Re: slow query plans caused by under-estimation of CTE cardinality
  • From: Tom Lane
• Re: Speed of exist
  • From: Pavel Stehule
• Re: Speed of exist
  • From: Bastiaan Olij
• Re: Speed of exist
  • From: Andy
• Speed of exist
  • From: Bastiaan Olij
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Mark Kirkwood
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Scott Marlowe
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Jon Nelson
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: slow query plans caused by under-estimation of CTE cardinality
  • From: John Lumby
• Re: slow query plans caused by under-estimation of CTE cardinality
  • From: Vitalii Tymchyshyn
• slow query plans caused by under-estimation of CTE cardinality
  • From: John Lumby
• Re: Surprising no use of indexes - low performance
  • From: Nicolas Charles
• Re: temp tablespaces and SSDs, etc..
  • From: Bruce Momjian
• Re: Surprising no use of indexes - low performance
  • From: Merlin Moncure
• Re: postgresql.conf recommendations
  • From: Scott Marlowe
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Scott Marlowe
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: Surprising no use of indexes - low performance
  • From: Jeff Janes
• Re: Very slow update statement on 40mio rows
  • From: Florian Schröck
• Re: Very slow update statement on 40mio rows
  • From: Kevin Grittner
• Very slow update statement on 40mio rows
  • From: Florian Schröck
• Re: Surprising no use of indexes - low performance
  • From: Nicolas Charles
• Re: Partition insert trigger using C language
  • From: Ali Pouya
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Scott Marlowe
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Dan Kogan
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Dan Kogan
• Re: Surprising no use of indexes - low performance
  • From: Jeff Janes
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: Surprising no use of indexes - low performance
  • From: Ireneusz Pluta
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Dan Kogan
• Surprising no use of indexes - low performance
  • From: Nicolas Charles
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Merlin Moncure
• Re: 700K Inserts in transaction
  • From: nik9000
• Re: PG_XLOG 27028 files running out of space
  • From: Tory M Blue
• Re: PG_XLOG 27028 files running out of space
  • From: Albe Laurenz
• Re: PG_XLOG 27028 files running out of space
  • From: Heikki Linnakangas
• Re: PG_XLOG 27028 files running out of space
  • From: Tory M Blue
• Re: PG_XLOG 27028 files running out of space
  • From: Ian Lawrence Barwick
• PG_XLOG 27028 files running out of space
  • From: Tory M Blue
• 700K Inserts in transaction
  • From: Asmir Mustafic
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Dan Kogan
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Josh Berkus
• Re: connection poolers' db connections
  • From: Yetkin Öztürk
• Re: connection poolers' db connections
  • From: Kevin Grittner
• connection poolers' db connections
  • From: Yetkin Öztürk
• Re: Partition insert trigger using C language
  • From: Matheus de Oliveira
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Dan Kogan
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Dan Kogan
• High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Dan Kogan
• Re: numerical primary key vs alphanumerical primary key
  • From: Claudio Freire
• Re: numerical primary key vs alphanumerical primary key
  • From: Florent Guillaume
• Re: numerical primary key vs alphanumerical primary key
  • From: Grant Johnson
• Re: numerical primary key vs alphanumerical primary key
  • From: Julien Cigar
• Re: postgresql.conf recommendations
  • From: Will Platnick
• Re: postgresql.conf recommendations
  • From: Scott Marlowe
• Re: postgresql.conf recommendations
  • From: Johnny Tan
• Re: Partition insert trigger using C language
  • From: Ali Pouya
• Re: postgresql.conf recommendations
  • From: Charles Gomes
• Is it correct to optimize a query with subselect in the "where"?
  • From: Alexandre Riveira
• Re: Slow query even with aggressive auto analyze
  • From: Amit kapila
• Re: postgresql.conf recommendations
  • From: Jeff Janes
• Re: postgresql.conf recommendations
  • From: Scott Marlowe
• Re: postgresql.conf recommendations
  • From: Jeff Janes
• Re: postgresql.conf recommendations
  • From: Josh Krupka
• Re: postgresql.conf recommendations
  • From: Scott Marlowe
• Re: postgresql.conf recommendations
  • From: Johnny Tan
• Re: postgresql.conf recommendations
  • From: Johnny Tan
• Re: Query Time is Slow
  • From: Kevin Grittner
• Query Time is Slow
  • From: Foster, Kristian B (HSC)
• temp tablespaces and SSDs, etc..
  • From: Jon Nelson
• Re: FTS performance issue probably due to wrong planner estimate of detoasting
  • From: Stefan Keller
• Slow query even with aggressive auto analyze
  • From: Karolis Pocius
• Re: FTS performance issue probably due to wrong planner estimate of detoasting
  • From: Jesper Krogh
• Re: FTS performance issue probably due to wrong planner estimate of detoasting
  • From: Pavel Stehule
• FTS performance issue probably due to wrong planner estimate of detoasting
  • From: Stefan Keller
• Re: postgresql.conf recommendations
  • From: Josh Krupka
• Re: postgresql.conf recommendations
  • From: Johnny Tan
• Re: postgresql.conf recommendations
  • From: Charles Gomes
• Re: postgresql.conf recommendations
  • From: Strahinja Kustudić
• Re: postgresql.conf recommendations
  • From: Kevin Grittner
• Re: postgresql.conf recommendations
  • From: Josh Krupka
• Re: postgresql.conf recommendations
  • From: Jeff Janes
• Re: postgresql.conf recommendations
  • From: Johnny Tan
• Re: postgresql.conf recommendations
  • From: Johnny Tan
• Re: postgresql.conf recommendations
  • From: Johnny Tan
• Re: postgresql.conf recommendations
  • From: David Whittaker
• Re: postgresql.conf recommendations
  • From: Josh Krupka
• Re: Slow Query Help
  • From: Pavan Deolasee
• Re: Slow Query Help
  • From: Will Platnick
• Re: Slow Query Help
  • From: Kevin Grittner
• Re: postgresql.conf recommendations
  • From: David Whittaker
• Re: postgresql.conf recommendations
  • From: Kevin Grittner
• Re: Slow Query Help
  • From: Will Platnick
• Re: Slow Query Help
  • From: Pavan Deolasee
• Re: postgresql.conf recommendations
  • From: ac@xxxxxx
• Re: postgresql.conf recommendations
  • From: Pavan Deolasee
• Re: postgresql.conf recommendations
  • From: Josh Krupka
• Re: postgresql.conf recommendations
  • From: Johnny Tan
• Re: postgresql.conf recommendations
  • From: Josh Krupka
• postgresql.conf recommendations
  • From: Johnny Tan
• Re: Slow Query Help
  • From: Heikki Linnakangas
• Slow Query Help
  • From: Will Platnick
• Re: numerical primary key vs alphanumerical primary key
  • From: Виктор Егоров
• numerical primary key vs alphanumerical primary key
  • From: Anne Rosset
• Re: Simple join doesn't use index
  • From: Dan Fairs
• Re: Simple join doesn't use index
  • From: Jeff Janes
• Re: Fighting the planner >:-(
  • From: Виктор Егоров
• Re: Fighting the planner >:-(
  • From: Casey Allen Shobe
• Re: Fighting the planner >:-(
  • From: Виктор Егоров
• Re: Fighting the planner >:-(
  • From: Casey Allen Shobe
• Re: Fighting the planner >:-(
  • From: Виктор Егоров
• Re: Fighting the planner >:-(
  • From: Casey Allen Shobe
• Re: Fighting the planner >:-(
  • From: Casey Allen Shobe
• Re: Fighting the planner >:-(
  • From: Richard Huxton
• Re: Fighting the planner >:-(
  • From: Casey Allen Shobe
• Fighting the planner >:-(
  • From: Casey Allen Shobe
• Re: Simple join doesn't use index
  • From: Jeff Janes
• Re: Simple join doesn't use index
  • From: Alex Vinnik
• Re: Simple join doesn't use index
  • From: Alex Vinnik
• Re: Simple join doesn't use index
  • From: Jeff Janes
• Re: Simple join doesn't use index
  • From: Merlin Moncure
• Re: Simple join doesn't use index
  • From: Alex Vinnik
• Re: Simple join doesn't use index
  • From: Ben Chobot
• Re: Simple join doesn't use index
  • From: Merlin Moncure
• Re: Simple join doesn't use index
  • From: Filip Rembiałkowski
• Re: Simple join doesn't use index
  • From: Alex Vinnik
• Re: Simple join doesn't use index
  • From: Alex Vinnik
• Re: Simple join doesn't use index
  • From: Merlin Moncure
• Re: Simple join doesn't use index
  • From: Filip Rembiałkowski
• Re: Simple join doesn't use index
  • From: Alex Vinnik
• Re: Triggers and transactions
  • From: Rosser Schwarz
• Re: Triggers and transactions
  • From: Richard Huxton
• Triggers and transactions
  • From: Craig James
• Re: PostgreSQL over internet
  • From: belal hamed
• Re: PostgreSQL over internet
  • From: David Rowley
• Re: PostgreSQL over internet
  • From: ktm@xxxxxxxx
• Re: PostgreSQL over internet
  • From: belal hamed
• Re: PostgreSQL over internet
  • From: Richard Neill
• Re: PostgreSQL over internet
  • From: ktm@xxxxxxxx
• PostgreSQL over internet
  • From: belal hamed
• Re: Nested loop and simple join query - slow after upgrade to 9.2
  • From: alexandre - aldeia digital
• Re: Nested loop and simple join query - slow after upgrade to 9.2
  • From: Jeff Janes
• Nested loop and simple join query - slow after upgrade to 9.2
  • From: alexandre - aldeia digital
• DML's to tpcw benchmark for postgresql
  • From: Sachin D. Kotwal
• Re: autovacuum fringe case?
  • From: Jeff Janes
• Re: autovacuum fringe case?
  • From: Alvaro Herrera
• Re: autovacuum fringe case?
  • From: AJ Weber
• Re: autovacuum fringe case?
  • From: Kevin Grittner
• Re: autovacuum fringe case?
  • From: Jeff Janes
• Re: autovacuum fringe case?
  • From: Evgeniy Shishkin
• autovacuum fringe case?
  • From: AJ Weber
• Effect of the WindowAgg on the Nested Loop
  • From: Виктор Егоров
• Re: High CPU usage after partitioning
  • From: Tom Lane
• Re: High CPU usage after partitioning
  • From: Igor Neyman
• Re: High CPU usage after partitioning
  • From: rudi
• Re: High CPU usage after partitioning
  • From: Andrew Dunstan
• Re: High CPU usage after partitioning
  • From: rudi
• Re: High CPU usage after partitioning
  • From: Merlin Moncure
• Re: High CPU usage after partitioning
  • From: rudi
• Re: High CPU usage after partitioning
  • From: Andrew Dunstan
• Re: High CPU usage after partitioning
  • From: Kevin Grittner
• Re: High CPU usage after partitioning
  • From: Merlin Moncure
• Re: Analyze and default_statistics_target
  • From: Albe Laurenz
• Re: Analyze and default_statistics_target
  • From: Heikki Linnakangas
• Analyze and default_statistics_target
  • From: AJ Weber
• High CPU usage after partitioning
  • From: rudi
• Re: Insert performance for large transaction with multiple COPY FROM
  • From: Horst Dehmer
• Re: Insert performance for large transaction with multiple COPY FROM
  • From: Jeff Janes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Ali Pouya
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Ali Pouya
• Re: Insert performance for large transaction with multiple COPY FROM
  • From: Horst Dehmer
• Re: Partition table in 9.0.x?
  • From: Jeff Janes
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Boszormenyi Zoltan
• Re: serious under-estimation of n_distinct for clustered distributions
  • From: Peter Geoghegan
• Re: serious under-estimation of n_distinct for clustered distributions
  • From: Stefan Andreatta
• From TODO: Simplify creation of partitioned tables
  • From: Alexandre de Arruda Paes
• Re: Insert performance for large transaction with multiple COPY FROM
  • From: Claudio Freire
• Re: Insert performance for large transaction with multiple COPY FROM
  • From: Horst Dehmer
• Re: Insert performance for large transaction with multiple COPY FROM
  • From: Tom Lane
• Re: Insert performance for large transaction with multiple COPY FROM
  • From: Claudio Freire
• Re: Insert performance for large transaction with multiple COPY FROM
  • From: Jeff Janes
• Re: Insert performance for large transaction with multiple COPY FROM
  • From: Horst Dehmer
• Re: Insert performance for large transaction with multiple COPY FROM
  • From: Claudio Freire
• Insert performance for large transaction with multiple COPY FROM
  • From: Jeff Janes
• Insert performance for large transaction with multiple COPY FROM
  • From: Horst Dehmer
• Re: Slow query after upgrade from 9.0 to 9.2
  • From: Jeff Janes
• Re: Partition insert trigger using C language
  • From: Matheus de Oliveira
• Re: Partition insert trigger using C language
  • From: Heikki Linnakangas
• Re: Partition insert trigger using C language
  • From: Matheus de Oliveira
• Re: Partition insert trigger using C language
  • From: Matheus de Oliveira
• Re: Partition insert trigger using C language
  • From: Heikki Linnakangas
• Re: Slow query after upgrade from 9.0 to 9.2
  • From: Andrzej Zawadzki
• Re: Slow query after upgrade from 9.0 to 9.2
  • From: Andrzej Zawadzki
• Re: Partition insert trigger using C language
  • From: Charles Gomes
• Re: Partition insert trigger using C language
  • From: Matheus de Oliveira
• Re: Partition insert trigger using C language
  • From: Heikki Linnakangas
• Re: Partition insert trigger using C language
  • From: Pavel Stehule
• Re: Partition insert trigger using C language
  • From: Matheus de Oliveira
• Re: Partition insert trigger using C language
  • From: Heikki Linnakangas
• Re: Slow query after upgrade from 9.0 to 9.2
  • From: Matheus de Oliveira
• Partition insert trigger using C language
  • From: Matheus de Oliveira
• Re: Slow query after upgrade from 9.0 to 9.2
  • From: Jeff Janes
• Updates on one row causing ExclusiveLock on PostgreSQL 8.3.5
  • From: PostgreSQL
• Updates on one row causing ExclusiveLock on PostgreSQL 8.3.5
  • From: PostgreSQL
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Shaun Thomas
• Slow query after upgrade from 9.0 to 9.2
  • From: Andrzej Zawadzki
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Henri Philipps
• Re: Simple join doesn't use index
  • From: Merlin Moncure
• Re: Simple join doesn't use index
  • From: Alex Vinnik
• Re: FW: performance issue with a 2.5gb joinded table
  • From: Vladimir Sitnikov
• Re: Simple join doesn't use index
  • From: Jeff Janes
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Alan Hodgson
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Shaun Thomas
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: AJ Weber
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Shaun Thomas
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Scott Marlowe
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Shaun Thomas
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Scott Marlowe
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Shaun Thomas
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Midge Brown
• Re: Partition table in 9.0.x?
  • From: AJ Weber
• Re: Partition table in 9.0.x?
  • From: Tom Lane
• Re: Partition table in 9.0.x?
  • From: Jeff Janes
• Re: Partition table in 9.0.x?
  • From: AJ Weber
• Re: Sub optimal performance with default setting of Postgresql with FreeBSD 9.1 on ZFS
  • From: Patrick Dung
• Re: Partition table in 9.0.x?
  • From: Jeff Janes
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Andrea Suisani
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Andrea Suisani
• Re: Simple join doesn't use index
  • From: Merlin Moncure
• Re: Forcing WAL flush
  • From: Jeff Janes
• Re: Forcing WAL flush
  • From: james
• Re: Forcing WAL flush
  • From: François Beausoleil
• Forcing WAL flush
  • From: james
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Merlin Moncure
• Re: Sub optimal performance with default setting of Postgresql with FreeBSD 9.1 on ZFS
  • From: ktm@xxxxxxxx
• Re: SMP on a heavy loaded database FIXED !!!!
  • From: nobody nowhere
• Re: Sub optimal performance with default setting of Postgresql with FreeBSD 9.1 on ZFS
  • From: Patrick Dung
• Re: Partition table in 9.0.x?
  • From: AJ Weber
• Re[2]: [PERFORM] Re[4]: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: nobody nowhere
• Re[2]: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: nobody nowhere
• Re: Partition table in 9.0.x?
  • From: Jeff Janes
• Re: Re[4]: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: Tom Lane
• Re: Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: Claudio Freire
• Re[6]: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: nobody nowhere
• Partition table in 9.0.x?
  • From: AJ Weber
• Re: FW: performance issue with a 2.5gb joinded table
  • From: Daniel Westermann
• Re: Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: Claudio Freire
• Re[4]: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: nobody nowhere
• Re: FW: performance issue with a 2.5gb joinded table
  • From: Tom Lane
• Re: Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: Claudio Freire
• Re: Postgres delete performance problem
  • From: Vitalii Tymchyshyn
• Re: Postgres delete performance problem
  • From: dankogan
• Re: Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: Claudio Freire
• Re[2]: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: nobody nowhere
• Re[2]: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: nobody nowhere
• Re: Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: Claudio Freire
• Re: Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: Charles Gomes
• Re[2]: [PERFORM] SMP on a heavy loaded database
  • From: nobody nowhere
• Re: SMP on a heavy loaded database
  • From: Scott Marlowe
• Re: serious under-estimation of n_distinct for clustered distributions
  • From: Stefan Andreatta
• Re: Simple join doesn't use index
  • From: Stefan Andreatta
• SMP on a heavy loaded database
  • From: nobody nowhere
• Re: Simple join doesn't use index
  • From: Jeremy Harris
• Simple join doesn't use index
  • From: Alex Vinnik
• Re: FW: performance issue with a 2.5gb joinded table
  • From: Daniel Westermann
• Re: FW: performance issue with a 2.5gb joinded table
  • From: Heikki Linnakangas
• FW: performance issue with a 2.5gb joinded table
  • From: Daniel Westermann
• Re: Two Necessary Kernel Tweaks for Linux Systems
  • From: Richard Neill
• Two Necessary Kernel Tweaks for Linux Systems
  • From: Shaun Thomas
• Re: High %SYS CPU usage
  • From: Cesar Martin
• Re: Slow connections on Win 7
  • From: Sam Gendler
• Slow connections on Win 7
  • From: John Kasarda
• Re: serious under-estimation of n_distinct for clustered distributions
  • From: Claudio Freire
• Re: serious under-estimation of n_distinct for clustered distributions
  • From: Stefan Andreatta
• Re: serious under-estimation of n_distinct for clustered distributions
  • From: Peter Geoghegan
• serious under-estimation of n_distinct for clustered distributions
  • From: Stefan Andreatta
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Pavel Stehule
• RES: Performance on Bulk Insert to Partitioned Table
  • From: Luciano Ernesto da Silva
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Jeff Janes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Pavel Stehule
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Stephen Frost
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Stephen Frost
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Jeff Janes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Pavel Stehule
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Vitalii Tymchyshyn
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Vitalii Tymchyshyn
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Pavel Stehule
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Stephen Frost
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Vitalii Tymchyshyn
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Vitalii Tymchyshyn
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Jeff Janes
• Re: backend suddenly becomes slow, then remains slow
  • From: Jeff Janes
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Nikolas Everett
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Tom Lane
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Nikolas Everett
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Tom Lane
• sched_migration_cost for high-connection counts
  • From: Shaun Thomas
• Re: Slow queries after vacuum analyze
  • From: Ghislain ROUVIGNAC
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Emmanuel Cecchet
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Richard Neill
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Tom Lane
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Nikolas Everett
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Nikolas Everett
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Pavel Stehule
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Tom Lane
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Stephen Frost
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Pavel Stehule
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Jeff Janes
• Performance on Bulk Insert to Partitioned Table
  • From: Jeff Janes
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Jeff Janes
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Nikolas Everett
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Nikolas Everett
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Nikolas Everett
• Re: backend suddenly becomes slow, then remains slow
  • From: Andrew Dunstan
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: Richard Neill
• Re: explain analyze reports that my queries are fast but they run very slowly
  • From: François Beausoleil
• explain analyze reports that my queries are fast but they run very slowly
  • From: Nikolas Everett
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Tom Lane
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Richard Neill
• Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Jeff Janes