Postgres Performance Date Index

• Thread Index

• Re: oom_killer
  • From: Kevin Grittner
• Re: oom_killer
  • From: Tory M Blue
• OT (slightly) testing for data loss on an SSD drive due to power failure
  • From: John Rouillard
• Re: oom_killer
  • From: Cédric Villemain
• Checkpoint execution overrun impact?
  • From: drvillo
• Re: oom_killer
  • From: Merlin Moncure
• Re: oom_killer
  • From: Scott Marlowe
• Re: oom_killer
  • From: J Sisson
• Re: oom_killer
  • From: Tory M Blue
• Re: oom_killer
  • From: Scott Marlowe
• Re: Constraint exclusion can't process simple constant expressions?
  • From: Josh Berkus
• Re: oom_killer
  • From: Claudio Freire
• Re: oom_killer
  • From: Tory M Blue
• Re: oom_killer
  • From: Claudio Freire
• Re: oom_killer
  • From: Tory M Blue
• Re: oom_killer
  • From: Tory M Blue
• Re: oom_killer
  • From: Merlin Moncure
• Re: oom_killer
  • From: Claudio Freire
• Re: oom_killer
  • From: Claudio Freire
• Re: oom_killer
  • From: Stephen Frost
• Re: oom_killer
  • From: yoshi watanabe
• oom_killer
  • From: Tory M Blue
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Laurent Laborde
• Re: Constraint exclusion can't process simple constant expressions?
  • From: Claudio Freire
• Re: Constraint exclusion can't process simple constant expressions?
  • From: Claudio Freire
• Re: %100 CPU on Windows Server 2003
  • From: Pavel Stehule
• %100 CPU on Windows Server 2003
  • From: Allen Sooredoo
• Re: Constraint exclusion can't process simple constant expressions?
  • From: Tom Lane
• Re: Constraint exclusion can't process simple constant expressions?
  • From: Josh Berkus
• Re: Constraint exclusion can't process simple constant expressions?
  • From: Brendan Jurd
• rant ? check the BBWC
  • From: mark
• Re: Constraint exclusion can't process simple constant expressions?
  • From: Josh Berkus
• Re: Constraint exclusion can't process simple constant expressions?
  • From: Brendan Jurd
• Re: Constraint exclusion can't process simple constant expressions?
  • From: Josh Berkus
• Re: Constraint exclusion can't process simple constant expressions?
  • From: Tom Lane
• Constraint exclusion can't process simple constant expressions?
  • From: Josh Berkus
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Shaun Thomas
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Laurent Laborde
• Re: not using partial index
  • From: Tom Lane
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Jeff
• not using partial index
  • From: Willy-Bas Loos
• Re: Two different execution plans for similar requests
  • From: Joby Joba
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Josh Berkus
• Re: How to configure a read-only database server?
  • From: philippe
• Re: How to configure a read-only database server?
  • From: Greg Smith
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Robert Haas
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Robert Haas
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Laurent Laborde
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Nicholson, Brad (Toronto, ON, CA)
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Laurent Laborde
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Laurent Laborde
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Greg Smith
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Laurent Laborde
• Re: big distinct clause vs. group by
  • From: Claudio Freire
• postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Laurent Laborde
• Re: big distinct clause vs. group by
  • From: Robert Klemme
• Re: How to configure a read-only database server?
  • From: Robert Klemme
• Re: big distinct clause vs. group by
  • From: Uwe Bartels
• Re: big distinct clause vs. group by
  • From: Robert Klemme
• How to configure a read-only database server?
  • From: Stefan Keller
• Re: big distinct clause vs. group by
  • From: Uwe Bartels
• Re: Select in subselect vs select = any array
  • From: Robert Haas
• Re: Background fsck
  • From: Pierre C
• Re: Is there a way to selective dump of records in Postgres 9.0.3?
  • From: Nikolas Everett
• Is there a way to selective dump of records in Postgres 9.0.3?
  • From: Sethu Prasad
• Re: REINDEX takes half a day (and still not complete!)
  • From: tv
• Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Robert Haas
• Re: Is there a way to selective dump of records in Postgres 9.0.3?
  • From: Samuel Gendler
• Re: Custom operator class costs
  • From: Robert Haas
• Re: Index use difference betweer LIKE, LIKE ANY?
  • From: Robert Haas
• Re: big distinct clause vs. group by
  • From: Robert Haas
• Assessing performance of fetches
  • From: John Rouillard
• Re: Assessing performance of fetches
  • From: Tom Lane
• Re: REINDEX takes half a day (and still not complete!)
  • From: Sethu Prasad
• Re: REINDEX takes half a day (and still not complete!)
  • From: Scott Marlowe
• Re: REINDEX takes half a day (and still not complete!)
  • From: Phoenix Kiula
• Re: REINDEX takes half a day (and still not complete!)
  • From: Scott Marlowe
• Re: REINDEX takes half a day (and still not complete!)
  • From: Scott Marlowe
• Re: REINDEX takes half a day (and still not complete!)
  • From: Scott Marlowe
• Re: REINDEX takes half a day (and still not complete!)
  • From: Shashank Tripathi
• Re: REINDEX takes half a day (and still not complete!)
  • From: Claudio Freire
• Re: REINDEX takes half a day (and still not complete!)
  • From: Claudio Freire
• Re: REINDEX takes half a day (and still not complete!)
  • From: Phoenix Kiula
• Re: REINDEX takes half a day (and still not complete!)
  • From: Phoenix Kiula
• Re: REINDEX takes half a day (and still not complete!)
  • From: Scott Marlowe
• Re: REINDEX takes half a day (and still not complete!)
  • From: Alan Hodgson
• Re: REINDEX takes half a day (and still not complete!)
  • From: Phoenix
