Postgres Performance Date Index

• Thread Index

• merge join killing performance
  • From: Scott Marlowe
• Re: Slow Bulk Delete
  • From: Jon Nelson
• Re: Slow Bulk Delete
  • From: Grzegorz Jaśkiewicz
• Re: Slow Bulk Delete
  • From: Jon Nelson
• Re: Slow Bulk Delete
  • From: A. Kretschmer
• Re: Slow Bulk Delete
  • From: Grzegorz Jaśkiewicz
• Re: Slow Bulk Delete
  • From: Віталій Тимчишин
• Re: Slow Bulk Delete
  • From: Jon Nelson
• Re: old server, new server, same performance
  • From: Scott Marlowe
• Re: Slow Bulk Delete
  • From: Pierre C
• Re: old server, new server, same performance
  • From: Piotr Legiecki
• Re: old server, new server, same performance
  • From: Scott Marlowe
• Re: old server, new server, same performance
  • From: Scott Marlowe
• Re: old server, new server, same performance
  • From: Scott Marlowe
• Re: old server, new server, same performance
  • From: Piotr Legiecki
• Re: Benchmark with FreeBSD 8.0 and pgbench
  • From: Віталій Тимчишин
• pg_dump and pg_restore
  • From: Jayadevan M
• Re: Planner issue on sorting joining of two tables with limit
  • From: Robert Haas
• Re: Benchmark with FreeBSD 8.0 and pgbench
  • From: joao.pinheiro
• Re: Benchmark with FreeBSD 8.0 and pgbench
  • From: Josh Berkus
• Benchmark with FreeBSD 8.0 and pgbench
  • From: joao.pinheiro
• Re: old server, new server, same performance
  • From: Sarwani Dwinanto
• Re: old server, new server, same performance
  • From: Scott Carey
• Re: old server, new server, same performance
  • From: Scott Marlowe
• Re: old server, new server, same performance
  • From: Thom Brown
• old server, new server, same performance
  • From: Piotr Legiecki
• Re: Performance issues when the number of records are around 10 Million
  • From: venu madhav
• Re: Performance issues when the number of records are around 10 Million
  • From: venu madhav
• Re: Performance issues when the number of records are around 10 Million
  • From: venu madhav
• Re: Performance issues when the number of records are around 10 Million
  • From: venu madhav
• Re: Performance issues when the number of records are around 10 Million
  • From: venu madhav
• Re: old server, new server, same performance
  • From: Yeb Havinga
• Re: old server, new server, same performance
  • From: Scott Marlowe
• Re: old server, new server, same performance
  • From: Kevin Grittner
• old server, new server, same performance
  • From: Piotr Legiecki
• Re: Performance issues when the number of records are around 10 Million
  • From: Kevin Grittner
• Re: Slow Bulk Delete
  • From: Bob Lunney
• Re: Performance issues when the number of records are around 10 Million
  • From: Craig James
• Re: Performance issues when the number of records are around 10 Million
  • From: Kevin Grittner
• Re: Performance issues when the number of records are around 10 Million
  • From: Kevin Grittner
• Re: Performance issues when the number of records are around 10 Million
  • From: Josh Berkus
• Re: 8K recordsize bad on ZFS?
  • From: Josh Berkus
• Re: Performance issues when the number of records are around 10 Million
  • From: Shrirang Chitnis
• Re: Performance issues when the number of records are around 10 Million
  • From: Jorge Montero
• Re: Performance issues when the number of records are around 10 Million
  • From: Kevin Grittner
• Performance issues when the number of records are around 10 Million
  • From: venu madhav
• Re: Slow Bulk Delete
  • From: thilo
• Re: 8K recordsize bad on ZFS?
  • From: Jignesh Shah
• Slow Bulk Delete
  • From: thilo
• Re: Function scan/Index scan to nested loop
  • From: Carlo Stonebanks
• Re: Function scan/Index scan to nested loop
  • From: Craig Ringer
• Re: Function scan/Index scan to nested loop
  • From: Scott Marlowe
• Function scan/Index scan to nested loop
  • From: Carlo Stonebanks
• Re: 8K recordsize bad on ZFS?
  • From: Josh Berkus
• Re: 8K recordsize bad on ZFS?
  • From: Greg Stark
• Re: 8K recordsize bad on ZFS?
  • From: Josh Berkus
• Re: 8K recordsize bad on ZFS?
  • From: Dimitri
• Re: 8K recordsize bad on ZFS?
  • From: Ivan Voras
• Re: 8K recordsize bad on ZFS?
  • From: Josh Berkus
• Re: Dell Perc HX00 RAID controllers: What's inside?
  • From: Scott Marlowe
• Re: Dell Perc HX00 RAID controllers: What's inside?
  • From: Greg Smith
• Re: Ugh - bad plan with LIMIT in a complex SELECT, any way to fix this?
  • From: Oleg Bartunov
• Re: 8K recordsize bad on ZFS?
  • From: Dimitri
• Re: Ugh - bad plan with LIMIT in a complex SELECT, any way to fix this?
  • From: Jesper Krogh
• Ugh - bad plan with LIMIT in a complex SELECT, any way to fix this?
  • From: Karl Denninger
• Re: Slow Bulk Delete
  • From: Andy Colson
• 8K recordsize bad on ZFS?
  • From: Josh Berkus
• Dell Perc HX00 RAID controllers: What's inside?
  • From: Craig James
• Re: debugging handle exhaustion and 15 min/ 5mil row delete
  • From: Marcos Ortiz
• Re: partioning tips?
  • From: Josh Berkus
• Re: Planner issue on sorting joining of two tables with limit
  • From: Tom Lane
