Postgres Performance Date Index

• Thread Index

• Re: Benchmarking a large server
  • From: Claudio Freire
• Re: Postgres 9.0.4 + Hot Standby + FusionIO Drive + Performance => Query failed ERROR: catalog is missing 1 attribute(s) for relid 172226
  • From: Sethu Prasad
• 8.2.13 commit is taking too much time
  • From: AI Rumman
• Re: Benchmarking a large server
  • From: Yeb Havinga
• Re: Benchmarking a large server
  • From: Greg Smith
• partition query on multiple cores
  • From: Didik Prasetyo
• Re: Postgres refusing to use >1 core
  • From: Craig Ringer
• Re: Benchmarking a large server
  • From: Shaun Thomas
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: Postgres refusing to use >1 core
  • From: Merlin Moncure
• Re: Postgres refusing to use >1 core
  • From: Scott Marlowe
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: Benchmarking a large server
  • From: david
• Re: Benchmarking a large server
  • From: Greg Smith
• Re: Benchmarking a large server
  • From: David Boreham
• Re: Benchmarking a large server
  • From: Craig James
• Re: Benchmarking a large server
  • From: Cédric Villemain
• Re: Postgres 9.0.4 + Hot Standby + FusionIO Drive + Performance => Query failed ERROR: catalog is missing 1 attribute(s) for relid 172226
  • From: Josh Berkus
• Re: good performance benchmark
  • From: Josh Berkus
• Re: Postgres refusing to use >1 core
  • From: Greg Smith
• Re: Benchmarking a large server
  • From: Greg Smith
• Re: Postgres refusing to use >1 core
  • From: Kevin Grittner
• Re: Postgres refusing to use >1 core
  • From: Merlin Moncure
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: Postgres refusing to use >1 core
  • From: Kevin Grittner
• Re: Postgres refusing to use >1 core
  • From: Merlin Moncure
• Re: wildcard makes seq scan on prod db but not in test
  • From: Marcus Engene
• Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: Benchmarking a large server
  • From: David Boreham
• Re: Benchmarking a large server
  • From: Merlin Moncure
• Re: Benchmarking a large server
  • From: Shaun Thomas
• Re: Benchmarking a large server
  • From: Ben Chobot
• Re: Benchmarking a large server
  • From: David Boreham
• Re: Benchmarking a large server
  • From: Merlin Moncure
• good performance benchmark
  • From: Merlin Moncure
• Benchmarking a large server
  • From: Chris Hoover
• Re: wildcard makes seq scan on prod db but not in test
  • From: Kevin Grittner
• Re: wildcard makes seq scan on prod db but not in test
  • From: Marcus Engene
• Re: wildcard makes seq scan on prod db but not in test
  • From: Kevin Grittner
• Re: wildcard makes seq scan on prod db but not in test
  • From: Tom Lane
• wildcard makes seq scan on prod db but not in test
  • From: Marcus Engene
• Re: indexes ignored when querying the master table
  • From: Greg Smith
• Re: indexes ignored when querying the master table
  • From: Florian Weimer
• Re: Query improvement
  • From: Mark
• Re: Query improvement
  • From: Mark
• indexes ignored when querying the master table
  • From: Thomas Hägi
• Re: Query improvement
  • From: Mark
• Re: Postgres 9.0.4 + Hot Standby + FusionIO Drive + Performance => Query failed ERROR: catalog is missing 1 attribute(s) for relid 172226
  • From: Simon Riggs
• Re: REINDEX takes half a day (and still not complete!)
  • From: Merlin Moncure
• Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?
  • From: Dimitri
• Re: Poor query plan chosen in 9.0.3 vs 8.3.7
  • From: Tom Lane
• Re: Poor query plan chosen in 9.0.3 vs 8.3.7
  • From: Bosco Rama
• Re: Poor query plan chosen in 9.0.3 vs 8.3.7
  • From: Brian Connolly
• Re: ask the database engine tuning on the server
  • From: Kevin Grittner
• Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?
  • From: Robert Haas
