Postgres Performance Date Index

• Thread Index

• Re: query total time im milliseconds
  • From: Samuel Gendler
• query total time im milliseconds
  • From: Radhya sahal
• Re: INSERT query times
  • From: Tom Lane
• query total time im milliseconds
  • From: Radhya sahal
• Re: issue with query optimizer when joining two partitioned tables
  • From: Jeremy Harris
• Re: Memory usage of auto-vacuum
  • From: Gael Le Mignot
• Re: issue with query optimizer when joining two partitioned tables
  • From: Anish Kejariwal
• Re: INSERT query times
  • From: Pavel Stehule
• Re: GROUP BY with reasonable timings in PLAN but unreasonable execution time
  • From: Clem Dickey
• UPDATEDs slowing SELECTs in a fully cached database
  • From: lars
• Re: DELETE taking too much memory
  • From: Vincent de Phily
• Re: DELETE taking too much memory
  • From: French, Martin
• Re: [GENERAL] DELETE taking too much memory
  • From: Vincent de Phily
• Re: DELETE taking too much memory
  • From: Vincent de Phily
• Re: [GENERAL] DELETE taking too much memory
  • From: Vincent de Phily
• Very large record sizes and resource usage
  • From: jtkells
• "VACUUM FULL ANALYZE" vs. Autovacuum Contention
  • From: D C
• Re: DELETE taking too much memory
  • From: French, Martin
• INSERT query times
  • From: sergio mayoral
• Re: issue with query optimizer when joining two partitioned tables
  • From: Tom Lane
• Re: Memory usage of auto-vacuum
  • From: Tom Lane
• Re: Memory usage of auto-vacuum
  • From: Craig Ringer
• Re: Memory usage of auto-vacuum
  • From: Gael Le Mignot
• Re: Memory usage of auto-vacuum
  • From: Guillaume Lelarge
• Re: Memory usage of auto-vacuum
  • From: Gael Le Mignot
• Re: Memory usage of auto-vacuum
  • From: Guillaume Lelarge
• Re: Memory usage of auto-vacuum
  • From: Gael Le Mignot
• Re: Memory usage of auto-vacuum
  • From: Gael Le Mignot
• Re: Memory usage of auto-vacuum
  • From: Guillaume Lelarge
• Re: Memory usage of auto-vacuum
  • From: Craig Ringer
• Re: issue with query optimizer when joining two partitioned tables
  • From: Heikki Linnakangas
• Memory usage of auto-vacuum
  • From: Gael Le Mignot
• Re: Slow query when using ORDER BY *and* LIMIT
  • From: Pavel Stehule
• Re: Slow query when using ORDER BY *and* LIMIT
  • From: Pavel Stehule
• Re: execution time for first INSERT
  • From: Jeff Davis
• Re: Slow query when using ORDER BY *and* LIMIT
  • From: Jonathan
• issue with query optimizer when joining two partitioned tables
  • From: Anish Kejariwal
• Just a note about column equivalence disarming the planner
  • From: Shaun Thomas
• Re: "VACUUM FULL ANALYZE" vs. Autovacuum Contention
  • From: Greg Smith
• Re: "VACUUM FULL ANALYZE" vs. Autovacuum Contention
  • From: D C
• Re: Infinite Cache
  • From: Magnus Hagander
• Re: [GENERAL] DELETE taking too much memory
  • From: Jose Ildefonso Camargo Tolosa
• Re: Infinite Cache
  • From: Heikki Linnakangas
• execution time for first INSERT
  • From: Sergio Mayoral
• Re: [GENERAL] DELETE taking too much memory
  • From: Claudio Freire
• Re: [GENERAL] DELETE taking too much memory
  • From: Dean Rasheed
• Re: [GENERAL] DELETE taking too much memory
  • From: Dean Rasheed
• Re: "VACUUM FULL ANALYZE" vs. Autovacuum Contention
  • From: Greg Smith
• Re: "VACUUM FULL ANALYZE" vs. Autovacuum Contention
  • From: Scott Marlowe
• "VACUUM FULL ANALYZE" vs. Autovacuum Contention
  • From: D C
• Re: [GENERAL] DELETE taking too much memory
  • From: Guillaume Lelarge
• very large record sizes and ressource usage
  • From: jtkells
• DELETE taking too much memory
  • From: vincent dephily
• Re: 100% CPU Utilization when we run queries.
  • From: bakkiya
