Postgres Performance Date Index

• Thread Index

• Re: Oracle v. Postgres 9.0 query performance
  • From: Tony Capobianco
• Re: Oracle v. Postgres 9.0 query performance
  • From: Pavel Stehule
• Re: Oracle v. Postgres 9.0 query performance
  • From: Tony Capobianco
• Re: Oracle v. Postgres 9.0 query performance
  • From: Vitalii Tymchyshyn
• Re: Oracle v. Postgres 9.0 query performance
  • From: Stephen Frost
• Re: Oracle v. Postgres 9.0 query performance
  • From: Tony Capobianco
• Re: Oracle v. Postgres 9.0 query performance
  • From: Tom Lane
• Re: Oracle v. Postgres 9.0 query performance
  • From: tv
• Oracle v. Postgres 9.0 query performance
  • From: Tony Capobianco
• Re: Set of related slow queries
  • From: Shaun Thomas
• Re: Set of related slow queries
  • From: Craig Ringer
• Re: Set of related slow queries
  • From: tv
• Re: Set of related slow queries
  • From: tv
• Re: strange query plan with LIMIT
  • From: Pavel Stehule
• Re: strange query plan with LIMIT
  • From: tv
• Re: strange query plan with LIMIT
  • From: anthony . shipman
• Re: Set of related slow queries
  • From: Craig Ringer
• Set of related slow queries
  • From: John Williams
• Re: strange query plan with LIMIT
  • From: Pavel Stehule
• Re: strange query plan with LIMIT
  • From: anthony . shipman
• Re: strange query plan with LIMIT
  • From: tv
• Re: strange query plan with LIMIT
  • From: Claudio Freire
• Re: strange query plan with LIMIT
  • From: anthony . shipman
• Re: 100% CPU Utilization when we run queries.
  • From: Craig Ringer
• 100% CPU Utilization when we run queries.
  • From: bakkiya
• Re: i want to ask monitory peformance memory postgresql with automatically
  • From: Marcos Ortiz
• Re: strange query plan with LIMIT
  • From: tv
• strange query plan with LIMIT
  • From: anthony . shipman
• Re: strange query plan with LIMIT
  • From: Pavel Stehule
• Re: i want to ask monitory peformance memory postgresql with automatically
  • From: Craig Ringer
• strange query plan with LIMIT
  • From: anthony . shipman
• Re: 8.4/9.0 simple query performance regression
  • From: Vitalii Tymchyshyn
• i want to ask monitory peformance memory postgresql with automatically
  • From: Didik Prasetyo
• Re: not exits slow compared to not in. (nested loops killing me)
  • From: mark
• Re: not exits slow compared to not in. (nested loops killing me)
  • From: Tom Lane
• Re: not exits slow compared to not in. (nested loops killing me)
  • From: Craig Ringer
• Re: 8.4/9.0 simple query performance regression
  • From: Tom Lane
• Re: poor performance when recreating constraints on large tables
  • From: Mike Broers
• 8.4/9.0 simple query performance regression
  • From: Josh Berkus
• not exits slow compared to not in. (nested loops killing me)
  • From: mark
• Re: poor performance when recreating constraints on large tables
  • From: Tom Lane
• poor performance when recreating constraints on large tables
  • From: Mike Broers
• Re: Different execution time for same plan
  • From: Kevin Grittner
• Re: Index use difference betweer LIKE, LIKE ANY?
  • From: Heikki Linnakangas
• Re: Index use difference betweer LIKE, LIKE ANY?
  • From: Heikki Linnakangas
• Re: Why we don't want hints Was: Slow count(*) again...
  • From: Robert Klemme
• Re: Why we don't want hints Was: Slow count(*) again...
  • From: pasman pasmański
• Re: Understanding Hash Join performance
  • From: Robert Haas
• Re: Problem query
  • From: CS DBA
• Re: Problem query
  • From: Kevin Grittner
• Re: Understanding Hash Join performance
  • From: Robert Haas
• Re: Understanding Hash Join performance
  • From: Claudio Freire
• Re: Problem query
  • From: Shaun Thomas
• Re: Problem query
  • From: Kevin Grittner
• Re: Problem query
  • From: Shaun Thomas
• Re: Problem query
  • From: Kevin Grittner
• Re: Understanding Hash Join performance
  • From: Kevin Grittner