• Re: REINDEX takes half a day (and still not complete!)
  • From: Scott Marlowe
• Re: REINDEX takes half a day (and still not complete!)
  • From: Jesper Krogh
• Re: REINDEX takes half a day (and still not complete!)
  • From: Scott Marlowe
• Re: REINDEX takes half a day (and still not complete!)
  • From: Phoenix Kiula
• Re: Bad Query Plan with Range Query
  • From: Mark Williams
• Re: Bad Query Plan with Range Query
  • From: Kevin Grittner
• Re: Bad Query Plan with Range Query
  • From: Mark Williams
• Re: Bad Query Plan with Range Query
  • From: Kevin Grittner
• Re: Bad Query Plan with Range Query
  • From: Kenneth Marshall
• Bad Query Plan with Range Query
  • From: Mark Williams
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: pasman pasmański
• Re: poor execution plan because column dependence
  • From: Václav Ovsík
• Re: Linux: more cores = less concurrency.
  • From: Claudio Freire
• Re: Linux: more cores = less concurrency.
  • From: Scott Carey
• Re: Linux: more cores = less concurrency.
  • From: Claudio Freire
• Re: Linux: more cores = less concurrency.
  • From: Scott Carey
• Re: poor execution plan because column dependence
  • From: Tom Lane
• Re: Performance
  • From: Cédric Villemain
• Re: Linux: more cores = less concurrency.
  • From: Cédric Villemain
• Re: Linux: more cores = less concurrency.
  • From: Florian Weimer
• Re: Performance
  • From: tv
• Re: poor execution plan because column dependence
  • From: Václav Ovsík
• Re: Performance
  • From: Claudio Freire
• Re: Linux: more cores = less concurrency.
  • From: Greg Smith
• Re: Performance
  • From: Scott Marlowe
• Re: Performance
  • From: Joshua D. Drake
• Re: Performance
  • From: Tom Lane
• Re: Performance
  • From: Tomas Vondra
• Re: Performance
  • From: Claudio Freire
• Re: Performance
  • From: Tomas Vondra
• Re: Performance
  • From: Kevin Grittner
• Re: Performance
  • From: Nathan Boley
• Re: Performance
  • From: Kevin Grittner
• Re: Performance
  • From: Claudio Freire
• Re: Performance
  • From: Tom Lane
• Re: Slow query postgres 8.3
  • From: Claudio Freire
• Re: Performance
  • From: Claudio Freire
• Re: how explain works to Mr Nathan Boley
  • From: Tomas Vondra
• Re: Slow query postgres 8.3
  • From: Tomas Vondra
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Scott Carey
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Tom Lane
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Scott Carey
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Scott Carey
• Re: Linux: more cores = less concurrency.
  • From: Scott Carey
• Re: poor execution plan because column dependence
  • From: Tom Lane
• Re: Performance
  • From: Kevin Grittner
• Re: Performance
  • From: tv
• Re: Performance
  • From: Ogden
• Re: Linux: more cores = less concurrency.
  • From: Glyn Astill
• Re: poor execution plan because column dependence
  • From: Václav Ovsík
• Re: poor execution plan because column dependence
  • From: Václav Ovsík
• Re: poor execution plan because column dependence
  • From: Tom Lane
• Re: poor execution plan because column dependence
  • From: Bob Lunney
• poor execution plan because column dependence
  • From: Václav Ovsík
• Re: Performance
  • From: Tomas Vondra
• Re: Performance
  • From: Ogden
• Re: Performance
  • From: Tomas Vondra
• Re: Linux: more cores = less concurrency.
  • From: Strange, John W
• Re: Performance
  • From: Ogden
• Re: Performance
  • From: Tomas Vondra
• Re: Performance
  • From: Ogden
• Re: Performance
  • From: Andreas Kretschmer
• Re: Linux: more cores = less concurrency.
  • From: Merlin Moncure
• Re: Linux: more cores = less concurrency.
  • From: Greg Smith
• Re: Linux: more cores = less concurrency.
  • From: Greg Smith
• Re: Linux: more cores = less concurrency.
  • From: F. BROUARD / SQLpro
• Re: Linux: more cores = less concurrency.
  • From: Claudio Freire
• Re: Linux: more cores = less concurrency.
  • From: Kevin Grittner
• Performance
  • From: Ogden
• Re: Linux: more cores = less concurrency.
  • From: Merlin Moncure
• Re: Linux: more cores = less concurrency.
  • From: Glyn Astill
• Re: Linux: more cores = less concurrency.
  • From: Glyn Astill
• Re: Linux: more cores = less concurrency.
  • From: Kevin Grittner
• Re: performance problem with LIMIT (order BY in DESC order). Wrong index used?
  • From: Tom Lane
• Re: Two servers - One Replicated - Same query
  • From: Kevin Grittner
• Re: Linux: more cores = less concurrency.
  • From: Merlin Moncure
• Re: Linux: more cores = less concurrency.
  • From: Merlin Moncure
• Re: Poor performance when joining against inherited tables
  • From: Shaun Thomas
• Re: Linux: more cores = less concurrency.
  • From: Glyn Astill
• Re: performance problem with LIMIT (order BY in DESC order). Wrong index used?
  • From: Dieter Rehbein
• Re: performance problem with LIMIT (order BY in DESC order). Wrong index used?
  • From: tv
• Re: performance problem with LIMIT (order BY in DESC order). Wrong index used?
  • From: Claudio Freire
• Re: performance problem with LIMIT (order BY in DESC order). Wrong index used?
  • From: Dieter Rehbein
• Re: Linux: more cores = less concurrency.
  • From: Glyn Astill
• Re: Linux: more cores = less concurrency.
  • From: Glyn Astill
