Postgres Performance Date Index

• Thread Index

• 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
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Improve performance for writing
  • From: Charles Gomes
• Improve performance for writing
  • From: Markus Innerebner
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Richard Neill
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Pavel Stehule
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?)
  • From: Jeff Janes
• backend suddenly becomes slow, then remains slow
  • From: Jeff Janes
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?)
  • From: Jeff Janes
• Re: 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: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?)
  • From: John Rouillard
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?)
  • From: Richard Neill
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Evgeny Shishkin
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?
  • From: Jeff Janes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Jeff Janes
• Re: 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: Richard Neill
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Richard Neill
• Re: Slow queries after vacuum analyze
  • From: Kevin Grittner
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Jeff Janes
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Jeff Janes
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Jeff Janes
• Re: 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: Richard Neill
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Richard Neill
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Scott Marlowe
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Tom Lane
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Ondrej Ivanič
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Jeff Janes
• Re: hash join vs nested loop join
  • From: Huan Ruan
• Re: Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• 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: Scott Marlowe
• Performance on Bulk Insert to Partitioned Table
  • From: Charles Gomes
• 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: Tom Lane
• Re: hash join vs nested loop join
  • From: Kevin Grittner
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Richard Neill
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Richard Neill
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Jeff Janes
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Tom Lane
• Re: hash join vs nested loop join
  • From: Huan Ruan
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Richard Neill
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Sergey Konoplev
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Richard Neill
• Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Sergey Konoplev
• Why does the query planner use two full indexes, when a dedicated partial index exists?
  • From: Richard Neill
• PG 9.1 performance loss due to query plan being changed depending on db data (4s vs 200ms)
  • From: Rodrigo Rosenfeld Rosas
• Re: How can i find out top high load sql queries in PostgreSQL.
  • From: Igor Neyman
• Re: hash join vs nested loop join
  • From: Kevin Grittner
• Re: hash join vs nested loop join
  • From: Huan Ruan
• Re: Slow queries after vacuum analyze
  • From: Kevin Grittner
• Re: How can i find out top high load sql queries in PostgreSQL.
  • From: Vibhor Kumar
• Re: How can i find out top high load sql queries in PostgreSQL.
  • From: suhas.basavaraj12
• Re: Do I have a hardware or a software problem?
  • From: Scott Marlowe
• Re: Why does the number of rows are different in actual and estimated.
  • From: Kevin Grittner
• Re: Why does the number of rows are different in actual and estimated.
  • From: AI Rumman
• Re: Why does the number of rows are different in actual and estimated.
  • From: Kevin Grittner
• Re: Why does the number of rows are different in actual and estimated.
  • From: Claudio Freire
• Re: Why does the number of rows are different in actual and estimated.
  • From: AI Rumman
• Re: backend suddenly becomes slow, then remains slow
  • From: Andrew Dunstan
• Re: Why does the number of rows are different in actual and estimated.
  • From: Claudio Freire
• Re: backend suddenly becomes slow, then remains slow
  • From: Tom Lane
• Re: Why does the number of rows are different in actual and estimated.
  • From: AI Rumman
• Re: Why does the number of rows are different in actual and estimated.
  • From: Tom Lane
• Re: Why does the number of rows are different in actual and estimated.
  • From: Kevin Grittner
• Re: Why does the number of rows are different in actual and estimated.
  • From: Claudio Freire
• Re: Why does the number of rows are different in actual and estimated.
  • From: AI Rumman
• backend suddenly becomes slow, then remains slow
  • From: Andrew Dunstan
• Re: hash join vs nested loop join
  • From: Kevin Grittner
• Re: hash join vs nested loop join
  • From: Huan Ruan
• Re: hash join vs nested loop join
  • From: Kevin Grittner
• Re: Why does the number of rows are different in actual and estimated.
  • From: Claudio Freire
• Re: hash join vs nested loop join
  • From: Huan Ruan
• Re: Why does the number of rows are different in actual and estimated.
  • From: Evgeny Shishkin
• Re: Why does the number of rows are different in actual and estimated.
  • From: Tom Lane