• Re: Problem query
  • From: Kevin Grittner
• Re: Strange behavior of child table.
  • From: Jenish
• Re: Speeding up loops in pl/pgsql function
  • From: Reuven M. Lerner
• Re: Delete performance
  • From: Jarrod Chesney
• Re: CLUSTER versus a dedicated table
  • From: Merlin Moncure
• Re: Problem query
  • From: Merlin Moncure
• Re: CLUSTER versus a dedicated table
  • From: mark
• Understanding Hash Join performance
  • From: Robert James
• CLUSTER versus a dedicated table
  • From: Robert James
• Re: Problem query
  • From: CS DBA
• Re: Problem query
  • From: CS DBA
• Re: Problem query
  • From: Kevin Grittner
• Re: Problem query
  • From: Merlin Moncure
• Problem query
  • From: CS DBA
• Re: Strange behavior of child table.
  • From: Jeff Davis
• Re: Speeding up loops in pl/pgsql function
  • From: Merlin Moncure
• Re: Speeding up loops in pl/pgsql function
  • From: Reuven M. Lerner
• Re: Delete performance
  • From: Greg Smith
• Re: Delete performance
  • From: Jarrod Chesney
• Re: Delete performance
  • From: Craig Ringer
• Re: Hash Anti Join performance degradation
  • From: Cédric Villemain
• Re: Delete performance
  • From: Pierre C
• Re: Hash Anti Join performance degradation
  • From: Robert Haas
• Re: picking a filesystem
  • From: Samuel Gendler
• Re: picking a filesystem
  • From: Shaun Thomas
• picking a filesystem
  • From: Robert Haas
• Strange behavior of child table.
  • From: Jenish
• Re: The shared buffers challenge
  • From: Merlin Moncure
• Re: Delete performance
  • From: Grzegorz Jaśkiewicz
• Delete performance
  • From: Jarrod Chesney
• Re: The shared buffers challenge
  • From: Greg Smith
• Re: serveRAID M5014 SAS
  • From: Mark Kirkwood
• Re: serveRAID M5014 SAS
  • From: Grzegorz Jaśkiewicz
• Re: The shared buffers challenge
  • From: Jeff Davis
• Re: The shared buffers challenge
  • From: Mark Kirkwood
• Re: serveRAID M5014 SAS
  • From: Mark Kirkwood
• Re: The shared buffers challenge
  • From: Claudio Freire
• Re: The shared buffers challenge
  • From: Maciek Sakrejda
• Re: The shared buffers challenge
  • From: Robert Haas
• Re: The shared buffers challenge
  • From: Merlin Moncure
• Re: The shared buffers challenge
  • From: Greg Smith
• Re: The shared buffers challenge
  • From: Greg Smith
• Re: The shared buffers challenge
  • From: Kevin Grittner
• Re: The shared buffers challenge
  • From: Scott Carey
• Re: The shared buffers challenge
  • From: Merlin Moncure
• Re: serveRAID M5014 SAS
  • From: Kevin Grittner
• Re: Performance block size.
  • From: Ivan Voras
• Re: Is any effect other process performance after vaccumdb finished ?
  • From: Craig Ringer
• Is any effect other process performance after vaccumdb finished ?
  • From: Junghwe Kim
• Re: Hash Anti Join performance degradation
  • From: Craig Ringer
• Re: The shared buffers challenge
  • From: Samuel Gendler
• Re: serveRAID M5014 SAS
  • From: Mark Kirkwood
• Re: serveRAID M5014 SAS
  • From: Mark Kirkwood
• Re: serveRAID M5014 SAS
  • From: Greg Smith
• Re: The shared buffers challenge
  • From: Greg Smith
• Re: serveRAID M5014 SAS
  • From: Mark Kirkwood
• Performance block size.
  • From: Tory M Blue
• Re: Hash Anti Join performance degradation
  • From: Cédric Villemain
• Re: Hash Anti Join performance degradation
  • From: panam
• Re: The shared buffers challenge
  • From: Kevin Grittner
• Re: Hash Anti Join performance degradation
  • From: Kevin Grittner
• Re: LIMIT and UNION ALL
  • From: Tom Lane
• Re: LIMIT and UNION ALL
  • From: Dave Johansen
• Re: The shared buffers challenge
  • From: Merlin Moncure