• DBT-5 & Postgres 9.0.3
  • From: Sethu Prasad
• Re: performance problem with LIMIT (order BY in DESC order). Wrong index used?
  • From: Claudio Freire
• Re: Slow query postgres 8.3
  • From: Claudio Freire
• Re: Linux: more cores = less concurrency.
  • From: Arjen van der Meijden
• Poor performance when joining against inherited tables
  • From: Lucas Madar
• Re: Linux: more cores = less concurrency.
  • From: Scott Marlowe
• performance problem with LIMIT (order BY in DESC order). Wrong index used?
  • From: Dieter Rehbein
• Re: Linux: more cores = less concurrency.
  • From: Jesper Krogh
• Re: Linux: more cores = less concurrency.
  • From: Scott Marlowe
• Re: Linux: more cores = less concurrency.
  • From: Merlin Moncure
• Re: Linux: more cores = less concurrency.
  • From: mark
• Re: Linux: more cores = less concurrency.
  • From: Scott Marlowe
• Re: Linux: more cores = less concurrency.
  • From: Scott Marlowe
• Re: Linux: more cores = less concurrency.
  • From: mark
• Two servers - One Replicated - Same query
  • From: Ozer, Pam
• Re: how explain works to Mr Nathan Boley
  • From: Radhya sahal
• Re: how explain works
  • From: Nathan Boley
• how explain works
  • From: Radhya sahal
• Re: Postgres 9 slave lagging
  • From: Merlin Moncure
• Re: Linux: more cores = less concurrency.
  • From: David Rees
• Re: Linux: more cores = less concurrency.
  • From: Kevin Grittner
• Re: Linux: more cores = less concurrency.
  • From: James Cloos
• Re: Linux: more cores = less concurrency.
  • From: Glyn Astill
• Re: Linux: more cores = less concurrency.
  • From: Kevin Grittner
• Re: Linux: more cores = less concurrency.
  • From: Scott Marlowe
• Re: Linux: more cores = less concurrency.
  • From: david
• Re: Linux: more cores = less concurrency.
  • From: Glyn Astill
• Re: Linux: more cores = less concurrency.
  • From: Jesper Krogh
• Re: Linux: more cores = less concurrency.
  • From: Steve Clark
• Postgres 9 slave lagging
  • From: Saurabh Agrawal
• Re: Linux: more cores = less concurrency.
  • From: Glyn Astill
• Re: Linux: more cores = less concurrency.
  • From: Scott Marlowe
• Re: Multiple index builds on same table - in one sweep?
  • From: Scott Marlowe
• Re: Multiple index builds on same table - in one sweep?
  • From: Tom Lane
• Re: Linux: more cores = less concurrency.
  • From: Scott Marlowe
• Re: Linux: more cores = less concurrency.
  • From: Glyn Astill
• Re: Multiple index builds on same table - in one sweep?
  • From: Shaun Thomas
• Re: Linux: more cores = less concurrency.
  • From: Joshua D. Drake
• Re: Linux: more cores = less concurrency.
  • From: Kevin Grittner
• Linux: more cores = less concurrency.
  • From: Glyn Astill
• Re: Multiple index builds on same table - in one sweep?
  • From: Scott Marlowe
• Re: Slow query postgres 8.3
  • From: Kevin Grittner
• Re: Multiple index builds on same table - in one sweep?
  • From: Greg Smith
• Re: Multiple index builds on same table - in one sweep?
  • From: Scott Marlowe
• Re: Slow query postgres 8.3
  • From: Anne Rosset
• Re: Multiple index builds on same table - in one sweep?
  • From: Scott Marlowe
• Re: optimizer parameters
  • From: Greg Smith
• Re: Multiple index builds on same table - in one sweep?
  • From: Greg Smith
• Re: optimizer parameters
  • From: Tomas Vondra
• optimizer parameters
  • From: Radhya sahal
• Re: Multiple index builds on same table - in one sweep?
  • From: Chris Ruprecht
• Re: Multiple index builds on same table - in one sweep?
  • From: Tom Lane
• Multiple index builds on same table - in one sweep?
  • From: Chris Ruprecht
• Re: Why it is using/not using index scan?
  • From: Tomas Vondra
• Re: Slow query postgres 8.3
  • From: tv
• Slow query postgres 8.3
  • From: Anne Rosset
• Re: Background fsck
  • From: Ireneusz Pluta
• Re: Why it is using/not using index scan?
  • From: Merlin Moncure
• postgresql benchmark
  • From: Radhya sahal
• Re: Background fsck
  • From: Jochen Erwied
• Re: Background fsck
  • From: Achilleas Mantzios
• Re: Background fsck
  • From: Ireneusz Pluta
• Re: Background fsck
  • From: Ireneusz Pluta
• Re: Background fsck
  • From: Ivan Voras
• Re: Background fsck
  • From: Ireneusz Pluta
• Re: Background fsck
  • From: Scott Marlowe
• Re: Background fsck
  • From: Achilleas Mantzios
• Re: Background fsck
  • From: Ireneusz Pluta
• Re: Intel SSDs that may not suck
  • From: Scott Carey
• Re: Background fsck
  • From: Greg Smith
• Re: Background fsck
  • From: Achilleas Mantzios
• Re: Background fsck
  • From: Ivan Voras
• Re: Partial index slower than regular index
  • From: Thom Brown
• Re: help speeding up a query in postgres 8.4.5
  • From: Maria L. Wilson
• Re: Partial index slower than regular index
  • From: Thom Brown
• Re: Partial index slower than regular index
  • From: Tom Lane
• Re: Intel SSDs that may not suck
  • From: Greg Smith
• Re: Intel SSDs that may not suck
  • From: Jesper Krogh