• Re: Why does the number of rows are different in actual and estimated.
  • From: Evgeny Shishkin
• Re: Why does the number of rows are different in actual and estimated.
  • From: Andrew Dunstan
• Re: Why does the number of rows are different in actual and estimated.
  • From: Claudio Freire
• Re: Why does the number of rows are different in actual and estimated.
  • From: Evgeny Shishkin
• Re: Why does the number of rows are different in actual and estimated.
  • From: Andrew Dunstan
• Why does the number of rows are different in actual and estimated.
  • From: AI Rumman
• Re: Occasional timeouts on TRUNCATE and simple INSERTs
  • From: Osborn, Jeff
• Re: Slow queries after vacuum analyze
  • From: Kevin Grittner
• Slow queries after vacuum analyze
  • From: Ghislain ROUVIGNAC
• Re: hash join vs nested loop join
  • From: Huan Ruan
• How do I track stats on foreign table access through foreign data wrapper?
  • From: David Crawford
• Re: hash join vs nested loop join
  • From: Huan Ruan
• Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?
  • From: Patryk Sidzina
• Re: encouraging index-only scans
  • From: Tom Lane
• Re: Limit & offset effect on query plans
  • From: Kevin Grittner
• Re: Limit & offset effect on query plans
  • From: Tom Lane
• Re: Limit & offset effect on query plans
  • From: Kevin Grittner
• Re: problem with large inserts
  • From: Filip Rembiałkowski
• Re: problem with large inserts
  • From: Lutz Fischer
• Re: Limit & offset effect on query plans
  • From: Tom Lane
• Re: problem with large inserts
  • From: Tom Lane
• Re: problem with large inserts
  • From: Filip Rembiałkowski
• Re: problem with large inserts
  • From: Willem Leenen
• Re: Limit & offset effect on query plans
  • From: Kevin Grittner
• problem with large inserts
  • From: Lutz Fischer
• Re: hash join vs nested loop join
  • From: Kevin Grittner
• Re: Do I have a hardware or a software problem?
  • From: Jeff Janes
• Memory issue for inheritance tables.
  • From: Hari Babu
• Re: Limit & offset effect on query plans
  • From: Pavan Deolasee
• Limit & offset effect on query plans
  • From: Amitabh Kant
• Re: hash join vs nested loop join
  • From: Kevin Grittner
• Re: Do I have a hardware or a software problem?
  • From: Craig Ringer
• Re: encouraging index-only scans
  • From: Andrew Dunstan
• Re: encouraging index-only scans
  • From: Andrew Dunstan
• encouraging index-only scans
  • From: Andrew Dunstan
• Re: Read rows deleted
  • From: Andrew Dunstan
• Re: Read rows deleted
  • From: Alejandro Carrillo
• Re: Read rows deleted
  • From: Sergey Konoplev
• track_activity_query_size
  • From: Andrew Dunstan
• Re: Savepoints in transactions for speed?
  • From: Jeff Janes
• Re: Do I have a hardware or a software problem?
  • From: Niels Kristian Schjødt
• Re: hash join vs nested loop join
  • From: Jeff Janes
• Read rows deleted
  • From: Alejandro Carrillo
• Re: Do I have a hardware or a software problem?
  • From: Niels Kristian Schjødt
• Re: hash join vs nested loop join
  • From: Evgeny Shishkin
• Re: hash join vs nested loop join
  • From: Evgeny Shishkin
• hash join vs nested loop join
  • From: Huan Ruan
• Re: Do I have a hardware or a software problem?
  • From: David Boreham
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Re: Do I have a hardware or a software problem?
  • From: David Boreham
• Re: Do I have a hardware or a software problem?
  • From: Mark Kirkwood
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Re: Do I have a hardware or a software problem?
  • From: Craig Ringer
• Re: Do I have a hardware or a software problem?
  • From: David Boreham
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Re: Do I have a hardware or a software problem?
  • From: David Boreham
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Re: Do I have a hardware or a software problem?
  • From: David Boreham
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Re: Do I have a hardware or a software problem?
  • From: Craig Ringer