• Poor query plan chosen in 9.0.3 vs 8.3.7
  • From: Brian Connolly
• Re: Explicit joins
  • From: Kevin Grittner
• Re: amazon ec2
  • From: Dave Page
• Re: Postgres 9.0.4 + Hot Standby + FusionIO Drive + Performance => Query failed ERROR: catalog is missing 1 attribute(s) for relid 172226
  • From: Sethu Prasad
• Explicit joins
  • From: Rishabh Kumar Jain
• ask the database engine tuning on the server
  • From: Didik Prasetyo
• Re: amazon ec2
  • From: Denis de Bernardy
• Re: amazon ec2
  • From: david
• Re: amazon ec2
  • From: Josh Berkus
• Re: Postgres 9.0.4 + Hot Standby + FusionIO Drive + Performance => Query failed ERROR: catalog is missing 1 attribute(s) for relid 172226
  • From: Josh Berkus
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Jim Nasby
• Re: row estimate very wrong for array type
  • From: Denis de Bernardy
• Re: row estimate very wrong for array type
  • From: Denis de Bernardy
• Re: row estimate very wrong for array type
  • From: Tom Lane
• Re: amazon ec2
  • From: Shaun Thomas
• row estimate very wrong for array type
  • From: Denis de Bernardy
• Re: REINDEX takes half a day (and still not complete!)
  • From: Jim Nasby
• Re: amazon ec2
  • From: Jim Nasby
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Willy-Bas Loos
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Jesper Krogh
• Re: Order of tables
  • From: Rishabh Kumar Jain
• Re: Order of tables
  • From: Rishabh Kumar Jain
• Re: Order of tables
  • From: Rishabh Kumar Jain
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Willy-Bas Loos
• Re: Order of tables
  • From: Rishabh Kumar Jain
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Jesper Krogh
• Re: amazon ec2
  • From: Greg Smith
• Re: amazon ec2
  • From: Greg Smith
• Re: amazon ec2
  • From: Josh Berkus
• Re: amazon ec2
  • From: david
• Re: amazon ec2
  • From: Mark Rostron
• Re: amazon ec2
  • From: Greg Spiegelberg
• Re: amazon ec2
  • From: Alan Hodgson
• Re: amazon ec2
  • From: Joel Reymont
• Re: amazon ec2
  • From: Alan Hodgson
• amazon ec2
  • From: Joel Reymont