• Re: Intel SSDs that may not suck
  • From: David Boreham
• Re: Intel SSDs that may not suck
  • From: gnuoytr
• Re: Intel SSDs that may not suck
  • From: David Boreham
• Re: Intel SSDs that may not suck
  • From: Greg Smith
• Re: Intel SSDs that may not suck
  • From: Greg Smith
• Re: Intel SSDs that may not suck
  • From: David Rees
• Re: Intel SSDs that may not suck
  • From: Scott Carey
• Re: Intel SSDs that may not suck
  • From: Scott Carey
• Re: Intel SSDs that may not suck
  • From: Scott Carey
• Re: Intel SSDs that may not suck
  • From: Scott Carey
• Re: Intel SSDs that may not suck
  • From: Scott Carey
• Re: Intel SSDs that may not suck
  • From: gnuoytr
• Re: Background fsck
  • From: Ireneusz Pluta
• Re: Background fsck
  • From: Scott Marlowe
• Background fsck
  • From: Ireneusz Pluta
• Re: Intel SSDs that may not suck
  • From: Andy
• Re: Intel SSDs that may not suck
  • From: Scott Carey
• Re: very long updates very small tables
  • From: Tomas Vondra
• Re: help speeding up a query in postgres 8.4.5
  • From: Tomas Vondra
• Re: help speeding up a query in postgres 8.4.5
  • From: Kevin Grittner
• Re: help speeding up a query in postgres 8.4.5
  • From: Maria L. Wilson
• Re: help speeding up a query in postgres 8.4.5
  • From: Maria L. Wilson
• Re: help speeding up a query in postgres 8.4.5
  • From: tv
• Re: help speeding up a query in postgres 8.4.5
  • From: Szymon Guz
• help speeding up a query in postgres 8.4.5
  • From: Maria L. Wilson
• Re: Postgres Performance Tuning
  • From: Ákos Gábriel
• Re: Partial index slower than regular index
  • From: Thom Brown
• Re: Partial index slower than regular index
  • From: Thom Brown
• Re: Which is better Index
  • From: Greg Smith
• Re: Partial index slower than regular index
  • From: Tom Lane
• Re: Partial index slower than regular index
  • From: Mark Kirkwood
• Re: Partial index slower than regular index
  • From: Mark Kirkwood
• Re: Partial index slower than regular index
  • From: Scott Marlowe
• Re: Partial index slower than regular index
  • From: Kenneth Marshall
• Partial index slower than regular index
  • From: Thom Brown
• Re: Intel SSDs that may not suck
  • From: Merlin Moncure
• Re: Which is better Index
  • From: Chetan Suttraway
• Re: Postgres Performance Tuning
  • From: Scott Marlowe
• Re: Postgres Performance Tuning
  • From: Adarsh Sharma
• Re: Postgres Performance Tuning
  • From: Scott Marlowe
• Re: Postgres Performance Tuning
  • From: Ákos Gábriel
• Which is better Index
  • From: Adarsh Sharma
• Re: Postgres Performance Tuning
  • From: Adarsh Sharma
• Re: Intel SSDs that may not suck
  • From: Greg Smith
• Re: Postgres Performance Tuning
  • From: Scott Marlowe
• Re: very long updates very small tables
  • From: Kevin Grittner
• Re: Postgres Performance Tuning
  • From: Raghavendra
• Re: Postgres Performance Tuning
  • From: Adarsh Sharma
• Re: Postgres Performance Tuning
  • From: tv
• Re: Postgres Performance Tuning
  • From: Scott Marlowe
• Re: Postgres Performance Tuning
  • From: Achilleas Mantzios
• Re: Postgres Performance Tuning
  • From: Adarsh Sharma
• Re: Postgres Performance Tuning
  • From: Scott Marlowe
• Re: Postgres Performance Tuning
  • From: Adarsh Sharma
• Re: Postgres Performance Tuning
  • From: Raghavendra
• Re: Postgres Performance Tuning
  • From: Scott Marlowe
• Re: Postgres Performance Tuning
  • From: Sethu Prasad
• Re: Postgres Performance Tuning
  • From: Scott Marlowe
• Re: Postgres Performance Tuning
  • From: Adarsh Sharma
• Re: Postgres Performance Tuning
  • From: tv
• Postgres Performance Tuning
  • From: Adarsh Sharma
• Re: very long updates very small tables
  • From: Lars Feistner
• Re: C on Client versus C on Server
  • From: Heikki Linnakangas
• C on Client versus C on Server
  • From: Eliot Gable
• Re: table contraints checks only happen in planner phase
  • From: Josh Berkus
• Re: COPY with high # of clients, partitioned table locking issues?
  • From: Greg Smith
• Re: good old VACUUM FULL
  • From: Craig Ringer
• table contraints checks only happen in planner phase
  • From: Joseph Shraibman
• index usage on queries on inherited tables
  • From: Joseph Shraibman
• Re: Slow deleting tables with foreign keys
  • From: Jeremy Palmer
• Re: Calculating 95th percentiles
  • From: Landreville
• Why it is using/not using index scan?
  • From: Laszlo Nagy
• Re: COPY with high # of clients, partitioned table locking issues?
  • From: Maciek Sakrejda
• Re: Slow deleting tables with foreign keys
  • From: Bob Lunney
• Re: COPY with high # of clients, partitioned table locking issues?
  • From: Emanuel Calvo
• Slow deleting tables with foreign keys
  • From: Jeremy Palmer
• Re: COPY with high # of clients, partitioned table locking issues?
  • From: Samuel Gendler
• Re: COPY with high # of clients, partitioned table locking issues?
  • From: Bob Lunney
• COPY with high # of clients, partitioned table locking issues?
  • From: Strange, John W