• Re: Do I have a hardware or a software problem?
  • From: Rosser Schwarz
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Re: Do I have a hardware or a software problem?
  • From: Craig Ringer
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Re: Do I have a hardware or a software problem?
  • From: Craig Ringer
• Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?
  • From: Tom Lane
• Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?
  • From: Jeff Janes
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Re: Do I have a hardware or a software problem?
  • From: Niels Kristian Schjødt
• Re: Occasional timeouts on TRUNCATE and simple INSERTs
  • From: Osborn, Jeff
• Re: Occasional timeouts on TRUNCATE and simple INSERTs
  • From: Merlin Moncure
• Re: Occasional timeouts on TRUNCATE and simple INSERTs
  • From: Sergey Konoplev
• Occasional timeouts on TRUNCATE and simple INSERTs
  • From: Osborn, Jeff
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Re: Do I have a hardware or a software problem?
  • From: Niels Kristian Schjødt
• Re: Do I have a hardware or a software problem?
  • From: Jeff Janes
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Re: Do I have a hardware or a software problem?
  • From: Niels Kristian Schjødt
• Re: Do I have a hardware or a software problem?
  • From: Craig Ringer
• Re: Do I have a hardware or a software problem?
  • From: Niels Kristian Schjødt
• Re: Do I have a hardware or a software problem?
  • From: Jeff Janes
• Re: Do I have a hardware or a software problem?
  • From: Evgeny Shishkin
• Do I have a hardware or a software problem?
  • From: Niels Kristian Schjødt
• Re: Slow query: bitmap scan troubles
  • From: postgresql
• Re: Perform scan on Toast table
  • From: Albe Laurenz
• Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?
  • From: Jeff Janes
• Perform scan on Toast table
  • From: classical_89
• Re: Slow query: bitmap scan troubles
  • From: Philip Scott
• Why is PostgreSQL 9.2 slower than 9.1 in my tests?
  • From: Patryk Sidzina
• Re: Slow query: bitmap scan troubles
  • From: Philip Scott
• Re: Slow query: bitmap scan troubles
  • From: Philip Scott
• Re: Any idea on how to improve the statistics estimates for this plan?
  • From: Jeff Janes
• Re: Slow query: bitmap scan troubles
  • From: Guillaume Lelarge
• Re: Any idea on how to improve the statistics estimates for this plan?
  • From: Guillaume Smet
• Re: Any idea on how to improve the statistics estimates for this plan?
  • From: Tom Lane
• Re: Any idea on how to improve the statistics estimates for this plan?
  • From: Jeff Janes
• Re: Slow query: bitmap scan troubles
  • From: Jeff Janes
• Re: Slow query: bitmap scan troubles
  • From: Claudio Freire
• Re: Slow query: bitmap scan troubles
  • From: Jeff Janes
• Re: Slow query: bitmap scan troubles
  • From: postgresql
• Re: Slow query: bitmap scan troubles
  • From: postgresql
• Re: Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance]
  • From: Andrea Suisani
• Re: Slow query: bitmap scan troubles
  • From: postgresql
• Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance]
  • From: John Lister
• Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance]
  • From: Andrea Suisani
• Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance]
  • From: Andrea Suisani
• Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance
  • From: John Lister
• Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance]
  • From: John Lister
• Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance
  • From: Stuart Bishop
• Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance
  • From: Scott Marlowe
• Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance
  • From: Shaun Thomas
• Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance
  • From: Bruce Momjian
• Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance
  • From: Shaun Thomas
• Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance
  • From: Daniel Farina
• Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance
  • From: Niels Kristian Schjødt
• Any idea on how to improve the statistics estimates for this plan?
  • From: Guillaume Smet
• Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance
  • From: Shaun Thomas
• Re: Slow query: bitmap scan troubles
  • From: Tom Lane
• Re: Slow query: bitmap scan troubles
  • From: Claudio Freire
• Re: Slow query: bitmap scan troubles
  • From: Jeff Janes
• Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance]
  • From: Andrew Dunstan
• Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance]
  • From: Claudio Freire