• Re: The shared buffers challenge
  • From: Claudio Freire
• Re: Hash Anti Join performance degradation
  • From: panam
• Re: The shared buffers challenge
  • From: Merlin Moncure
• Re: The shared buffers challenge
  • From: Claudio Freire
• Re: The shared buffers challenge
  • From: Merlin Moncure
• Re: Speeding up loops in pl/pgsql function
  • From: Steve Crawford
• Re: The shared buffers challenge
  • From: Kevin Grittner
• Re: Hash Anti Join performance degradation
  • From: Kevin Grittner
• The shared buffers challenge
  • From: Merlin Moncure
• Re: Hash Anti Join performance degradation
  • From: Cédric Villemain
• Re: Speeding up loops in pl/pgsql function
  • From: Reuven M. Lerner
• Re: Speeding up loops in pl/pgsql function
  • From: Merlin Moncure
• Re: Hash Anti Join performance degradation
  • From: panam
• Re: Speeding up loops in pl/pgsql function
  • From: Merlin Moncure
• Re: FW: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Pierre C
• Re: Speeding up loops in pl/pgsql function
  • From: Jochen Erwied
• Re: serveRAID M5014 SAS
  • From: Grzegorz Jaśkiewicz
• Re: serveRAID M5014 SAS
  • From: Mark Kirkwood
• Re: serveRAID M5014 SAS
  • From: Grzegorz Jaśkiewicz
• Re: Speeding up loops in pl/pgsql function
  • From: Santhakumaran
• Re: "error with invalid page header" while vacuuming pgbench data
  • From: Craig Ringer
• Re: Hash Anti Join performance degradation
  • From: Craig Ringer
• Re: Speeding up loops in pl/pgsql function
  • From: Merlin Moncure
• Re: Speeding up loops in pl/pgsql function
  • From: Steve Crawford
• Re: FW: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Stefan Keller
• Re: serveRAID M5014 SAS
  • From: Mark Kirkwood
• Re: serveRAID M5014 SAS
  • From: Mark Kirkwood
• Re: Speeding up loops in pl/pgsql function
  • From: Reuven M. Lerner
• Re: "error with invalid page header" while vacuuming pgbench data
  • From: Scott Marlowe
• Re: FW: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Merlin Moncure
• Re: "error with invalid page header" while vacuuming pgbench data
  • From: John Rouillard
• Re: Speeding up loops in pl/pgsql function
  • From: Merlin Moncure
• Re: "error with invalid page header" while vacuuming pgbench data
  • From: Greg Smith
• Re: "error with invalid page header" while vacuuming pgbench data
  • From: Kevin Grittner
• Re: Speeding up loops in pl/pgsql function
  • From: Alex Hunsaker
• Re: Speeding up loops in pl/pgsql function
  • From: Pavel Stehule
• Re: Speeding up loops in pl/pgsql function
  • From: Alex Hunsaker
• Re: Speeding up loops in pl/pgsql function
  • From: Reuven M. Lerner
• Re: FW: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Pierre C
• Re: "error with invalid page header" while vacuuming pgbench data
  • From: John Rouillard
• Re: Hash Anti Join performance degradation
  • From: Kevin Grittner
• Speeding up loops in pl/pgsql function
  • From: Reuven M. Lerner
• Re: Hash Anti Join performance degradation
  • From: panam
• Re: serveRAID M5014 SAS
  • From: Kevin Grittner
• Re: serveRAID M5014 SAS
  • From: Greg Smith
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Vitalii Tymchyshyn
• serveRAID M5014 SAS
  • From: Grzegorz Jaśkiewicz
• Re: Performance degradation of inserts when database size grows
  • From: Santhakumaran
• Re: Hash Anti Join performance degradation
  • From: Craig Ringer
• Re: FW: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Stefan Keller
• Re: Performance degradation of inserts when database size grows
  • From: Greg Smith
• Re: Hash Anti Join performance degradation
  • From: Tom Lane
• Re: Performance degradation of inserts when database size grows
  • From: Tomas Vondra
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Greg Smith
• Re: Hash Anti Join performance degradation
  • From: panam
• Re: Hash Anti Join performance degradation
  • From: Cédric Villemain
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Vitalii Tymchyshyn
• Re: Hash Anti Join performance degradation
  • From: Craig Ringer