• Re: very long updates very small tables
  • From: Kevin Grittner
• Re: very long updates very small tables
  • From: pasman pasmański
• Re: Why Index is not used
  • From: Greg Smith
• Re: very long updates very small tables
  • From: Lars Feistner
• Re: multiple table scan performance
  • From: Craig James
• Re: multiple table scan performance
  • From: Samuel Gendler
• Re: multiple table scan performance
  • From: Marti Raudsepp
• Re: multiple table scan performance
  • From: Claudio Freire
• multiple table scan performance
  • From: Samuel Gendler
• Re: Intel SSDs that may not suck
  • From: Jesper Krogh
• Re: very long updates very small tables
  • From: Kevin Grittner
• Re: Intel SSDs that may not suck
  • From: Greg Smith
• Re: Intel SSDs that may not suck
  • From: gnuoytr
• Re: Intel SSDs that may not suck
  • From: Jeff
• Re: Intel SSDs that may not suck
  • From: Jesper Krogh
• Re: Intel SSDs that may not suck
  • From: Strange, John W
• very long updates very small tables
  • From: Lars Feistner
• Re: Intel SSDs that may not suck
  • From: Jeff
• Re: Intel SSDs that may not suck
  • From: Cédric Villemain
• Re: Intel SSDs that may not suck
  • From: Jeff
• Re: Intel SSDs that may not suck
  • From: Yeb Havinga
• Re: Intel SSDs that may not suck
  • From: Justin Pitts
• Re: Analyze on temp table taking very long
  • From: Mahadevan, Mridula
• Re: Intel SSDs that may not suck
  • From: Scott Marlowe
• Re: Intel SSDs that may not suck
  • From: Jesper Krogh
• Re: Intel SSDs that may not suck
  • From: Merlin Moncure
• Re: Intel SSDs that may not suck
  • From: Andy
• Re: buffercache/bgwriter
  • From: Uwe Bartels
• Intel SSDs that may not suck
  • From: Greg Smith
• Re: Xeon twice the performance of opteron
  • From: Greg Smith
• Re: buffercache/bgwriter
  • From: Greg Smith
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Joshua Berkus
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Nathan Boley
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Scott Carey
• Re: Why Index is not used
  • From: Maciek Sakrejda
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Vitalii Tymchyshyn
• Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration
  • From: Strange, John W
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Tom Lane
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Tom Lane
• Re: Why Index is not used
  • From: Shaun Thomas
• Re: Slow query on CLUTER -ed tables
  • From: Laszlo Nagy
• Re: Why Index is not used
  • From: Adarsh Sharma
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Vitalii Tymchyshyn
• Re: Why Index is not used
  • From: tv
• Re: Why Index is not used
  • From: Chetan Suttraway
• Re: Why Index is not used
  • From: Adarsh Sharma
• Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration
  • From: Marti Raudsepp
• Re: Why Index is not used
  • From: Chetan Suttraway
• Re: Why Index is not used
  • From: Thomas Kellerer
• Re: Why Index is not used
  • From: Adarsh Sharma
• Re: Why Index is not used
  • From: Chetan Suttraway
• Re: Why Index is not used
  • From: Adarsh Sharma
• Re: Why Index is not used
  • From: Andreas Kretschmer
• Why Index is not used
  • From: Adarsh Sharma
• Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration
  • From: DM
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Claudio Freire
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Nathan Boley
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Merlin Moncure
• Re: maintenance_work_mem + create index
  • From: Euler Taveira de Oliveira
• Re: maintenance_work_mem + create index
  • From: Shaun Thomas
• Re: maintenance_work_mem + create index
  • From: Uwe Bartels
• Re: maintenance_work_mem + create index
  • From: Shaun Thomas
• Re: maintenance_work_mem + create index
  • From: Uwe Bartels
• Re: maintenance_work_mem + create index
  • From: Stephen Frost
• maintenance_work_mem + create index
  • From: Uwe Bartels
• Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration
  • From: Achilleas Mantzios
• Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration
  • From: Marti Raudsepp
• Re: buffercache/bgwriter
  • From: Uwe Bartels
• Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration
  • From: Achilleas Mantzios
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Віталій Тимчишин
• Re: Re-Reason of Slowness of Query
  • From: Adarsh Sharma
• pg9.0.3 explain analyze running very slow compared to a different box with much less configuration
  • From: DM
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Josh Berkus
• Re: Slow query on CLUTER -ed tables
  • From: Marti Raudsepp
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Claudio Freire
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Tom Lane
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Justin Pitts
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Claudio Freire
• Slow query on CLUTER -ed tables
  • From: Laszlo Nagy
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Josh Berkus
• Re: buffercache/bgwriter
  • From: Cédric Villemain
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Claudio Freire
• Shouldn't we have a way to avoid "risky" plans?
  • From: Josh Berkus
• Re: buffercache/bgwriter
  • From: Jeff Janes
• Re: buffercache/bgwriter
  • From: Uwe Bartels
• Re: buffercache/bgwriter
  • From: Jeff Janes
• Re: buffercache/bgwriter
  • From: Uwe Bartels
• Re: buffercache/bgwriter
  • From: Nicholson, Brad (Toronto, ON, CA)
• Re: buffercache/bgwriter
  • From: Uwe Bartels
• Re: buffercache/bgwriter
  • From: tv
• Re: Re-Reason of Slowness of Query
  • From: Shaun Thomas
• Re: Re-Reason of Slowness of Query
  • From: tv
• Re: buffercache/bgwriter
  • From: Uwe Bartels
• Re: Re-Reason of Slowness of Query
  • From: Shaun Thomas
• Re: buffercache/bgwriter
  • From: Jochen Erwied