• Re: 100% CPU Utilization when we run queries.
  • From: Robert Klemme
• Re: GROUP BY with reasonable timings in PLAN but unreasonable execution time
  • From: Clem Dickey
• Re: 100% CPU Utilization when we run queries.
  • From: Craig Ringer
• Re: 100% CPU Utilization when we run queries.
  • From: Scott Marlowe
• Re: Query in 9.0.2 not using index in 9.0.0 works fine
  • From: Samuel Gendler
• Re: 100% CPU Utilization when we run queries.
  • From: Tomas Vondra
• Re: Query in 9.0.2 not using index in 9.0.0 works fine
  • From: Matthias Howell
• Re: 100% CPU Utilization when we run queries.
  • From: Kevin Grittner
• Re: 100% CPU Utilization when we run queries.
  • From: bakkiya
• Re: Query in 9.0.2 not using index in 9.0.0 works fine
  • From: Samuel Gendler
• Query in 9.0.2 not using index in 9.0.0 works fine
  • From: Matthias Howell
• GROUP BY with reasonable timings in PLAN but unreasonable execution time
  • From: Clem Dickey
• Slow query when using ORDER BY *and* LIMIT
  • From: Jonathan
• Re: bitmask index
  • From: Greg Smith
• Re: Postgres bulkload without transaction logs
  • From: Greg Smith
• Postgres bulkload without transaction logs
  • From: shouvik basu
• Re: Infinite Cache
  • From: Shaun Thomas
• Re: bitmask index
  • From: Marcus Engene
• Re: Infinite Cache
  • From: Greg Smith
• Re: Infinite Cache
  • From: Magnus Hagander
• Re: How can retrieve total query run-time with out using explain
  • From: Craig Ringer
• How can retrieve total query run-time with out using explain
  • From: Radhya sahal
• Re: Infinite Cache
  • From: Dave Page
• Re: near identical queries have vastly different plans
  • From: Samuel Gendler
• Re: near identical queries have vastly different plans
  • From: Tom Lane
• Re: Infinite Cache
  • From: Jim Nasby
• Re: Infinite Cache
  • From: Greg Smith
• Infinite Cache
  • From: Anthony Presley
• Re: is parallel union all possible over dblink?
  • From: Svetlin Manavski
• Re: near identical queries have vastly different plans
  • From: Samuel Gendler
• Re: Poor performance when joining against inherited tables
  • From: Robert Haas
• Re: is parallel union all possible over dblink?
  • From: Greg Spiegelberg
• Re: near identical queries have vastly different plans
  • From: Samuel Gendler
• near identical queries have vastly different plans
  • From: Samuel Gendler
• Re: sequential scan unduly favored over text search gin index
  • From: Jeff Janes
• Re: sequential scan unduly favored over text search gin index
  • From: Jeff Janes
• Re: is parallel union all possible over dblink?
  • From: Shaun Thomas
• Re: is parallel union all possible over dblink?
  • From: Greg Spiegelberg
• Re: is parallel union all possible over dblink?
  • From: Marinos Yannikos
• is parallel union all possible over dblink?
  • From: Svetlin Manavski
• Re: change sample size for statistics
  • From: Robert Haas
• Re: Slow performance when querying millions of rows
  • From: Greg Smith
• Re: Slow performance when querying millions of rows
  • From: Greg Smith
• Re: Slow performance when querying millions of rows
  • From: Tomas Vondra
• Re: Slow performance when querying millions of rows
  • From: Tomas Vondra
• Re: Slow performance when querying millions of rows
  • From: Craig McIlwee
• Re: Slow performance when querying millions of rows
  • From: Craig McIlwee
• Re: Slow performance when querying millions of rows
  • From: Greg Smith
• Re: Slow performance when querying millions of rows
  • From: Tomas Vondra
• Slow performance when querying millions of rows
  • From: Craig McIlwee
• Re: Long Running Update - My Solution
  • From: Harry Mantheakis
• Re: Long Running Update - My Solution
  • From: Greg Smith
• Fw: Getting rid of a seq scan in query on a large table
  • From: Denis de Bernardy
• Re: Performance issue with Insert
  • From: Kevin Grittner
• Re: Performance issue with Insert
  • From: Tomas Vondra
• Re: Performance issue with Insert
  • From: Jenish
• Re: Performance issue with Insert
  • From: Tomas Vondra