• Re: Planner issue on sorting joining of two tables with limit
  • From: Kevin Grittner
• Re: Planner issue on sorting joining of two tables with limit
  • From: Alexander Korotkov
• Re: Planner issue on sorting joining of two tables with limit
  • From: Alexander Korotkov
• Re: debugging handle exhaustion and 15 min/ 5mil row delete
  • From: Mark Stosberg
• Re: debugging handle exhaustion and 15 min/ 5mil row delete
  • From: Marcos Ortiz
• Re: debugging handle exhaustion and 15 min/ 5mil row delete
  • From: Kenneth Marshall
• debugging handle exhaustion and 15 min/ 5mil row delete
  • From: Mark Stosberg
• Re: PgPool II configuration with PostgreSQL 8.4
  • From: Rosser Schwarz
• Re: PgPool II configuration with PostgreSQL 8.4
  • From: Marcos Ortiz
• Re: PgPool II configuration with PostgreSQL 8.4
  • From: Tatsuo Ishii
• PgPool II configuration with PostgreSQL 8.4
  • From: Neha Mehta
• Re: partioning tips?
  • From: Dave Crooke
• partioning tips?
  • From: Richard Yen
• Re: autovacuum strategy / parameters
  • From: Robert Haas
• Re: autovacuum strategy / parameters
  • From: Scott Marlowe
• Re: autovacuum strategy / parameters
  • From: Scott Marlowe
• Re: autovacuum strategy / parameters
  • From: Robert Haas
• Re: autovacuum strategy / parameters
  • From: Tom Lane
• Re: autovacuum strategy / parameters
  • From: Greg Smith
• Re: autovacuum strategy / parameters
  • From: Scott Marlowe
• Re: autovacuum strategy / parameters
  • From: Scott Marlowe
• Re: Optimization idea
  • From: Cédric Villemain
• Re: autovacuum strategy / parameters
  • From: Robert Haas
• Re: Optimization idea
  • From: Cédric Villemain
• Re: autovacuum strategy / parameters
  • From: Alvaro Herrera
• Re: autovacuum strategy / parameters
  • From: Josh Berkus
• Re: Optimization idea
  • From: Cédric Villemain
• Re: Optimization idea
  • From: Robert Haas
• Re: autovacuum strategy / parameters
  • From: Thomas Kellerer
• Re: autovacuum strategy / parameters
  • From: Kenneth Marshall
• Re: autovacuum strategy / parameters
  • From: akp geek
• Re: autovacuum strategy / parameters
  • From: Thomas Kellerer
• Re: autovacuum strategy / parameters
  • From: Kevin Grittner
• Re: Optimization idea
  • From: Vlad Arkhipov
• Re: Optimization idea
  • From: Cédric Villemain
• Re: tmpfs and postgres memory
  • From: Robert Haas
• Re: autovacuum strategy / parameters
  • From: Robert Haas
• Re: Optimization idea
  • From: Robert Haas
• Re: tmpfs and postgres memory
  • From: Greg Spiegelberg
• tmpfs and postgres memory
  • From: Anj Adu
• Re: autovacuum strategy / parameters
  • From: Alvaro Herrera
• Re: Planner issue on sorting joining of two tables with limit
  • From: Tom Lane
• Planner issue on sorting joining of two tables with limit
  • From: Коротков Александр
• Re: autovacuum strategy / parameters
  • From: Rick
• Re: Optimization idea
  • From: Cédric Villemain
• Re: Optimization idea
  • From: Vlad Arkhipov
• Re: Replacing Cursors with Temporary Tables
  • From: Merlin Moncure
• Re: Replacing Cursors with Temporary Tables
  • From: Grzegorz Jaśkiewicz
• Re: Replacing Cursors with Temporary Tables
  • From: Merlin Moncure
• Re: Replacing Cursors with Temporary Tables
  • From: Pierre C
• Re: Replacing Cursors with Temporary Tables
  • From: Eliot Gable
• Re: Replacing Cursors with Temporary Tables
  • From: Eliot Gable
• Re: Optimization idea
  • From: Robert Haas
• Re: Optimization idea
  • From: Tom Lane
• Re: Replacing Cursors with Temporary Tables
  • From: Robert Haas
• Re: Optimization idea
  • From: Robert Haas
• Re: Replacing Cursors with Temporary Tables
  • From: Merlin Moncure
• Re: Replacing Cursors with Temporary Tables
  • From: Eliot Gable
• Re: Optimization idea
  • From: Cédric Villemain
• Re: Optimization idea
  • From: Kevin Grittner
• Re: Optimization idea
  • From: Robert Haas
• Re: Optimization idea
  • From: Cédric Villemain
• Re: Optimization idea
  • From: Robert Haas
• Re: Optimization idea
  • From: Vlad Arkhipov
• Re: Optimization idea
  • From: Vlad Arkhipov
• Re: Replacing Cursors with Temporary Tables
  • From: Eliot Gable
• Re: autovacuum strategy / parameters
  • From: Robert Haas
• Re: significant slow down with various LIMIT
  • From: norn
• Re: significant slow down with various LIMIT
  • From: norn
• autovacuum strategy / parameters
  • From: Rick
• Re: Replacing Cursors with Temporary Tables
  • From: Merlin Moncure
• Re: Replacing Cursors with Temporary Tables
  • From: Merlin Moncure
• Re: Optimization idea
  • From: Greg Smith
• Re: Replacing Cursors with Temporary Tables
  • From: Merlin Moncure
• Re: Replacing Cursors with Temporary Tables
  • From: Merlin Moncure
• Optimization idea
  • From: Vlad Arkhipov
• Re: Replacing Cursors with Temporary Tables
  • From: Scott Carey