• Re: good old VACUUM FULL
  • From: Shaun Thomas
• buffercache/bgwriter
  • From: Uwe Bartels
• Re: Re-Reason of Slowness of Query
  • From: tv
• Re: Re-Reason of Slowness of Query
  • From: Adarsh Sharma
• Re: Re-Reason of Slowness of Query
  • From: Adarsh Sharma
• Re: Re-Reason of Slowness of Query
  • From: Chetan Suttraway
• Re: Re-Reason of Slowness of Query
  • From: Vitalii Tymchyshyn
• Re: Re-Reason of Slowness of Query
  • From: Adarsh Sharma
• Re: Re-Reason of Slowness of Query
  • From: Chetan Suttraway
• Re: Re-Reason of Slowness of Query
  • From: Chetan Suttraway
• Re: Re-Reason of Slowness of Query
  • From: tv
• Re: Re-Reason of Slowness of Query
  • From: Vitalii Tymchyshyn
• Re: Re-Reason of Slowness of Query
  • From: Adarsh Sharma
• Re: Re-Reason of Slowness of Query
  • From: Vitalii Tymchyshyn
• Re: Re-Reason of Slowness of Query
  • From: Adarsh Sharma
• Re: Re-Reason of Slowness of Query
  • From: Vitalii Tymchyshyn
• Re-Reason of Slowness of Query
  • From: Adarsh Sharma
• Re: Reason of Slowness of query
  • From: Vitalii Tymchyshyn
• Re: Reason of Slowness of query
  • From: Chetan Suttraway
• Re: Reason of Slowness of query
  • From: Adarsh Sharma
• Re: Reason of Slowness of query
  • From: Vitalii Tymchyshyn
• Re: Reason of Slowness of query
  • From: Samuel Gendler
• Re: Reason of Slowness of query
  • From: Chetan Suttraway
• Reason of Slowness of query
  • From: Adarsh Sharma
• Re: good old VACUUM FULL
  • From: Scott Marlowe
• Re: ANTI-JOIN needs table, index scan not possible?
  • From: Robert Haas
• Re: good old VACUUM FULL
  • From: Chris
• good old VACUUM FULL
  • From: felix
• Re: Analyze on temp table taking very long
  • From: Tom Lane
• Re: Performance on AIX
  • From: Josh Berkus
• Analyze on temp table taking very long
  • From: Mahadevan, Mridula
• Re: Help: massive parallel update to the same table
  • From: Red Maple
• Re: Request for feedback on hardware for a new database server
  • From: Merlin Moncure
• Re: Select in subselect vs select = any array
  • From: mark
• Re: REINDEX takes half a day (and still not complete!)
  • From: Scott Marlowe
• Re: REINDEX takes half a day (and still not complete!)
  • From: Merlin Moncure
• Re: Select in subselect vs select = any array
  • From: Pavel Stehule
• Re: Select in subselect vs select = any array
  • From: Adam Tistler
• Re: Select in subselect vs select = any array
  • From: Pavel Stehule
• Re: Select in subselect vs select = any array
  • From: Adam Tistler
• Re: REINDEX takes half a day (and still not complete!)
  • From: Phoenix Kiula
• Re: Select in subselect vs select = any array
  • From: Pavel Stehule
• Select in subselect vs select = any array
  • From: Adam Tistler
• Re: Fastest pq_restore?
  • From: bricklen
• Re: Performance on AIX
  • From: Andy Colson
• Performance on AIX
  • From: phb07
• Re: REINDEX takes half a day (and still not complete!)
  • From: Scott Marlowe
• Re: REINDEX takes half a day (and still not complete!)
  • From: Scott Marlowe
• REINDEX takes half a day (and still not complete!)
  • From: Phoenix Kiula
• Re: Request for feedback on hardware for a new database server
  • From: Scott Marlowe
• Re: Help: massive parallel update to the same table
  • From: Kevin Grittner
• Re: Fastest pq_restore?
  • From: Andy Colson
• Re: Help: massive parallel update to the same table
  • From: Red Maple
• Re: Request for feedback on hardware for a new database server
  • From: Scott Marlowe
• Re: Help: massive parallel update to the same table
  • From: Kevin Grittner
• Re: Request for feedback on hardware for a new database server
  • From: Claudio Freire
• Re: Help with Query Tuning
  • From: tv
• Re: Disabling nested loops - worst case performance
  • From: Claudio Freire
• Re: Fastest pq_restore?
  • From: Kevin Grittner
• Re: Help: massive parallel update to the same table
  • From: Nicholson, Brad (Toronto, ON, CA)
• Re: Help: massive parallel update to the same table
  • From: Kevin Grittner
• Help: massive parallel update to the same table
  • From: Red Maple
• Re: Help with Query Tuning
  • From: Reid Thompson
• Re: Request for feedback on hardware for a new database server
  • From: Arjen van der Meijden
• Re: Xeon twice the performance of opteron
  • From: Jeff
• Re: Disabling nested loops - worst case performance
  • From: Anssi Kääriäinen
• Re: Disabling nested loops - worst case performance
  • From: Anssi Kääriäinen
• Re: Disabling nested loops - worst case performance
  • From: Thomas Kellerer
• Re: Disabling nested loops - worst case performance
  • From: Vitalii Tymchyshyn
• Re: Disabling nested loops - worst case performance
  • From: Anssi Kääriäinen
• Re: Request for feedback on hardware for a new database server
  • From: Scott Marlowe
• Re: Request for feedback on hardware for a new database server
  • From: Arjen van der Meijden
• Re: Disabling nested loops - worst case performance
  • From: Pavel Stehule
• Disabling nested loops - worst case performance
  • From: Anssi Kääriäinen