• Re: Performance issue with Insert
  • From: Tomas Vondra
• Re: Long Running Update - My Solution
  • From: Robert Klemme
• Re: Performance issue with Insert
  • From: Merlin Moncure
• Re: Performance issue with Insert
  • From: Jenish
• Re: Long Running Update - My Solution
  • From: tv
• Re: Performance issue with Insert
  • From: tv
• Re: Long Running Update - My Solution
  • From: Kevin Grittner
• Re: Long Running Update - My Solution
  • From: Harry Mantheakis
• Re: Performance issue with Insert
  • From: Jenish
• Re: Performance issue with Insert
  • From: Kevin Grittner
• Re: Getting rid of a seq scan in query on a large table
  • From: Kevin Grittner
• Performance issue with Insert
  • From: Jenish
• Getting rid of a seq scan in query on a large table
  • From: Jens Hoffrichter
• Re: Cost of creating an emply WAL segment
  • From: Greg Smith
• Re: Cost of creating an emply WAL segment
  • From: Shaun Thomas
• Re: Long Running Update
  • From: Harry Mantheakis
• Re: Long Running Update
  • From: Kevin Grittner
• Re: Long Running Update
  • From: Harry Mantheakis
• Re: Long Running Update
  • From: Harry Mantheakis
• Re: Cost of creating an emply WAL segment
  • From: Greg Smith
• Re: Long Running Update
  • From: Kevin Grittner
• Cost of creating an emply WAL segment
  • From: Devrim GÜNDÜZ
• Re: Long Running Update
  • From: Kevin Grittner
• Re: Long Running Update
  • From: Kevin Grittner
• Re: Long Running Update
  • From: Mark Thornton
• Re: Long Running Update
  • From: Harry Mantheakis
• Re: Long Running Update
  • From: Vitalii Tymchyshyn
• Re: Long Running Update
  • From: Claudio Freire
• Re: Long Running Update
  • From: Harry Mantheakis
• Re: Long Running Update
  • From: Harry Mantheakis
• Re: Improve the Postgres Query performance
  • From: Tripura
• Re: Long Running Update
  • From: Kevin Grittner
• Re: Long Running Update
  • From: Claudio Freire
• Long Running Update
  • From: Harry Mantheakis
• Re: bitmask index
  • From: Robert Klemme
• Re: bitmask index
  • From: Greg Smith
• Re: seq scan in the case of max() on the primary key column
  • From: Greg Smith
• bitmask index
  • From: Marcus Engene
• Re: seq scan in the case of max() on the primary key column
  • From: Shaun Thomas
• Re: seq scan in the case of max() on the primary key column
  • From: Scott Marlowe
• Re: seq scan in the case of max() on the primary key column
  • From: Greg Smith
• Re: Contemplating SSD Hardware RAID
  • From: Shaun Thomas
• Re: seq scan in the case of max() on the primary key column
  • From: Shaun Thomas
• Re: seq scan in the case of max() on the primary key column
  • From: Marti Raudsepp
• Re: Improve the Postgres Query performance
  • From: Craig Ringer
• Improve the Postgres Query performance
  • From: Tripura
• Re: Contemplating SSD Hardware RAID
  • From: Greg Smith
• Re: Contemplating SSD Hardware RAID
  • From: Merlin Moncure
• Re: Contemplating SSD Hardware RAID
  • From: Scott Marlowe
• Re: Contemplating SSD Hardware RAID
  • From: Yeb Havinga
• Re: Contemplating SSD Hardware RAID
  • From: Yeb Havinga
• Re: seq scan in the case of max() on the primary key column
  • From: Shaun Thomas
• Re: Contemplating SSD Hardware RAID
  • From: Anton Rommerskirchen
• Re: Contemplating SSD Hardware RAID
  • From: Greg Smith
• Re: Contemplating SSD Hardware RAID
  • From: Florian Weimer
• Re: Inoptimal query plan for max() and multicolumn index
  • From: F. BROUARD / SQLpro
• Re: Contemplating SSD Hardware RAID
  • From: Yeb Havinga
• Re: Contemplating SSD Hardware RAID
  • From: Yeb Havinga
• Re: Inoptimal query plan for max() and multicolumn index
  • From: Vladimir Kulev
• Re: Contemplating SSD Hardware RAID
  • From: Greg Smith