• Re: Very high effective_cache_size == worse performance?
  • From: Scott Carey
• Re: Replacing Cursors with Temporary Tables
  • From: Robert Haas
• Re: [PERFORM] Dbt2 with postgres issues on CentOS-5.3‏
  • From: Mark Wong
• Replacing Cursors with Temporary Tables
  • From: Eliot Gable
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Kris Jurka
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Kris Jurka
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Nikolas Everett
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Tom Lane
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Nikolas Everett
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Robert Haas
• Re: significant slow down with various LIMIT
  • From: Kevin Grittner
• Re: Very high effective_cache_size == worse performance?
  • From: Greg Smith
• Re: performance change from 8.3.1 to later releases
  • From: Tom Lane
• Re: significant slow down with various LIMIT
  • From: Kevin Grittner
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Kris Jurka
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Dave Crooke
• Re: Very high effective_cache_size == worse performance?
  • From: David Kerr
• Re: Very high effective_cache_size == worse performance?
  • From: Greg Smith
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Kevin Grittner
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Nikolas Everett
• Re: performance change from 8.3.1 to later releases
  • From: Scott Marlowe
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Dave Crooke
• Re: Very high effective_cache_size == worse performance?
  • From: Scott Marlowe
• Re: Very high effective_cache_size == worse performance?
  • From: Scott Marlowe
• performance change from 8.3.1 to later releases
  • From: Roger Ging
• Re: Very high effective_cache_size == worse performance?
  • From: David Kerr
• Re: Very high effective_cache_size == worse performance?
  • From: David Kerr
• Re: Very high effective_cache_size == worse performance?
  • From: David Kerr
• Re: Very high effective_cache_size == worse performance?
  • From: Scott Marlowe
• Re: Very high effective_cache_size == worse performance?
  • From: David Kerr
• Re: Very high effective_cache_size == worse performance?
  • From: Scott Marlowe
• Re: Very high effective_cache_size == worse performance?
  • From: David Kerr
• Re: Very high effective_cache_size == worse performance?
  • From: Scott Marlowe
• Re: Very high effective_cache_size == worse performance?
  • From: Kris Jurka
• Re: Very high effective_cache_size == worse performance?
  • From: Kevin Grittner
• Re: Very high effective_cache_size == worse performance?
  • From: Scott Marlowe
• Re: Very high effective_cache_size == worse performance?
  • From: Robert Haas
• Re: Very high effective_cache_size == worse performance?
  • From: Nikolas Everett
• Re: Very high effective_cache_size == worse performance?
  • From: David Kerr
• Re: Very high effective_cache_size == worse performance?
  • From: Robert Haas
• Re: Very high effective_cache_size == worse performance?
  • From: Joshua D. Drake