• Re: Request for feedback on hardware for a new database server
  • From: Jesper Krogh
• Re: Help with Query Tuning
  • From: Adarsh Sharma
• Re: Request for feedback on hardware for a new database server
  • From: Scott Marlowe
• Re: Request for feedback on hardware for a new database server
  • From: Steve Atkins
• Re: Xeon twice the performance of opteron
  • From: Scott Marlowe
• Re: Xeon twice the performance of opteron
  • From: mark
• Re: Fastest pq_restore?
  • From: Andy Colson
• Request for feedback on hardware for a new database server
  • From: Oliver Charles
• Fastest pq_restore?
  • From: Michael Andreasen
• Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Timothy Garnett
• Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Kevin Grittner
• Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Timothy Garnett
• Re: Xeon twice the performance of opteron
  • From: Craig James
• Re: Xeon twice the performance of opteron
  • From: Claudio Freire
• Re: Xeon twice the performance of opteron
  • From: J Sisson
• Xeon twice the performance of opteron
  • From: Jeff
• Re: Updating histogram_bounds after a delete
  • From: Kevin Grittner
• Re: Updating histogram_bounds after a delete
  • From: Tom Lane
• Re: Updating histogram_bounds after a delete
  • From: Kenneth Marshall
• Re: Updating histogram_bounds after a delete
  • From: Kevin Grittner
• Re: Updating histogram_bounds after a delete
  • From: Derrick Rice
• Re: pg_xlog size
  • From: Tech Madhu
• Re: Help with Query Tuning
  • From: tv
• Re: Help with Query Tuning
  • From: Adarsh Sharma
• Re: Help with Query Tuning
  • From: Adarsh Sharma
• Re: pg_xlog size
  • From: Fujii Masao
• Re: Updating histogram_bounds after a delete
  • From: Kevin Grittner
• Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Kevin Grittner
• Re: Updating histogram_bounds after a delete
  • From: Derrick Rice
• Updating histogram_bounds after a delete
  • From: Derrick Rice
• Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Claudio Freire
• Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Shaun Thomas
• Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Kevin Grittner
• Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Tom Lane
• Re: pg_xlog size
  • From: Euler Taveira de Oliveira
• Re: Help with Query Tuning
  • From: Reid Thompson
• Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Shaun Thomas
• Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Tom Lane
• Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Kevin Grittner
• Re: Help with Query Tuning
  • From: Kenneth Marshall
• Help with Query Tuning
  • From: Adarsh Sharma
• Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Timothy Garnett
• Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Timothy Garnett
• Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3
  • From: Timothy Garnett
• pg_xlog size
  • From: Tech Madhu
• Custom operator class costs
  • From: Ben Beecher
• big distinct clause vs. group by
  • From: Uwe Bartels
• Re: Table partitioning problem
  • From: Samba GUEYE
• Re: Table partitioning problem
  • From: Shaun Thomas
• Re: Index use difference betweer LIKE, LIKE ANY?
  • From: Chetan Suttraway
• Re: Table partitioning problem
  • From: Samba GUEYE
• Re: unexpected stable function behavior
  • From: Julius Tuskenis
• Re: unexpected stable function behavior
  • From: Julius Tuskenis
• Re: Bug in the planner?
  • From: Tom Lane
• Re: Performance regression from 8.3.7 to 9.0.3
  • From: Merlin Moncure
• Re: Table partitioning problem
  • From: Conor Walsh
• Re: Table partitioning problem
  • From: Robert Haas
• Re: Performance regression from 8.3.7 to 9.0.3
  • From: Tom Lane
• Re: Performance regression from 8.3.7 to 9.0.3
  • From: Merlin Moncure
• Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1
  • From: Tom Lane
• Bug in the planner?
  • From: Claudio Freire
• Re: unexpected stable function behavior
  • From: Tom Lane
• Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1
  • From: John Surcombe
• Re: unexpected stable function behavior
  • From: Julius Tuskenis
• Re: Table partitioning problem
  • From: Samba GUEYE
• Re: Tuning massive UPDATES and GROUP BY's?
  • From: runner
• Re: Performance regression from 8.3.7 to 9.0.3
  • From: Claudio Freire
• Re: unexpected stable function behavior
  • From: Andres Freund
• Re: unexpected stable function behavior
  • From: Merlin Moncure
• Re: Tuning massive UPDATES and GROUP BY's?
  • From: Greg Spiegelberg
• Re: Tuning massive UPDATES and GROUP BY's?
  • From: Marti Raudsepp
• Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1
  • From: Tom Lane
• Re: Tuning massive UPDATES and GROUP BY's?
  • From: runner
• Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1
  • From: Tom Lane
• Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1
  • From: Jeremy
• Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1
  • From: John Surcombe
• Re: Tuning massive UPDATES and GROUP BY's?
  • From: Marti Raudsepp
• Re: ANTI-JOIN needs table, index scan not possible?
  • From: Kevin Grittner
• Re: ANTI-JOIN needs table, index scan not possible?
  • From: Kenneth Marshall
• Re: ANTI-JOIN needs table, index scan not possible?
  • From: hans wulf
• Re: Tuning massive UPDATES and GROUP BY's?
  • From: fork
• Re: Table partitioning problem
  • From: Robert Haas
• Re: ANTI-JOIN needs table, index scan not possible?
  • From: Maciek Sakrejda
• Re: big joins not converging
  • From: fork
• ANTI-JOIN needs table, index scan not possible?
  • From: hans wulf
• Re: NULLS LAST performance
  • From: Robert Haas
• Re: big joins not converging
  • From: Dan Ancona
• Re: big joins not converging
  • From: fork
• Re: Tuning massive UPDATES and GROUP BY's?
  • From: Marti Raudsepp
• Re: big joins not converging
  • From: Steve Atkins