• Re: sequential scan unduly favored over text search gin index
  • From: Tom Lane
• Contemplating SSD Hardware RAID
  • From: Dan Harris
• Cross Table (Pivot)
  • From: Mario Guerrero
• Re: sequential scan unduly favored over text search gin index
  • From: Sushant Sinha
• Re: bad plan: 8.4.8, hashagg, work_mem=1MB.
  • From: Jon Nelson
• Re: how to know slowly query in lock postgre
  • From: Tomas Vondra
• Re: sequential scan unduly favored over text search gin index
  • From: Tomas Vondra
• Re: sequential scan unduly favored over text search gin index
  • From: Jesper Krogh
• Re: bad plan: 8.4.8, hashagg, work_mem=1MB.
  • From: Tom Lane
• Re: sequential scan unduly favored over text search gin index
  • From: Sushant Sinha
• bad plan: 8.4.8, hashagg, work_mem=1MB.
  • From: Jon Nelson
• Re: sequential scan unduly favored over text search gin index
  • From: Kevin Grittner
• sequential scan unduly favored over text search gin index
  • From: Sushant Sinha
• Re: Inoptimal query plan for max() and multicolumn index
  • From: Kevin Grittner
• Re: how to know slowly query in lock postgre
  • From: Claudio Freire
• Re: generating a large XML document
  • From: Julius Tuskenis
• Re: generating a large XML document
  • From: Pavel Stehule
• how to know slowly query in lock postgre
  • From: Didik Prasetyo
• Re: generating a large XML document
  • From: Pavel Stehule
• Re: generating a large XML document
  • From: Julius Tuskenis
• Re: generating a large XML document
  • From: Julius Tuskenis
• Re: generating a large XML document
  • From: Samuel Gendler
• Re: generating a large XML document
  • From: Pavel Stehule
• Re: generating a large XML document
  • From: Julius Tuskenis
• Inoptimal query plan for max() and multicolumn index
  • From: Vladimir Kulev
• Re: Large rows number, and large objects
  • From: Jose Ildefonso Camargo Tolosa
• Re: Degrading PostgreSQL 8.4 write performance
  • From: Pierre C
• hstore - Implementation and performance issues around its operators
  • From: Stefan Keller
• Re: Large rows number, and large objects
  • From: Craig James
• Re: Large rows number, and large objects
  • From: Samuel Gendler
• Large rows number, and large objects
  • From: Jose Ildefonso Camargo Tolosa
• Re: seq scan in the case of max() on the primary key column
  • From: Jim Nasby
• Re: seq scan in the case of max() on the primary key column
  • From: Greg Smith
• Re: Degrading PostgreSQL 8.4 write performance
  • From: Greg Smith
• Re: Degrading PostgreSQL 8.4 write performance
  • From: Merlin Moncure
• Re: seq scan in the case of max() on the primary key column
  • From: Svetlin Manavski
• Degrading PostgreSQL 8.4 write performance
  • From: Kabu Taah
• Re: Performance advice for a new low(er)-power server
  • From: Merlin Moncure
• Re: seq scan in the case of max() on the primary key column
  • From: Shaun Thomas
• Re: Performance advice for a new low(er)-power server
  • From: jesper
• Re: Performance advice for a new low(er)-power server
  • From: Haestan
• Re: Performance advice for a new low(er)-power server
  • From: Haestan
• Re: Performance advice for a new low(er)-power server
  • From: Merlin Moncure
• Re: Performance advice for a new low(er)-power server
  • From: Greg Smith
• Re: Performance advice for a new low(er)-power server
  • From: Merlin Moncure
• Re: Performance advice for a new low(er)-power server
  • From: Scott Marlowe
• generating a large XML document
  • From: Julius Tuskenis
• Re: Performance advice for a new low(er)-power server
  • From: Greg Smith
• Re: seq scan in the case of max() on the primary key column
  • From: Shaun Thomas
• Re: Performance advice for a new low(er)-power server
  • From: Jesper Krogh
• Re: Performance advice for a new low(er)-power server
  • From: Merlin Moncure
• Re: seq scan in the case of max() on the primary key column
  • From: Magnus Hagander
• Re: seq scan in the case of max() on the primary key column
  • From: Jesper Krogh
• seq scan in the case of max() on the primary key column
  • From: Svetlin Manavski
• Performance advice for a new low(er)-power server
  • From: Haestan