• Very high effective_cache_size == worse performance?
  • From: David Kerr
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Kevin Grittner
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Kris Jurka
• Re: [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Dave Crooke
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Hannu Krosing
• HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Dave Crooke
• Re: significant slow down with various LIMIT
  • From: norn
• stats collector suddenly causing lots of IO
  • From: Chris
• [JDBC] SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Kevin Grittner
• Dbt2 with postgres issues on CentOS-5.3‏
  • From: MUHAMMAD ASIF
• SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Dave Crooke
• Getting rid of a cursor from JDBC .... Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Dave Crooke
• Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Scott Carey
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Matthew Wakeling
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Віталій Тимчишин
• Re: stats collector suddenly causing lots of IO
  • From: Josh Kupershmidt
• Re: stats collector suddenly causing lots of IO
  • From: Tom Lane
• Re: stats collector suddenly causing lots of IO
  • From: Greg Smith
• Re: stats collector suddenly causing lots of IO
  • From: Josh Kupershmidt
• Re: stats collector suddenly causing lots of IO
  • From: Greg Smith
• Re: stats collector suddenly causing lots of IO
  • From: Josh Kupershmidt
• Re: stats collector suddenly causing lots of IO
  • From: Scott Carey
• Re: stats collector suddenly causing lots of IO
  • From: Scott Carey
• Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
  • From: Josh Berkus
• Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
  • From: Alvaro Herrera
• Re: stats collector suddenly causing lots of IO
  • From: Tom Lane
• Re: stats collector suddenly causing lots of IO
  • From: Tom Lane
• Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
  • From: Josh Berkus
• Re: stats collector suddenly causing lots of IO
  • From: Josh Kupershmidt
• Re: stats collector suddenly causing lots of IO
  • From: Tom Lane
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Tom Lane
• Re: stats collector suddenly causing lots of IO
  • From: Tom Lane
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Yeb Havinga
• Re: stats collector suddenly causing lots of IO
  • From: Josh Kupershmidt
• Re: stats collector suddenly causing lots of IO
  • From: Tom Lane
• Re: stats collector suddenly causing lots of IO
  • From: Tom Lane
• Re: stats collector suddenly causing lots of IO
  • From: Josh Kupershmidt
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Tom Lane
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Віталій Тимчишин
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Yeb Havinga
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Віталій Тимчишин
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Віталій Тимчишин
• Re: Planner not using column limit specified for one column for another column equal to first
  • From: Yeb Havinga
• Planner not using column limit specified for one column for another column equal to first
  • From: Віталій Тимчишин
• SOLVED: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Dave Crooke
• Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
  • From: Josh Berkus
• Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
  • From: Tom Lane
• Re: 8.3.9 - latency spikes with Linux (and tuning for consistently low latency)
  • From: Greg Smith
• Re: stats collector suddenly causing lots of IO
  • From: Tom Lane
• Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
  • From: Josh Berkus
• Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
  • From: Alvaro Herrera
• Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
  • From: Tom Lane
• Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set
  • From: Dave Crooke
• Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
  • From: Alvaro Herrera
• Autovaccum with cost_delay does not complete on one solaris 5.10 machine
  • From: Josh Berkus
• Re: 8.3.9 - latency spikes with Linux (and tuning for consistently low latency)
  • From: Kevin Grittner
• Re: 8.3.9 - latency spikes with Linux (and tuning for consistently low latency)
  • From: Tom Lane
• 8.3.9 - latency spikes with Linux (and tuning for consistently low latency)
  • From: Marinos Yannikos
• Re: JDBC question for PG 8.3.9
  • From: Dave Cramer
• Re: JDBC question for PG 8.3.9
  • From: Dave Crooke
• Re: Good/Bad query plans based on text criteria
  • From: Tom Lane
• Good/Bad query plans based on text criteria
  • From: JmH
• Re: JDBC question for PG 8.3.9
  • From: Craig Ringer
• Re: Occasional giant spikes in CPU load
  • From: Bruce Momjian
• JDBC question for PG 8.3.9
  • From: Dave Crooke
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Krzysztof Kardas
• Re: significant slow down with various LIMIT
  • From: Kevin Grittner
• Re: count is ten times faster
  • From: Kevin Grittner
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Kevin Grittner
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Grzegorz Jaśkiewicz
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Krzysztof Kardas
• Re: stats collector suddenly causing lots of IO
  • From: Alvaro Herrera
• Re: "could not open relation..."
  • From: Tom Lane
• Re: stats collector suddenly causing lots of IO
  • From: Cédric Villemain
• Re: count is ten times faster
  • From: Pierre C
• Re: significant slow down with various LIMIT
  • From: Chris Bowlby
• Re: significant slow down with various LIMIT
  • From: Kevin Grittner
• stats collector suddenly causing lots of IO
  • From: Chris
• Re: significant slow down with various LIMIT
  • From: norn
• count is ten times faster
  • From: Sabin Coanda
• Re: *** PROBABLY SPAM *** Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: Bruce Momjian
• Re: How to diagnose a *context-switching * storm problem ?
  • From: Kevin Grittner
• Re: significant slow down with various LIMIT
  • From: Kevin Grittner
• Re: [PERFORM] How to diagnose a “context-switching ” storm problem ?
  • From: Sergey Konoplev
• Re: significant slow down with various LIMIT
  • From: norn
• How to diagnose a “context-switching ” storm problem ?
  • From: RD黄永卫
• 答复: [PERFORM] About “context-switching issue on Xeon” test case ？
  • From: RD黄永卫
• Re: planer chooses very bad plan
  • From: Hannu Krosing
• Re: Some question
  • From: Ľubomír Varga
• Re: significant slow down with various LIMIT
  • From: norn
• Re: How check execution plan of a function
  • From: Kevin Grittner
• Re: function performs differently with different values
  • From: Robert Haas
• Re: significant slow down with various LIMIT
  • From: Kevin Grittner
• significant slow down with various LIMIT
  • From: Helio Campos Mello de Andrade
• Re: planer chooses very bad plan
  • From: Pierre C
• Re: significant slow down with various LIMIT
  • From: Helio Campos Mello de Andrade
• Re: planer chooses very bad plan
  • From: Scott Marlowe
• Re: planer chooses very bad plan
  • From: Corin
• Re: planer chooses very bad plan
  • From: Corin
• Re: planer chooses very bad plan
  • From: Luke Lonergan
• Re: planer chooses very bad plan
  • From: Scott Marlowe
• planer chooses very bad plan
  • From: Corin
• Re: [PERFORM] About “context-switching issue on Xeon” test case ？
  • From: Scott Marlowe
• Re: Some question
  • From: Kevin Grittner
• Re: "could not open relation..."
  • From: Brian Cox
• Re: About “context-switching issue on Xeon” test case ？
  • From: Greg Smith
• function performs differently with different values
  • From: Ben Chobot
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Krzysztof Kardas
• Re: [PERFORM] About “context-switching issue on Xeon” test case ？
  • From: Scott Marlowe
• Re: [PERFORM] About “context-switching issue on Xeon” test case ？
  • From: Scott Marlowe
• Re: "could not open relation..."
  • From: Tom Lane
• Re: About “context-switching issue on Xeon” test case ？
  • From: Greg Smith
• Re: significant slow down with various LIMIT
  • From: Robert Haas
• Re: How check execution plan of a function
  • From: Sabin Coanda
• Re: significant slow down with various LIMIT
  • From: norn
• About “context-switching issue on Xeon” test case ？
  • From: RD黄永卫
• "could not open relation..."
  • From: Brian Cox
• Re: 3ware vs. MegaRAID
  • From: Scott Marlowe
• Re: 3ware vs. MegaRAID
  • From: Jesper Krogh
• Re: 3ware vs. MegaRAID
  • From: Greg Smith
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Scott Marlowe
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Merlin Moncure
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Scott Marlowe
• Re: 3ware vs. MegaRAID
  • From: Jesper Krogh
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Greg Smith
• Re: 3ware vs. MegaRAID
  • From: Greg Smith
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Scott Mead
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Merlin Moncure
• Re: How check execution plan of a function
  • From: Andy Colson
• Re: 3ware vs. MegaRAID
  • From: Jesper Krogh
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Greg Smith
• Re: 3ware vs. MegaRAID
  • From: Scott Carey
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Greg Smith
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Richard Yen
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Robert Haas
• Re: significant slow down with various LIMIT
  • From: Kevin Grittner
• Re: How check execution plan of a function
  • From: Andy Colson
• Re: Query Optimization
  • From: A. Kretschmer
• Re: LIMIT causes planner to do Index Scan using a less optimal index
  • From: Joel Jacobson
• Re: How check execution plan of a function
  • From: Sabin Coanda
• Re: Occasional giant spikes in CPU load
  • From: Alan Hodgson
• Re: Using high speed swap to improve performance?
  • From: Lew
• Re: LIMIT causes planner to do Index Scan using a less optimal index
  • From: Joel Jacobson
• significant slow down with various LIMIT
  • From: norn
• How check execution plan of a function
  • From: Sabin Coanda
• Re: Query Optimization
  • From: Kaloyan Iliev Iliev
• Query Optimization
  • From: Kaloyan Iliev Iliev
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Merlin Moncure
• Re: PostgreSQL with Zabbix - problem of newbe
  • From: Grzegorz Jaśkiewicz
• PostgreSQL with Zabbix - problem of newbe
  • From: Krzysztof Kardas
• Re: 3ware vs. MegaRAID
  • From: Greg Smith
• Re: Occasional giant spikes in CPU load
  • From: Greg Smith
• Re: 3ware vs. MegaRAID
  • From: Dave Crooke
• Re: 3ware vs. MegaRAID
  • From: Scott Carey
• Re: Occasional giant spikes in CPU load
  • From: Robert Haas
• Re: Occasional giant spikes in CPU load
  • From: David Rees
• Re: Occasional giant spikes in CPU load
  • From: Craig James
• Re: Occasional giant spikes in CPU load
  • From: Robert Haas
• Re: Occasional giant spikes in CPU load
  • From: Tom Lane
• Re: Occasional giant spikes in CPU load
  • From: David Rees
• Re: Occasional giant spikes in CPU load
  • From: Steve Crawford
• Re: Occasional giant spikes in CPU load
  • From: Craig James
• Re: Occasional giant spikes in CPU load
  • From: Craig James
• Re: Occasional giant spikes in CPU load
  • From: David Rees
• Re: Occasional giant spikes in CPU load
  • From: Joshua D. Drake
• Re: Occasional giant spikes in CPU load
  • From: Tom Lane
• Re: Occasional giant spikes in CPU load
  • From: Greg Smith
• Re: Occasional giant spikes in CPU load
  • From: Craig James
• Re: Occasional giant spikes in CPU load
  • From: Joshua D. Drake
• Occasional giant spikes in CPU load
  • From: Craig James
• Re: indexes in partitioned tables - again
  • From: Robert Haas
• Re: query slow; strace output worrisome
  • From: Robert Haas
• Re: LIMIT causes planner to do Index Scan using a less optimal index
  • From: Matthew Wakeling
• Re: LIMIT causes planner to do Index Scan using a less optimal index
  • From: Sherry . CTR . Zhu
• Re: LIMIT causes planner to do Index Scan using a less optimal index
  • From: Grzegorz Jaśkiewicz
• Re: LIMIT causes planner to do Index Scan using a less optimal index
  • From: Sherry . CTR . Zhu
• Re: LIMIT causes planner to do Index Scan using a less optimal index
  • From: Grzegorz Jaśkiewicz
• Re: LIMIT causes planner to do Index Scan using a less optimal index
  • From: Sherry . CTR . Zhu
• Re: Some question
  • From: Yeb Havinga
• Re: query slow; strace output worrisome
  • From: Craig Ringer
• Re: LIMIT causes planner to do Index Scan using a less optimal index
  • From: Robert Haas
• indexes in partitioned tables - again
  • From: Samuel Gendler
• Re: Some question
  • From: Kevin Grittner
• Re: Using high speed swap to improve performance?
  • From: Scott Marlowe
• Re: Some question
  • From: Scott Marlowe
• Re: LIMIT causes planner to do Index Scan using a less optimal index
  • From: Robert Haas
• Re: 3ware vs. MegaRAID
  • From: Ireneusz Pluta
• Re: query slow; strace output worrisome
  • From: Brian Cox
• LIMIT causes planner to do Index Scan using a less optimal index
  • From: Joel Jacobson
• Re: temp table "on commit delete rows": transaction overhead
  • From: Artiom Makarov
• Re: How to fast the REINDEX
  • From: Hannu Krosing
• Re: Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: Hannu Krosing
• Re: Using high speed swap to improve performance?
  • From: Lew
• Some question
  • From: Ľubomír Varga
• Re: temp table "on commit delete rows": transaction overhead
  • From: Artiom Makarov
• Re: Using high speed swap to improve performance?
  • From: Christiaan Willemsen
• Re: query slow; strace output worrisome
  • From: Craig Ringer
• Re: query slow; strace output worrisome
  • From: Brian Cox
• Re: query slow; strace output worrisome
  • From: Craig Ringer
• query slow; strace output worrisome
  • From: Brian Cox
• Re: Huge table searching optimization
  • From: Oliver Kindernay
• Re: How to fast the REINDEX
  • From: Robert Haas
• Re: Huge table searching optimization
  • From: Tom Lane
• Re: Huge table searching optimization
  • From: Andres Freund
• Re: Using high speed swap to improve performance?
  • From: Greg Smith
• Re: Huge table searching optimization
  • From: hubert depesz lubaczewski
• Huge table searching optimization
  • From: Oliver Kindernay
• Re: temp table "on commit delete rows": transaction overhead
  • From: Bruce Momjian
• Re: Using high speed swap to improve performance?
  • From: Scott Marlowe
• Re: Using high speed swap to improve performance?
  • From: Robert Haas
• Re: Using high speed swap to improve performance?
  • From: Robert Haas
• Re: [GENERAL] ERROR: cache lookup failed for relation X
  • From: raghavendra t
• Re: [GENERAL] ERROR: cache lookup failed for relation X
  • From: Tom Lane
• Re: [GENERAL] ERROR: cache lookup failed for relation X
  • From: justin@xxxxxxxxxxxx
• ERROR: cache lookup failed for relation X
  • From: raghavendra t
• Re: How much memory is PostgreSQL using
  • From: Guillaume Lelarge
• David Crooke wants to stay in touch on LinkedIn
  • From: David Crooke
• Re: *** PROBABLY SPAM *** Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: John Beaver
• Re: Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: John Beaver
• Re: *** PROBABLY SPAM *** Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: Pierre C
• Does the psql executable support a "fetch many" approach when dumping large queries to stdout?
  • From: Beaver, John E
• Re: How much memory is PostgreSQL using
  • From: Campbell, Lance
• Re: Using high speed swap to improve performance?
  • From: Arjen van der Meijden
• Using high speed swap to improve performance?
  • From: Christiaan Willemsen
• Re: Database size growing over time and leads to performance impact
  • From: Scott Carey
• Re: Database size growing over time and leads to performance impact
  • From: Tom Lane
• Re: Database size growing over time and leads to performance impact
  • From: Scott Carey
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Eliot Gable
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Robert Haas
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Eliot Gable
• Re: How to fast the REINDEX
  • From: Kevin Grittner
• Re: How to fast the REINDEX
  • From: Brad Nicholson
• Re: How to fast the REINDEX
  • From: raghavendra t
• Re: How to fast the REINDEX
  • From: Pierre C
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: How to fast the REINDEX
  • From: Greg Smith
• Re: How to fast the REINDEX
  • From: Steve Clark
• Re: How to fast the REINDEX
  • From: Craig Ringer
• Re: temp table "on commit delete rows": transaction overhead
  • From: Bruce Momjian
• Re: How to fast the REINDEX
  • From: raghavendra t
• Re: How to fast the REINDEX
  • From: Jaime Casanova
• Re: How to fast the REINDEX
  • From: Kevin Grittner
• Re: How to fast the REINDEX
  • From: raghavendra t
• Re: How to fast the REINDEX
  • From: Kevin Grittner
• Re: How to fast the REINDEX
  • From: raghavendra t
• Re: How to fast the REINDEX
  • From: Kevin Grittner
• Re: How to fast the REINDEX
  • From: raghavendra t
• Re: How to fast the REINDEX
  • From: Kevin Grittner
• How to fast the REINDEX
  • From: raghavendra t
• Re: Database size growing over time and leads to performance impact
  • From: Alvaro Herrera
• Re: Database size growing over time and leads to performance impact
  • From: Robert Haas
• Re: Database size growing over time and leads to performance impact
  • From: Scott Carey
• Re: query has huge variance in execution times
  • From: David Wilson
• Re: query has huge variance in execution times
  • From: Brian Cox
• Re: 3ware vs. MegaRAID
  • From: Francisco Reyes
• Re: experiments in query optimization
  • From: Robert Haas
• Re: mysql to postgresql, performance questions
  • From: Bruce Momjian
• Re: 3ware vs. MegaRAID
  • From: Matteo Beccati
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Matthew Wakeling
• Re: query has huge variance in execution times
  • From: David Wilson
• query has huge variance in execution times
  • From: Brian Cox
• Re: experiments in query optimization
  • From: Robert Haas
• Re: temp table "on commit delete rows": transaction overhead
  • From: Tom Lane
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: 3ware vs. MegaRAID
  • From: Greg Smith
• Re: 3ware vs. MegaRAID
  • From: Matteo Beccati
• Re: experiments in query optimization
  • From: Faheem Mitha
• transaction overhead at "on commit delete rows";
  • From: admin@xxxxxxxx
• temp table "on commit delete rows": transaction overhead
  • From: Artiom Makarov
• Re: Database size growing over time and leads to performance impact
  • From: Greg Smith
• Re: [ADMIN] Database size growing over time and leads to performance impact
  • From: Tomeh, Husam
• Re: experiments in query optimization
  • From: Kevin Grittner
• Re: REINDEXing database-wide daily
  • From: Kevin Grittner
• Re: why does swap not recover?
  • From: Robert Haas
• Re: Why Wal_buffer is 64KB
  • From: Robert Haas
• Re: REINDEXing database-wide daily
  • From: Andy Colson
• Re: Database size growing over time and leads to performance impact
  • From: Andy Colson
• 3ware vs. MegaRAID
  • From: Ireneusz Pluta
• Re: Database size growing over time and leads to performance impact
  • From: Gnanakumar
• Re: Performance regarding LIKE searches
  • From: Matthew Wakeling
• REINDEXing database-wide daily
  • From: Gnanakumar
• Re: why does swap not recover?
  • From: Josh Berkus
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Robert Haas
• Re: experiments in query optimization
  • From: Faheem Mitha
• Re: experiments in query optimization
  • From: Robert Haas
• Re: Performance regarding LIKE searches
  • From: Andy Colson
• Re: Performance regarding LIKE searches
  • From: randalls
• Re: Performance regarding LIKE searches
  • From: Tom Lane
• Re: How much memory is PostgreSQL using
  • From: Greg Smith
• Performance regarding LIKE searches
  • From: randalls
• How much memory is PostgreSQL using
  • From: Campbell, Lance
• Re: Optimizer showing wrong rows in plan
  • From: Nikolas Everett
• Re: Optimizer showing wrong rows in plan
  • From: raghavendra t
• Re: Optimizer showing wrong rows in plan
  • From: Matthew Wakeling
• Re: Why Wal_buffer is 64KB
  • From: Tadipathri Raghu
• Re: Why Wal_buffer is 64KB
  • From: Scott Marlowe
• Re: Why Wal_buffer is 64KB
  • From: Tadipathri Raghu
• Re: Optimizer showing wrong rows in plan
  • From: Tadipathri Raghu
• Re: Pgbench TPS Calculation
  • From: Greg Smith
• Re: Database size growing over time and leads to performance impact
  • From: Greg Smith
• Re: Forcing index scan on query produces 16x faster
  • From: Cédric Villemain
• Re: Optimizer showing wrong rows in plan
  • From: Tom Lane
• Re: Optimizer showing wrong rows in plan
  • From: Jeremy Harris
• Re: Optimizer showing wrong rows in plan
  • From: Tom Lane
• Re: Optimizer showing wrong rows in plan
  • From: Gary Doades
• Re: Optimizer showing wrong rows in plan
  • From: Frank Heikens
• Re: Optimizer showing wrong rows in plan
  • From: Tadipathri Raghu
• Re: Optimizer showing wrong rows in plan
  • From: Tadipathri Raghu
• Re: Optimizer showing wrong rows in plan
  • From: Szymon Guz
• Re: Optimizer showing wrong rows in plan
  • From: Tadipathri Raghu
• Re: Optimizer showing wrong rows in plan
  • From: Szymon Guz
• Re: why does swap not recover?
  • From: Richard Yen
• Optimizer showing wrong rows in plan
  • From: Tadipathri Raghu
• Pgbench TPS Calculation
  • From: Reydan Cankur
• Re: Database size growing over time and leads to performance impact
  • From: Pierre C
• Re: Database size growing over time and leads to performance impact
  • From: Andy Colson
• Database size growing over time and leads to performance impact
  • From: Gnanakumar
• Re: why does swap not recover?
  • From: Craig James
• Re: why does swap not recover?
  • From: Scott Carey
• Re: Block at a time ...
  • From: Scott Carey
• Re: pg_dump far too slow
  • From: Scott Carey
• Re: why does swap not recover?
  • From: Scott Marlowe
• why does swap not recover?
  • From: Richard Yen
• Re: Why Wal_buffer is 64KB
  • From: Scott Marlowe
• Re: Why Wal_buffer is 64KB
  • From: Pierre C
• Re: Performance Tuning Large PL/PGSQL Stored Procedure
  • From: Richard Huxton
• Re: Performance Tuning Large PL/PGSQL Stored Procedure
  • From: Merlin Moncure
• good effective_io_concurrency for FusionIO drives?
  • From: Richard Yen
• Re: Performance Tuning Large PL/PGSQL Stored Procedure
  • From: Eliot Gable
• Re: Why Wal_buffer is 64KB
  • From: Tadipathri Raghu
• Re: Performance Tuning Large PL/PGSQL Stored Procedure
  • From: Merlin Moncure
• experiments in query optimization
  • From: Faheem Mitha
• Re: mysql to postgresql, performance questions
  • From: Yeb Havinga
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Pierre C
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: James Mansion
• Re: mysql to postgresql, performance questions
  • From: Hannu Krosing
• tuning auto vacuum for highly active tables
  • From: Bhella Paramjeet-PFCW67
• Re: Why Wal_buffer is 64KB
  • From: Pierre C
• Re: Why Wal_buffer is 64KB
  • From: Jaime Casanova
• Re: Why Wal_buffer is 64KB
  • From: Brad Nicholson
• Re: default_statistics_target
  • From: Robert Haas
• Why Wal_buffer is 64KB
  • From: Tadipathri Raghu
• Re: memory question
  • From: Matthew Wakeling
• Re: memory question
  • From: Dave Crooke
• Re: Forcing index scan on query produces 16x faster
  • From: Robert Haas
• Re: memory question
  • From: Scott Marlowe
• Re: Forcing index scan on query produces 16x faster
  • From: Eger, Patrick
• memory question
  • From: Campbell, Lance
• Re: Forcing index scan on query produces 16x faster
  • From: Robert Haas
• Re: PostgreSQL upgraded to 8.2 but forcing index scan on query produces faster
  • From: Christian Brink
• Re: mysql to postgresql, performance questions
  • From: Chris Browne
• Re: mysql to postgresql, performance questions
  • From: Chris Browne
• Re: mysql to postgresql, performance questions
  • From: Greg Smith
• Re: mysql to postgresql, performance questions
  • From: Yeb Havinga
• Re: mysql to postgresql, performance questions
  • From: Yeb Havinga
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Dave Crooke
• Re: mysql to postgresql, performance questions
  • From: Tom Lane
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Dave Crooke
• Re: [ADMIN] tuning auto vacuum for highly active tables
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Ross J. Reedstrom
• Re: mysql to postgresql, performance questions
  • From: Greg Smith
• Performance Tuning Large PL/PGSQL Stored Procedure
  • From: Eliot Gable
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Tom Lane
• Re: mysql to postgresql, performance questions
  • From: Ross J. Reedstrom
• Re: Got that new server, now it's time for config!
  • From: Scott Mead
• Re: Got that new server, now it's time for config!
  • From: Greg Smith
• Re: Block at a time ...
  • From: Craig James
• Re: Got that new server, now it's time for config!
  • From: Dan Harris
• Re: PostgreSQL upgraded to 8.2 but forcing index scan on query produces faster
  • From: Eger, Patrick
• Got that new server, now it's time for config!
  • From: Carlo Stonebanks
• Re: default_statistics_target
  • From: Carlo Stonebanks
• Re: Block at a time ...
  • From: Greg Stark
• Re: Block at a time ...
  • From: Dave Crooke
• Re: Block at a time ...
  • From: Pierre C
• Re: PostgreSQL upgraded to 8.2 but forcing index scan on query produces faster
  • From: Tom Lane
• PostgreSQL upgraded to 8.2 but forcing index scan on query produces faster
  • From: Christian Brink
• Re: Block at a time ...
  • From: Scott Carey
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Justin Graf
• Re: Building multiple indexes concurrently
  • From: Justin Pitts
• Re: Building multiple indexes concurrently
  • From: Hannu Krosing
• Re: Building multiple indexes concurrently
  • From: Justin Pitts
• Re: mysql to postgresql, performance questions
  • From: Dave Crooke
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: GiST index performance
  • From: Yeb Havinga
• Re: GiST index performance
  • From: Matthew Wakeling
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Tom Lane
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Matthew Wakeling
• Re: mysql to postgresql, performance questions
  • From: Pierre C
• Re: mysql to postgresql, performance questions
  • From: Merlin Moncure
• Re: pgbench installation
  • From: Greg Smith
• Re: GZIP of pre-zipped output
  • From: Scott Marlowe
• Re: GZIP of pre-zipped output
  • From: Craig Ringer
• Re: mysql to postgresql, performance questions
  • From: Dave Crooke
• Re: mysql to postgresql, performance questions
  • From: Merlin Moncure
• Re: pg_dump far too slow
  • From: Bob Lunney
• GZIP of pre-zipped output
  • From: Dave Crooke
• Re: pg_dump far too slow
  • From: David Newall
• Re: pg_dump far too slow
  • From: Tom Lane
• Re: pg_dump far too slow
  • From: Dave Crooke
• Re: pg_dump far too slow
  • From: Craig Ringer
• Re: pg_dump far too slow
  • From: David Newall
• Re: mysql to postgresql, performance questions
  • From: Andy Colson
• Re: GiST index performance
  • From: Yeb Havinga
• pgbench installation
  • From: Reydan Cankur
• Re: PG using index+filter instead only use index
  • From: Tom Lane
• Re: GiST index performance
  • From: Kenneth Marshall
• Re: PG using index+filter instead only use index
  • From: Alexandre de Arruda Paes
• Re: GiST index performance
  • From: Yeb Havinga
• Re: GiST index performance
  • From: Yeb Havinga
• Re: PG using index+filter instead only use index
  • From: Tom Lane
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Dave Crooke
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Stephen Frost
• Re: mysql to postgresql, performance questions
  • From: Merlin Moncure
• Re: mysql to postgresql, performance questions
  • From: Pierre C
• Re: Building multiple indexes concurrently
  • From: Andres Freund
• Re: GiST index performance
  • From: Yeb Havinga
• Re: too complex query plan for not exists query and multicolumn indexes
  • From: Kevin Grittner
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• PG using index+filter instead only use index
  • From: Alexandre de Arruda Paes
• too complex query plan for not exists query and multicolumn indexes
  • From: Corin
• Re: shared_buffers advice
  • From: Dimitri Fontaine
• Re: mysql to postgresql, performance questions
  • From: Dimitri Fontaine
• Re: mysql to postgresql, performance questions
  • From: Ivan Voras
• Re: Forcing index scan on query produces 16x faster
  • From: Dave Crooke
• Re: Building multiple indexes concurrently
  • From: Hannu Krosing
• Re: mysql to postgresql, performance questions
  • From: Arjen van der Meijden
• Re: mysql to postgresql, performance questions
  • From: Scott Marlowe
• Re: mysql to postgresql, performance questions
  • From: Magnus Hagander
• Re: shared_buffers advice
  • From: Greg Smith
• Re: mysql to postgresql, performance questions
  • From: Stephen Frost
• Re: mysql to postgresql, performance questions
  • From: Grzegorz Jaśkiewicz
• Re: mysql to postgresql, performance questions
  • From: Thom Brown
• Re: mysql to postgresql, performance questions
  • From: Kenneth Marshall
• Re: mysql to postgresql, performance questions
  • From: tv
• mysql to postgresql, performance questions
  • From: Corin
• Re: pg_dump far too slow
  • From: Matthew Wakeling
• Re: shared_buffers advice
  • From: Dimitri Fontaine
• Re: Forcing index scan on query produces 16x faster
  • From: Eger, Patrick
• Re: Testing FusionIO
  • From: Ben Chobot
• Re: Forcing index scan on query produces 16x faster
  • From: Tom Lane
• Re: Forcing index scan on query produces 16x faster
  • From: David Wilson
• Forcing index scan on query produces 16x faster
  • From: Christian Brink
• Re: Building multiple indexes concurrently
  • From: Greg Smith
• Re: Building multiple indexes concurrently
  • From: Alvaro Herrera
• Re: Testing FusionIO
  • From: david
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Testing FusionIO
  • From: Kenny Gorman
• Re: Building multiple indexes concurrently
  • From: Andres Freund
• Re: Testing FusionIO
  • From: Justin Pitts
• Re: Testing FusionIO
  • From: Justin Pitts
• Re: Testing FusionIO
  • From: Justin Pitts
• Re: Building multiple indexes concurrently
  • From: Greg Smith
• Re: Block at a time ...
  • From: Bob Lunney
• Re: Block at a time ...
  • From: Craig James
• Re: Block at a time ...
  • From: Dave Crooke
• Fwd: shared_buffers advice
  • From: VJK
• Re: Building multiple indexes concurrently
  • From: Rob Wultsch
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Building multiple indexes concurrently
  • From: Tom Lane
• Re: Block at a time ...
  • From: Tom Lane
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Testing FusionIO
  • From: Brad Nicholson
• Re: Testing FusionIO
  • From: Devrim GÜNDÜZ
• Re: Building multiple indexes concurrently
  • From: Greg Smith
• Re: Block at a time ...
  • From: Greg Stark
• Re: GiST index performance
  • From: Yeb Havinga