• [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Willy-Bas Loos
• Re: pgpoolAdmin handling several pgpool-II clusters
  • From: Jorgen
• Re: Query improvement
  • From: Marc Mamin
• Postgres 9.0.4 + Hot Standby + FusionIO Drive + Performance => Query failed ERROR: catalog is missing 1 attribute(s) for relid 172226
  • From: Sethu Prasad
• Re: pgpoolAdmin handling several pgpool-II clusters
  • From: Magnus Hagander
• Re: Query improvement
  • From: Claudio Freire
• Re: pgpoolAdmin handling several pgpool-II clusters
  • From: Jorgen
• Re: Query improvement
  • From: Mark
• Re: 8.4.7, incorrect estimate
  • From: Wayne Conrad
• Re: 8.4.7, incorrect estimate
  • From: Kevin Grittner
• Re: The right SHMMAX and FILE_MAX
  • From: Greg Smith
• Re: 8.4.7, incorrect estimate
  • From: Tom Lane
• Re: 8.4.7, incorrect estimate
  • From: Wayne Conrad
• Re: The right SHMMAX and FILE_MAX
  • From: Adarsh Sharma
• Re: The right SHMMAX and FILE_MAX
  • From: Tomas Vondra
• Re: The right SHMMAX and FILE_MAX
  • From: Mark Kirkwood
• Re: Query improvement
  • From: Claudio Freire
• Query improvement
  • From: Mark
• Re: FUSION-IO io cards
  • From: Justin Pitts
• Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?
  • From: Hsien-Wen Chu
• Re: pgpoolAdmin handling several pgpool-II clusters
  • From: Tatsuo Ishii
• Re: The right SHMMAX and FILE_MAX
  • From: Adarsh Sharma
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Greg Smith
• Re: The right SHMMAX and FILE_MAX
  • From: Greg Smith
• Re: The right SHMMAX and FILE_MAX
  • From: Kevin Grittner
• Re: {Spam} Will shared_buffers crash a server
  • From: Marti Raudsepp
• The right SHMMAX and FILE_MAX
  • From: Phoenix Kiula
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Samuel Gendler
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Jeff Janes
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Joel Reymont
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Jeff Janes
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Joel Reymont
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Joel Reymont
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Kevin Grittner
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Kevin Grittner
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Joel Reymont
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Pierre C
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Joel Reymont
• Re: stored proc and inserting hundreds of thousands of rows
  • From: Kevin Grittner
• stored proc and inserting hundreds of thousands of rows
  • From: Joel Reymont
• Re: REINDEX takes half a day (and still not complete!)
  • From: Kenneth Marshall
• Re: REINDEX takes half a day (and still not complete!)
  • From: Phoenix Kiula
• Re: REINDEX takes half a day (and still not complete!)
  • From: Greg Smith
• Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?
  • From: Greg Smith
• Re: pgpoolAdmin handling several pgpool-II clusters
  • From: Tatsuo Ishii
• Re: Performance
  • From: Robert Haas
• Re: Performance
  • From: Robert Haas
• Re: index usage on queries on inherited tables
  • From: Robert Haas
• Re: Performance
  • From: Claudio Freire
• Re: Performance
  • From: Greg Smith
• Re: 8.4.7, incorrect estimate
  • From: Tom Lane
• Re: Performance
  • From: James Mansion
• Re: Performance
  • From: Andy Colson
• Re: 8.4.7, incorrect estimate
  • From: Kevin Grittner
• Re: FUSION-IO io cards
  • From: Joachim Worringen
• Re: 8.4.7, incorrect estimate
  • From: Kevin Grittner
• Re: FUSION-IO io cards
  • From: Greg Smith
• Re: Performance
  • From: Greg Smith
• 8.4.7, incorrect estimate
  • From: Wayne Conrad
• Re: FUSION-IO io cards
  • From: gnuoytr
• Re: FUSION-IO io cards
  • From: Joachim Worringen
• pgpoolAdmin handling several pgpool-II clusters
  • From: Jorgen
• Re: {Spam} Will shared_buffers crash a server
  • From: French, Martin
• Re: FUSION-IO io cards
  • From: Tyler Mills
• Re: FUSION-IO io cards
  • From: Ben Chobot
• Re: FUSION-IO io cards
  • From: gnuoytr
• Re: FUSION-IO io cards
  • From: Ivan Voras
• Re: FUSION-IO io cards
  • From: Stephen Cook
• FUSION-IO io cards
  • From: Mark Steben
• Re: Order of tables
  • From: Rishabh Kumar Jain
• Re: Will shared_buffers crash a server
  • From: Scott Marlowe
• Re: Performance
  • From: James Mansion
• Re: Will shared_buffers crash a server
  • From: Achilleas Mantzios
• Re: Will shared_buffers crash a server
  • From: Claudio Freire
• Will shared_buffers crash a server
  • From: Qiang Wang
• Re: Performance
  • From: Joshua Berkus
• Re: Performance
  • From: Tomas Vondra
• Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?
  • From: Greg Smith
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Jeff Janes
• Re: Order of tables
  • From: Heikki Linnakangas
• Re: Order of tables
  • From: Robert Klemme
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Samuel Gendler
• Order of tables
  • From: Rishabh Kumar Jain
• Re: Performance
  • From: Sethu Prasad
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Sok Ann Yap
• VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?
  • From: HSIEN-WEN CHU
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Sok Ann Yap
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Sok Ann Yap
• Re: index usage on queries on inherited tables
  • From: Greg Smith
• Re: index usage on queries on inherited tables
  • From: Samuel Gendler
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Kevin Grittner
• Re: Performance
  • From: Greg Smith
• Re: index usage on queries on inherited tables
  • From: Joseph Shraibman
• Re: Performance
  • From: Claudio Freire
• Re: Performance
  • From: Tomas Vondra
• Re: index usage on queries on inherited tables
  • From: Robert Haas
• Re: Performance
  • From: Robert Haas
• Re: Performance
  • From: Robert Haas
• Re: Performance
  • From: Kevin Grittner
• Re: Performance
  • From: Greg Smith
• Re: Query Performance with Indexes on Integer type vs. Date type.
  • From: Dhimant Patel
• Re: Query Performance with Indexes on Integer type vs. Date type.
  • From: Phoenix Kiula
• Re: Query Performance with Indexes on Integer type vs. Date type.
  • From: Kevin Grittner
• Re: Query Performance with Indexes on Integer type vs. Date type.
  • From: Maciek Sakrejda
• Re: Query Performance with Indexes on Integer type vs. Date type.
  • From: Tom Lane
• Query Performance with Indexes on Integer type vs. Date type.
  • From: Dhimant Patel
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Kevin Grittner
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Claudio Freire
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Claudio Freire
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Merlin Moncure
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Kevin Grittner
• reducing random_page_cost from 4 to 2 to force index scan
  • From: Sok Ann Yap
• Re: Performance
  • From: Tomas Vondra
• Re: Time to put theory to the test?
  • From: Josh Berkus
• Re: Time to put theory to the test?
  • From: Kenneth Marshall
• Re: Time to put theory to the test?
  • From: Magnus Hagander
• Re: Time to put theory to the test?
  • From: Tom Lane
• Re: Time to put theory to the test?
  • From: gnuoytr
• optimizing a cpu-heavy query
  • From: Joel Reymont
• tuning on ec2
  • From: Joel Reymont
• Re: Time to put theory to the test?
  • From: Scott Marlowe
• Re: Time to put theory to the test?
  • From: Kevin Grittner
• Re: Time to put theory to the test?
  • From: J Sisson
• Re: Performance
  • From: Claudio Freire
• Re: Time to put theory to the test?
  • From: Mark Kirkwood
• Re: Performance
  • From: Robert Haas
• Re: Performance
  • From: Robert Haas
• Re: Time to put theory to the test?
  • From: Rob Wultsch
• Re: Slow deleting tables with foreign keys
  • From: Robert Haas
• Re: %100 CPU on Windows Server 2003
  • From: Robert Haas
• Time to put theory to the test?
  • From: J Sisson
• Re: big distinct clause vs. group by
  • From: Uwe Bartels
• Re: Issue with partition elimination
  • From: Josh Berkus
• Re: big distinct clause vs. group by
  • From: Віталій Тимчишин
• Re: big distinct clause vs. group by
  • From: Uwe Bartels
• Re: How to configure a read-only database server?
  • From: Tomas Vondra
• Re: How to configure a read-only database server?
  • From: Stefan Keller
• Re: oom_killer
  • From: Tory M Blue
• Issue with partition elimination
  • From: Paul Pierce
• Re: REINDEX takes half a day (and still not complete!)
  • From: Robert Haas
• Re: big distinct clause vs. group by
  • From: Robert Haas
• Re: oom_killer
  • From: Robert Haas
• Re: Shouldn't we have a way to avoid "risky" plans?
  • From: Robert Haas
• Re: How to configure a read-only database server?
  • From: Robert Haas
• Re: not using partial index
  • From: Henry
• Re: OT (slightly) testing for data loss on an SSD drive due to power failure
  • From: Greg Smith
• Re: oom_killer
  • From: Claudio Freire
• Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1
  • From: Marinos Yannikos
• Re: oom_killer
  • From: Cédric Villemain
• Re: oom_killer
  • From: Tory M Blue
• Re: oom_killer
  • From: Tory M Blue
• Re: oom_killer
  • From: David Rees
• Re: oom_killer
  • From: Tory M Blue
• Re: oom_killer
  • From: Cédric Villemain
• Re: oom_killer
  • From: Cédric Villemain
• Re: oom_killer
  • From: Tory M Blue
• 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)