• Re: Performance degradation of inserts when database size grows
  • From: Terry Schmitt
• Hash Anti Join performance degradation
  • From: panam
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Robert Haas
• Re: postgres not use index, IN statement
  • From: Craig Ringer
• Re: "error with invalid page header" while vacuuming pgbench data
  • From: Kevin Grittner
• "error with invalid page header" while vacuuming pgbench data
  • From: John Rouillard
• postgres not use index, IN statement
  • From: Anibal David Acosta
• Re: Pushing LIMIT into sub-queries of a UNION ALL?
  • From: Josh Berkus
• Re: Pushing LIMIT into sub-queries of a UNION ALL?
  • From: Robert Klemme
• Re: Performance degradation of inserts when database size grows
  • From: Tomas Vondra
• Re: Performance degradation of inserts when database size grows
  • From: Robert Haas
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Josh Berkus
• Re: Performance degradation of inserts when database size grows
  • From: Robert Haas
• Re: Performance degradation of inserts when database size grows
  • From: Tomas Vondra
• Logfile
  • From: Nick Raj
• Re: SORT performance - slow?
  • From: Tomas Vondra
• Re: SORT performance - slow?
  • From: Robert Haas
• Re: Pushing LIMIT into sub-queries of a UNION ALL
  • From: Robert Haas
• Re: FW: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Robert Haas
• Re: SORT performance - slow?
  • From: Maciek Sakrejda
• Re: Pushing LIMIT into sub-queries of a UNION ALL?
  • From: Dave Johansen
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: Performance degradation of inserts when database size grows
  • From: Shaun Thomas
• Re: [OT]: Confidentiality disclosures in list posts (Was: SORT performance - slow?)
  • From: Shaun Thomas
• Re: FW: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Pierre C
• Re: Postgres refusing to use >1 core
  • From: Craig Ringer
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: SORT performance - slow?
  • From: Tomas Vondra
• Re: Pushing LIMIT into sub-queries of a UNION ALL?
  • From: Robert Klemme
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: Performance degradation of inserts when database size grows
  • From: Leonardo Francalanci
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• [OT]: Confidentiality disclosures in list posts (Was: SORT performance - slow?)
  • From: Lew
• FW: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: m1ott
• Re: Modifying shared_buffers causes despite plenty of ram
  • From: STA
• Modifying shared_buffers causes despite plenty of ram
  • From: STA
• Re: Modifying shared_buffers causes despite plenty of ram
  • From: STA
• Pushing LIMIT into sub-queries of a UNION ALL?
  • From: Dave Johansen
• Performance degradation of inserts when database size grows
  • From: Andrey Vorobiev
• Pushing LIMIT into sub-queries of a UNION ALL
  • From: Dave Johansen
• Re: SORT performance - slow?
  • From: Kevin Grittner
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Cédric Villemain
• Re: SORT performance - slow?
  • From: Samuel Gendler
• SORT performance - slow?
  • From: Strange, John W
• Re: Link error when use Pgtypes function in windows
  • From: Robert Haas
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Robert Haas
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Jim Nasby
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Robert Haas
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Greg Smith
• Re: hash semi join caused by "IN (select ...)"
  • From: Scott Carey
• Re: LIMIT and UNION ALL
  • From: Robert Klemme
• Re: LIMIT and UNION ALL
  • From: Pavel Stehule
• LIMIT and UNION ALL
  • From: Dave Johansen
• Re: hash semi join caused by "IN (select ...)"
  • From: Dave Johansen
• Re: hash semi join caused by "IN (select ...)"
  • From: Clemens Eisserer
• Re: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Jim Nasby
• Re: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Stefan Keller
• Re: Using pgiosim realistically
  • From: John Rouillard
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Jim Nasby
• Re: Fill Factor
  • From: Cédric Villemain
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Robert Klemme
• Re: Fill Factor
  • From: Scott Marlowe
• Fill Factor
  • From: Anibal David Acosta
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Cédric Villemain
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Craig Ringer
• Re: hash semi join caused by "IN (select ...)"
  • From: Clemens Eisserer
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Robert Klemme
• Re: hash semi join caused by "IN (select ...)"
  • From: Dave Johansen
• Re: hash semi join caused by "IN (select ...)"
  • From: Tom Lane