• big joins not converging
  • From: Dan Ancona
• Re: unexpected stable function behavior
  • From: Merlin Moncure
• Re: Tuning massive UPDATES and GROUP BY's?
  • From: fork
• Re: Basic performance tuning on dedicated server
  • From: Merlin Moncure
• Basic performance tuning on dedicated server
  • From: runner
• unexpected stable function behavior
  • From: Julius Tuskenis
• Re: Tuning massive UPDATES and GROUP BY's?
  • From: Merlin Moncure
• Re: NULLS LAST performance
  • From: Merlin Moncure
• Tuning massive UPDATES and GROUP BY's?
  • From: fork
• Re: NULLS LAST performance
  • From: Robert Haas
• Re: Performance trouble finding records through related records
  • From: sverhagen
• Re: Table partitioning problem
  • From: Samba GUEYE
• Re: NULLS LAST performance
  • From: Jim Nasby
• Re: Slow join on partitioned table
  • From: Conor Walsh
• Re: Table partitioning problem
  • From: Jim Nasby
• Re: Query performance with disabled hashjoin and mergejoin
  • From: Robert Haas
• Re: Query performance with disabled hashjoin and mergejoin
  • From: Merlin Moncure
• Re: Query performance with disabled hashjoin and mergejoin
  • From: Tom Lane
• Re: Query performance with disabled hashjoin and mergejoin
  • From: Robert Haas
• Re: Performance issues
  • From: Andy Colson
• Re: Linux I/O schedulers - CFQ & random seeks
  • From: Mindaugas Riauba
• Re: Performance issues
  • From: Andreas Forø Tollefsen
• Re: Performance issues
  • From: Andreas Forø Tollefsen
• Table partitioning problem
  • From: Samba GUEYE
• Re: Performance issues
  • From: Andy Colson
• Re: Performance trouble finding records through related records
  • From: sverhagen
• Re: Performance trouble finding records through related records
  • From: sverhagen
• Re: Performance issues
  • From: Andreas Forø Tollefsen
• Re: [GENERAL] How to tune this query
  • From: Jaiswal Dhaval Sudhirkumar
• How to tune this query
  • From: Adarsh Sharma
• Re: Performance issues
  • From: Tom Lane
• Re: Performance issues
  • From: David Kerr
• Re: Performance issues
  • From: Andreas Forø Tollefsen
• Re: Query performance with disabled hashjoin and mergejoin
  • From: Merlin Moncure
• Re: Performance trouble finding records through related records
  • From: Merlin Moncure
• Re: plan variations: join vs. exists vs. row comparison
  • From: Kevin Grittner
• Re: plan variations: join vs. exists vs. row comparison
  • From: Jon Nelson
• Re: plan variations: join vs. exists vs. row comparison
  • From: Merlin Moncure
• Re: plan variations: join vs. exists vs. row comparison
  • From: Tom Lane
• Re: Performance trouble finding records through related records
  • From: Robert Haas
• plan variations: join vs. exists vs. row comparison
  • From: Jon Nelson
• Re: Anyone tried Flashcache with PostgreSQL?
  • From: Cédric Villemain
• Re: Performance issues
  • From: Oleg Bartunov
• Re: Performance issues
  • From: Andreas Forø Tollefsen
• Re: Performance issues
  • From: Kenneth Marshall
• Re: Performance issues
  • From: Andreas Forø Tollefsen
• Re: Performance issues
  • From: Kenneth Marshall
• Performance issues
  • From: Andreas Forø Tollefsen
• Re: Table partitioning
  • From: Mark Thornton
• Re: Linux I/O schedulers - CFQ & random seeks
  • From: Omar Kilani
• Re: Calculating 95th percentiles
  • From: marcin mank
• Re: Table partitioning
  • From: Tobias Brox
• Re: Table partitioning
  • From: Mark Thornton
• Table partitioning
  • From: Tobias Brox
• Re: Calculating 95th percentiles
  • From: Pierre C
• Re: Linux I/O schedulers - CFQ & random seeks
  • From: Rosser Schwarz
• Re: Linux I/O schedulers - CFQ & random seeks
  • From: Kevin Grittner
• Re: Linux I/O schedulers - CFQ & random seeks
  • From: Scott Marlowe
• Re: Linux I/O schedulers - CFQ & random seeks
  • From: Dan Harris
• Re: Slow join on partitioned table
  • From: Robert Haas
• Re: Linux I/O schedulers - CFQ & random seeks
  • From: Wayne Conrad
• Linux I/O schedulers - CFQ & random seeks
  • From: Glyn Astill
• Re: Slow join on partitioned table
  • From: Mark Thornton
• Re: Slow join on partitioned table
  • From: Mark Thornton
• Re: Slow join on partitioned table
  • From: Robert Haas
• Calculating 95th percentiles
  • From: Landreville
• Re: Is it require further tuning
  • From: Robert Haas
• Re: Slowing UPDATEs inside a transaction
  • From: Merlin Moncure
• Re: Slowing UPDATEs inside a transaction
  • From: Robert Haas
• Re: Vacuum problem due to temp tables
  • From: Robert Haas
• Slow join on partitioned table
  • From: Mark Thornton
• Re: Vacuum problem due to temp tables
  • From: Vidhya Bondre
• Re: Slowing UPDATEs inside a transaction
  • From: Matt Burke
• Re: Slowing UPDATEs inside a transaction
  • From: Merlin Moncure
• Re: Performance trouble finding records through related records
  • From: Andy Colson
• Re: Slowing UPDATEs inside a transaction
  • From: Robert Haas
• Slowing UPDATEs inside a transaction
  • From: Matt Burke
• Re: Performance trouble finding records through related records
  • From: sverhagen