• Re: 100% CPU Utilization when we run queries.
  • From: bakkiya
• Re: need to repeat the same condition on joined tables in order to choose the proper plan
  • From: Svetlin Manavski
• Re: need to repeat the same condition on joined tables in order to choose the proper plan
  • From: Robert Klemme
• Re: need to repeat the same condition on joined tables in order to choose the proper plan
  • From: Tom Lane
• need to repeat the same condition on joined tables in order to choose the proper plan
  • From: Svetlin Manavski
• Re: change sample size for statistics
  • From: Willy-Bas Loos
• Re: how much postgres can scale up?
  • From: Benjamin Krajmalnik
• Re: Triggering autovacuum
  • From: Scott Marlowe
• Re: Triggering autovacuum
  • From: Reuven M. Lerner
• Re: change sample size for statistics
  • From: Nathan Boley
• Re: change sample size for statistics
  • From: Josh Berkus
• Re: how much postgres can scale up?
  • From: Anibal David Acosta
• Re: how much postgres can scale up?
  • From: Greg Smith
• Re: how much postgres can scale up?
  • From: Pierre C
• Re: strange query plan with LIMIT
  • From: Claudio Freire
• Re: how much postgres can scale up?
  • From: Pierre C
• Re: how much postgres can scale up?
  • From: Anibal David Acosta
• Re: how much postgres can scale up?
  • From: Craig Ringer
• Re: how much postgres can scale up?
  • From: Craig Ringer
• Re: how much postgres can scale up?
  • From: Anibal David Acosta
• Re: 100% CPU Utilization when we run queries.
  • From: Craig Ringer
• change sample size for statistics
  • From: Willy-Bas Loos
• Re: how much postgres can scale up?
  • From: tv
• how much postgres can scale up?
  • From: Anibal David Acosta
• Re: strange query plan with LIMIT
  • From: tv
• Re: [GENERAL] [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Robert Klemme
• Re: 100% CPU Utilization when we run queries.
  • From: Marti Raudsepp
• Re: strange query plan with LIMIT
  • From: anthony . shipman
• Re: 100% CPU Utilization when we run queries.
  • From: bakkiya
• Re: Oracle v. Postgres 9.0 query performance
  • From: Tom Lane
• Re: Oracle v. Postgres 9.0 query performance
  • From: Tatsuo Ishii
• Re: [GENERAL] [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Greg Smith
• Re: Triggering autovacuum
  • From: Greg Smith
• Re: Postgresql on itanium server
  • From: Tom Lane
• Triggering autovacuum
  • From: Reuven M. Lerner
• Re: Postgresql on itanium server
  • From: Jochen Erwied
• Re: poor performance when recreating constraints on large tables
  • From: Samuel Gendler
• Re: [PERFORMANCE] expanding to SAN: which portion best to move
  • From: Willy-Bas Loos
• Re: Postgresql on itanium server
  • From: Marti Raudsepp
• Re: Postgresql on itanium server
  • From: Jochen Erwied
• Re: Postgresql on itanium server
  • From: muthu krishnan
• Re: Postgresql on itanium server
  • From: Jochen Erwied
• Postgresql on itanium server
  • From: muthu krishnan
• Re: enable database user login/logout information
  • From: Alexander Shulgin
• enable database user login/logout information
  • From: muthu krishnan
• Re: strange query plan with LIMIT
  • From: anthony . shipman
• Re: strange query plan with LIMIT
  • From: anthony . shipman
• Re: poor performance when recreating constraints on large tables
  • From: Greg Smith
• Re: poor performance when recreating constraints on large tables
  • From: Claudio Freire
• Re: poor performance when recreating constraints on large tables
  • From: Samuel Gendler
• Re: Oracle v. Postgres 9.0 query performance
  • From: Tony Capobianco
• Re: poor performance when recreating constraints on large tables
  • From: Kevin Grittner
• Re: poor performance when recreating constraints on large tables
  • From: Samuel Gendler
• Re: Oracle v. Postgres 9.0 query performance
  • From: Samuel Gendler
• Re: Oracle v. Postgres 9.0 query performance
  • From: Kevin Grittner
• Re: poor performance when recreating constraints on large tables
  • From: Robert Haas
• 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: Tom Lane
• Re: Set of related slow queries
  • From: John Williams
• Re: Oracle v. Postgres 9.0 query performance
  • From: Tony Capobianco
• 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