• hash semi join caused by "IN (select ...)"
  • From: Clemens Eisserer
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Tom Lane
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Nathan Boley
• Re: Using pgiosim realistically
  • From: Jeff
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Tom Lane
• Re: Using pgiosim realistically
  • From: John Rouillard
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Jeff Janes
• Re: Using pgiosim realistically
  • From: Jeff
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Tom Lane
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Robert Haas
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Robert Haas
• Re: Why query takes soo much time
  • From: Tom Lane
• Re: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Merlin Moncure
• Re: Using pgiosim realistically
  • From: John Rouillard
• Re: Why query takes soo much time
  • From: Denis de Bernardy
• Re: Why query takes soo much time
  • From: Craig Ringer
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Robert Klemme
• Why query takes soo much time
  • From: Adarsh Sharma
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Jesper Krogh
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Jesper Krogh
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Greg Smith
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Craig Ringer
• Re: KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Craig Ringer
• Re: slow loop inserts?
  • From: Dan Birken
• slow loop inserts?
  • From: Ezequiel Lovelle
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Cédric Villemain
• Re: DBT-5 & Postgres 9.0.3
  • From: Robert Haas
• Re: Postgres 9.0.4 + Hot Standby + FusionIO Drive + Performance => Query failed ERROR: catalog is missing 1 attribute(s) for relid 172226
  • From: Robert Haas
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Robert Haas
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Josh Berkus
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Josh Berkus
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Stuart Bishop
• Re: Using pgiosim realistically
  • From: ktm@xxxxxxxx
• KVP table vs. hstore - hstore performance (Was: Postgres NoSQL emulation)
  • From: Stefan Keller
• Re: Query improvement
  • From: Robert Haas
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Robert Haas
• Using pgiosim realistically
  • From: John Rouillard
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Cédric Villemain
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Josh Berkus
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Robert Haas
• Re: reducing random_page_cost from 4 to 2 to force index scan
  • From: Tom Lane
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Robert Haas
• 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: Robert Haas
• Re: Link error when use Pgtypes function in windows
  • From: Maciek Sakrejda
• Link error when use Pgtypes function in windows
  • From: Fanbin Meng
• Re: How to avoid seq scans for joins between union-all views (test case included)
  • From: Fredrik Widlert
• Re: How to avoid seq scans for joins between union-all views (test case included)
  • From: Cédric Villemain
• Re: How to avoid seq scans for joins between union-all views (test case included)
  • From: Denis de Bernardy
• How to avoid seq scans for joins between union-all views (test case included)
  • From: Fredrik Widlert
• Re: setting configuration values inside a stored proc
  • From: Samuel Gendler
• Re: [ADMIN] since when has pg_stat_user_indexes.idx_scan been counting?
  • From: tv
• Re: setting configuration values inside a stored proc
  • From: Andres Freund
• Re: [ADMIN] since when has pg_stat_user_indexes.idx_scan been counting?
  • From: Greg Smith
• Re: Checkpoint execution overrun impact?
  • From: Greg Smith
• Re: tuning on ec2
  • From: Josh Berkus
• Re: 'Interesting' prepared statement slowdown on large table join
  • From: Jeff Janes
• setting configuration values inside a stored proc
  • From: Samuel Gendler
• Re: Poor performance when joining against inherited tables
  • From: Maciek Sakrejda
• Re: [ADMIN] since when has pg_stat_user_indexes.idx_scan been counting?
  • From: Tomas Vondra
• Re: [ADMIN] since when has pg_stat_user_indexes.idx_scan been counting?
  • From: raghu ram
• Re: Poor performance when joining against inherited tables
  • From: Lucas Madar
• Re: since when has pg_stat_user_indexes.idx_scan been counting?
  • From: Tom Lane
• Re: since when has pg_stat_user_indexes.idx_scan been counting?
  • From: Greg Smith
• Re: [ADMIN] since when has pg_stat_user_indexes.idx_scan been counting?
  • From: Willy-Bas Loos
• Re: 'Interesting' prepared statement slowdown on large table join
  • From: Prodan, Andrei
• Re: Postgres refusing to use >1 core
  • From: Shaun Thomas
• Re: Postgres refusing to use >1 core
  • From: Tom Lane
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: Postgres refusing to use >1 core
  • From: Aren Cambre
• Re: since when has pg_stat_user_indexes.idx_scan been counting?
  • From: Tomas Vondra
• Re: since when has pg_stat_user_indexes.idx_scan been counting?
  • From: Tomas Vondra
• Re: Postgres refusing to use >1 core
  • From: Eric McKeeth
• Re: Postgres refusing to use >1 core
  • From: Shaun Thomas
• since when has pg_stat_user_indexes.idx_scan been counting?
  • From: Willy-Bas Loos
• Re: Postgres refusing to use >1 core
  • From: Tom Lane
• Re: Postgres refusing to use >1 core
  • From: Shaun Thomas
• Re: Postgres refusing to use >1 core
  • From: Michael Graham
• Re: Postgres refusing to use >1 core
  • From: Vitalii Tymchyshyn
• Re: DBT-5 & Postgres 9.0.3
  • From: Sethu Prasad
• Re: Postgres refusing to use >1 core
  • From: David Boreham
• Re: tuning on ec2
  • From: Robert Haas
• Re: Checkpoint execution overrun impact?
  • From: Robert Haas
• Re: Postgres refusing to use >1 core
  • From: Scott Marlowe
• Re: DBT-5 & Postgres 9.0.3
  • From: Robert Haas
• Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
  • From: Robert Haas
• 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: Aren Cambre
• Re: Postgres refusing to use >1 core
  • From: Josh Berkus
• Re: Postgres refusing to use >1 core
  • From: gnuoytr
• Re: Postgres refusing to use >1 core
  • From: Shaun Thomas
• Re: Postgres refusing to use >1 core
  • From: Scott Marlowe
• Re: Postgres refusing to use >1 core
  • From: gnuoytr
• Re: Postgres refusing to use >1 core
  • From: Shaun Thomas
• Re: 'Interesting' prepared statement slowdown on large table join
  • From: Jeff Janes
• Re: Postgres refusing to use >1 core
  • From: Pierre C
• Re: Poor performance when joining against inherited tables
  • From: Tom Lane
• Re: Poor performance when joining against inherited tables
  • From: Robert Haas
• Re: 'Interesting' prepared statement slowdown on large table join
  • From: Tom Lane
• Re: 'Interesting' prepared statement slowdown on large table join
  • From: Shaun Thomas
• Re: help speeding up a query in postgres 8.4.5
  • From: Tom Lane
• Re: partition query on multiple cores
  • From: Mason S
• Re: help speeding up a query in postgres 8.4.5
  • From: Robert Haas
• Re: partition query on multiple cores
  • From: Mason S
• Re: Postgres NoSQL emulation
  • From: Pierre C
• 'Interesting' prepared statement slowdown on large table join
  • From: Prodan, Andrei
• Re: Postgres refusing to use >1 core
  • From: Pierre C
• Re: help speeding up a query in postgres 8.4.5
  • From: Scott Marlowe
• 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: Postgres refusing to use >1 core
  • From: Scott Marlowe
• Re: Postgres NoSQL emulation
  • From: Scott Marlowe
• Re: Postgres refusing to use >1 core
  • From: Craig Ringer
• Re: Postgres refusing to use >1 core
  • From: Craig Ringer
• Re: Postgres NoSQL emulation
  • From: Merlin Moncure
• Re: Question processor speed differences.
  • From: Greg Smith
• Postgres NoSQL emulation
  • From: Pierre C
• Re: partition query on multiple cores
  • From: Tomas Vondra
• Re: help speeding up a query in postgres 8.4.5
  • From: Robert Haas
• Re: Benchmarking a large server
  • From: Greg Smith
• Re: help speeding up a query in postgres 8.4.5
  • From: Robert Haas
• Question processor speed differences.
  • From: Tory M Blue
• Re: partition query on multiple cores
  • From: Shaun Thomas
• Re: partition query on multiple cores
  • From: Maciek Sakrejda
• Re: 8.2.13 commit is taking too much time
  • From: Greg Smith
• Re: Benchmarking a large server
  • From: Cédric Villemain
• Re: Benchmarking a large server
  • From: Jeff
• Re: Postgres refusing to use >1 core
  • From: Merlin Moncure
• Re: 8.2.13 commit is taking too much time
  • From: tv
• Re: indexes ignored when querying the master table
  • From: Thomas Hägi
• 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