Postgres Performance Date Index

• Thread Index

• Re: Best practice when reindexing in production
  • From: Igor Neyman
• Re: Best practice when reindexing in production
  • From: Matheus de Oliveira
• Re: Best practice when reindexing in production
  • From: Magnus Hagander
• Re: Best practice when reindexing in production
  • From: Niels Kristian Schjødt
• Re: Best practice when reindexing in production
  • From: Niels Kristian Schjødt
• Re: Best practice when reindexing in production
  • From: Armand du Plessis
• Re: Best practice when reindexing in production
  • From: Magnus Hagander
• Best practice when reindexing in production
  • From: Niels Kristian Schjødt
• Re: Performance of complicated query
  • From: Steve Crawford
• Re: Performance of complicated query
  • From: Jonathan Morra
• Re: Slow SELECT by primary key? Postgres 9.1.2
  • From: Matheus de Oliveira
• Re: Slow SELECT by primary key? Postgres 9.1.2
  • From: Roman Konoval
• Re: Slow SELECT by primary key? Postgres 9.1.2
  • From: Evgeniy Shishkin
• Re: Slow SELECT by primary key? Postgres 9.1.2
  • From: John Mudd
• Re: Slow SELECT by primary key? Postgres 9.1.2
  • From: Evgeny Shishkin
• Re: Slow SELECT by primary key? Postgres 9.1.2
  • From: John Mudd
• Re: Slow SELECT by primary key? Postgres 9.1.2
  • From: Evgeny Shishkin
• Slow SELECT by primary key? Postgres 9.1.2
  • From: John Mudd
• Re: Advice on optimizing select/index
  • From: Robert Klemme
• Re: Reporting query failing
  • From: Tomas Vondra
• Reporting query failing
  • From: aup20
• Re: [GENERAL] Very slow inner join query Unacceptable latency.
  • From: Scott Marlowe
• Re: [GENERAL] Very slow inner join query Unacceptable latency.
  • From: fburgess
• Re: pgbench: spike in pgbench results(graphs) while testing pg_hint_plan performance
  • From: sachin kotwal
• Re: pgbench: spike in pgbench results(graphs) while testing pg_hint_plan performance
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: [GENERAL] Very slow inner join query Unacceptable latency.
  • From: Scott Marlowe
• Re: Very slow inner join query Unacceptable latency.
  • From: Amit Kapila
• Re: Performance of complicated query
  • From: Jonathan Morra
• Re: Very slow inner join query Unacceptable latency.
  • From: Jaime Casanova
• Re: Performance of complicated query
  • From: james
• Re: Performance of complicated query
  • From: Jonathan Morra
• Re: Performance of complicated query
  • From: Steve Crawford
• Re: Performance of complicated query
  • From: Jonathan Morra
• Re: Performance of complicated query
  • From: Vladimir Sitnikov
• Re: Setting vacuum_freeze_min_age really low
  • From: Josh Berkus
• Re: Performance of complicated query
  • From: Jonathan Morra
• Re: Performance of complicated query
  • From: Steve Crawford
• Re: Very slow inner join query Unacceptable latency.
  • From: fburgess
• Performance of complicated query
  • From: Jonathan Morra
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Andrea Suisani
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• pgbench: spike in pgbench results(graphs) while testing pg_hint_plan performance
  • From: Sachin D. Bhosale-Kotwal
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Andrea Suisani
• Re: Very slow inner join query Unacceptable latency.
  • From: Amit Kapila
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Joshua D. Drake
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Mark Kirkwood
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Mark Kirkwood
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Mark Kirkwood
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Mark Kirkwood
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Joshua D. Drake
• Re: Very slow inner join query Unacceptable latency.
  • From: Jeff Janes
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Joshua D. Drake
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: CSS
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Shaun Thomas
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Joshua D. Drake
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Shaun Thomas
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Shaun Thomas
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: David Boreham
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Shaun Thomas
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Re: Very slow inner join query Unacceptable latency.
  • From: fburgess
• Advice on optimizing select/index
  • From: Niels Kristian Schjødt
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Re: Very slow inner join query Unacceptable latency.
  • From: Amit Kapila
• Re: pg_statsinfo : error could not connect to repository
  • From: Amit Langote
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Advice on tuning slow query
  • From: Sergey Konoplev
• Advice on tuning slow query
  • From: Samuel Stearns
• Re: Very slow inner join query Unacceptable latency.
  • From: Jaime Casanova
• Very slow inner join query Unacceptable latency.
  • From: fburgess
• Re: performance database for backup/restore
  • From: Jeison Bedoya
• Re: pg_statsinfo : error could not connect to repository
  • From: Kasahara Tatsuhito
• Re: performance database for backup/restore
  • From: Jeff Janes
• Re: performance database for backup/restore
  • From: ktm@xxxxxxxx
• Re: Cost of opening and closing an empty transaction
  • From: Ross Reedstrom
• Re: performance database for backup/restore
  • From: Steve Crawford
• Re: performance database for backup/restore
  • From: Evgeny Shishkin
• performance database for backup/restore
  • From: Jeison Bedoya
• pg_statsinfo : error could not connect to repository
  • From: Sameer Thakur
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Tomas Vondra
• Re: statistics target for columns in unique constraint?
  • From: Kevin Grittner
• Re: Hardware suggestions for maximum read performance
  • From: Scott Marlowe
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Greg Smith
• Re: Deleting Rows From Large Tables
  • From: Greg Smith
• Re: Hardware suggestions for maximum read performance
  • From: Greg Smith
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Cuong Hoang
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Tomas Vondra
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Tomas Vondra
• Re: Deleting Rows From Large Tables
  • From: Greg Spiegelberg
• Re: Deleting Rows From Large Tables
  • From: Jeff Janes
• Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: jonranes
• Re: Slow CTE Query
  • From: Sergey Konoplev
• Slow CTE Query
  • From: Stefan Keller
• Re: statistics target for columns in unique constraint?
  • From: ach
• Re: Deleting Rows From Large Tables
  • From: Vitalii Tymchyshyn
• Re: Deleting Rows From Large Tables
  • From: Sékine Coulibaly
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Deleting Rows From Large Tables
  • From: Rob Emery
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: David Rees
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Mark Kirkwood
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Cuong Hoang
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Tomas Vondra
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Cuong Hoang
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Jeff Janes
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Jeff Janes
• Re: Reliability with RAID 10 SSD and Streaming Replication
  • From: Merlin Moncure
• Reliability with RAID 10 SSD and Streaming Replication
  • From: Cuong Hoang
• Re: Thinking About Correlated Columns (again)
  • From: Shaun Thomas
• Re: [OT] linux 3.10 kernel will improve ipc,sysv semaphore scalability
  • From: Andrea Suisani
• Re: Thinking About Correlated Columns (again)
  • From: Craig James
• Re: Thinking About Correlated Columns (again)
  • From: Thomas Kellerer
• Re: Thinking About Correlated Columns (again)
  • From: Gavin Flower
• Re: Effect of the WindowAgg on the Nested Loop
  • From: Victor Yegorov
• Re: Thinking About Correlated Columns (again)
  • From: Gavin Flower
• Re: Thinking About Correlated Columns (again)
  • From: eggyknap
• Re: Effect of the WindowAgg on the Nested Loop
  • From: Robert Haas
• Re: Thinking About Correlated Columns (again)
  • From: Nikolas Everett
• Re: Thinking About Correlated Columns (again)
  • From: Andrew Dunstan
• Re: Thinking About Correlated Columns (again)
  • From: Shaun Thomas
• Re: Thinking About Correlated Columns (again)
  • From: Craig James
• Re: Thinking About Correlated Columns (again)
  • From: Heikki Linnakangas
• Thinking About Correlated Columns (again)
  • From: Shaun Thomas
• Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: ktm@xxxxxxxx
• Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: Christoph Berg
• Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: Christoph Berg
• Re: Lock and pg_stat
  • From: Robert Haas
• Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: Robert Haas
• Re: Predicate information in EXPLAIN Command
  • From: Heikki Linnakangas
• Predicate information in EXPLAIN Command
  • From: Sameer Thakur
• Re: Hardware suggestions for maximum read performance
  • From: Scott Marlowe
• Re: Hardware suggestions for maximum read performance
  • From: Mike McCann
• Re: Hardware suggestions for maximum read performance
  • From: Jeff Janes
• Re: statistics target for columns in unique constraint?
  • From: Mark Kirkwood
• Re: Hardware suggestions for maximum read performance
  • From: Mike McCann
• Re: statistics target for columns in unique constraint?
  • From: Marti Raudsepp
• Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: Tom Lane
• Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: Robert Haas
• Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: Tom Lane
• Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: Mark Felder
• Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: Robert Haas
• Re: Setting vacuum_freeze_min_age really low
  • From: Andres Freund
• Re: Setting vacuum_freeze_min_age really low
  • From: Robert Haas
• statistics target for columns in unique constraint?
  • From: ach
• Lock and pg_stat
  • From: Desbiens, Eric
• Re: Setting vacuum_freeze_min_age really low
  • From: Andres Freund
• Re: Setting vacuum_freeze_min_age really low
  • From: Josh Berkus
• Re: In progress INSERT wrecks plans on table
  • From: Mark Kirkwood
• Re: PostgreSQL planner
  • From: Misa Simic
• Re: PostgreSQL planner
  • From: Robert Haas
• Re: In progress INSERT wrecks plans on table
  • From: Tom Lane
• Re: In progress INSERT wrecks plans on table
  • From: Mark Kirkwood
• Re: In progress INSERT wrecks plans on table
  • From: Vitalii Tymchyshyn
• Re: Setting vacuum_freeze_min_age really low
  • From: Andres Freund
• Re: Setting vacuum_freeze_min_age really low
  • From: Andres Freund
• Re: Setting vacuum_freeze_min_age really low
  • From: Robert Haas
• Re: Hardware suggestions for maximum read performance
  • From: Jeff Janes
• Re: Deterioration in performance when query executed in multi threads
  • From: Anne Rosset
• Re: In progress INSERT wrecks plans on table
  • From: Mark Kirkwood
• Re: In progress INSERT wrecks plans on table
  • From: Simon Riggs
• Re: In progress INSERT wrecks plans on table
  • From: Matt Clarkson
• Re: In progress INSERT wrecks plans on table
  • From: Mark Kirkwood
• Re: In progress INSERT wrecks plans on table
  • From: Simon Riggs
• Re: Deterioration in performance when query executed in multi threads
  • From: Igor Neyman
• Re: In progress INSERT wrecks plans on table
  • From: mark . kirkwood
• Re: Deterioration in performance when query executed in multi threads
  • From: Gavin Flower
• Re: Deterioration in performance when query executed in multi threads
  • From: Anne Rosset
• Re: Deterioration in performance when query executed in multi threads
  • From: Anne Rosset
• Re: In progress INSERT wrecks plans on table
  • From: Matt Clarkson
• Re: Deterioration in performance when query executed in multi threads
  • From: Igor Neyman
• Re: Deterioration in performance when query executed in multi threads
  • From: Igor Neyman
• Re: Deterioration in performance when query executed in multi threads
  • From: Thomas Kellerer
• Re: Deterioration in performance when query executed in multi threads
  • From: Anne Rosset
• Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: Tom Lane
• Deterioration in performance when query executed in multi threads
  • From: Anne Rosset
• RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
  • From: Christoph Berg
• Re: In progress INSERT wrecks plans on table
  • From: Gavin Flower
• Re: Deterioration in performance when query executed in multi threads
  • From: Merlin Moncure
• Re: Deterioration in performance when query executed in multi threads
  • From: Igor Neyman
• Re: In progress INSERT wrecks plans on table
  • From: Simon Riggs
• Re: Hardware suggestions for maximum read performance
  • From: Yuri Levinsky
• Re: In progress INSERT wrecks plans on table
  • From: Mark Kirkwood
• Re: In progress INSERT wrecks plans on table
  • From: Simon Riggs
• Re: Deterioration in performance when query executed in multi threads
  • From: Anne Rosset
• Re: Hardware suggestions for maximum read performance
  • From: Julien Cigar
• Re: In progress INSERT wrecks plans on table
  • From: Simon Riggs
• Re: Hardware suggestions for maximum read performance
  • From: Scott Marlowe
• Re: Hardware suggestions for maximum read performance
  • From: Arjen van der Meijden
• Re: Hardware suggestions for maximum read performance
  • From: Scott Marlowe
• Hardware suggestions for maximum read performance
  • From: Mike McCann
• Re: In progress INSERT wrecks plans on table
  • From: mark . kirkwood
• Re: In progress INSERT wrecks plans on table
  • From: Thomas Kellerer
• Re: In progress INSERT wrecks plans on table
  • From: mark . kirkwood
• Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
  • From: Claudio Freire
• Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
  • From: Simon Riggs
• Re: Query planner ignoring constraints on partitioned tables when joining
  • From: Simon Riggs
• Re: In progress INSERT wrecks plans on table
  • From: Simon Riggs
• Re: 100x slowdown for nearly identical tables
  • From: Tom Lane
• Re: In progress INSERT wrecks plans on table
  • From: Mark Kirkwood
• Re: 100x slowdown for nearly identical tables
  • From: Craig James
• Re: 100x slowdown for nearly identical tables
  • From: Tom Lane
• 100x slowdown for nearly identical tables
  • From: Craig James
• Re: [BUGS] BUG #8130: Hashjoin still gives issues
  • From: Jeff Davis
• Re: [BUGS] BUG #8130: Hashjoin still gives issues
  • From: Igor Neyman
• Re: Deterioration in performance when query executed in multi threads
  • From: Igor Neyman
• Re: Deterioration in performance when query executed in multi threads
  • From: Anne Rosset
• Re: Deterioration in performance when query executed in multi threads
  • From: Scott Marlowe
• Re: Deterioration in performance when query executed in multi threads
  • From: ktm@xxxxxxxx
• Re: Deterioration in performance when query executed in multi threads
  • From: Anne Rosset
• Re: [BUGS] BUG #8130: Hashjoin still gives issues
  • From: Stefan de Konink
• Re: Deterioration in performance when query executed in multi threads
  • From: ktm@xxxxxxxx
• Re: In progress INSERT wrecks plans on table
  • From: Tom Lane
• Deterioration in performance when query executed in multi threads
  • From: Anne Rosset
• Re: In progress INSERT wrecks plans on table
  • From: Mark Kirkwood
• Re: Bad Execution Plan with "OR" Clauses Across Outer-Joined Tables
  • From: Mark Hampton
• Re: Bad Execution Plan with "OR" Clauses Across Outer-Joined Tables
  • From: Vitalii Tymchyshyn
• Bad Execution Plan with "OR" Clauses Across Outer-Joined Tables
  • From: Mark Hampton
• Re: In progress INSERT wrecks plans on table
  • From: Mark Kirkwood
• In progress INSERT wrecks plans on table
  • From: Mark Kirkwood
• different plans for the same query - different filter values
  • From: Misa Simic
• Re: [PERFORM] Question about network bandwidth usage between PostgreSQL’s client and server
  • From: Heikki Linnakangas
• Question about network bandwidth usage between PostgreSQL’s client and server
  • From: Kelphet Xiong
• Re: template1 vacuuming consuming much time compared to another production DBs
  • From: pradeep singh
• Re: Issues with OSX and SHMMAX?
  • From: Tom Lane
• Re: Issues with OSX and SHMMAX?
  • From: Steve Atkins
• Re: Issues with OSX and SHMMAX?
  • From: Josh Berkus
• Re: Performance with the new security release
  • From: Heikki Linnakangas
• Performance with the new security release
  • From: Anne Rosset
• Re: template1 vacuuming consuming much time compared to another production DBs
  • From: Andrew Dunstan
• template1 vacuuming consuming much time compared to another production DBs
  • From: pradeep singh
• Re: - why only 9.1?
  • From: Ireneusz Pluta
• Re: Issues with OSX and SHMMAX?
  • From: Evgeny Shishkin
• Issues with OSX and SHMMAX?
  • From: Josh Berkus
• Re:
  • From: Scott Marlowe
• Re:
  • From: Scott Marlowe
• Re:
  • From: Rob Wultsch
• [no subject]
  • From: sunil virmani
• maintenance_work_mem and autovacuum_max_workers
  • From: Rodrigo Barboza
• Re: slow bitmap heap scans on pg 9.2
  • From: Steve Singer
• Re: Query planner ignoring constraints on partitioned tables when joining
  • From: Tom Lane
• Re: SQLNestedException: Cannot get a connection, pool error Timeout waiting for idle object
  • From: Vitalii Tymchyshyn
• Re: High CPU usage buy low I/O wait
  • From: ktm@xxxxxxxx
• High CPU usage buy low I/O wait
  • From: bing1221
• Re: [GENERAL] SQLNestedException: Cannot get a connection, pool error Timeout waiting for idle object
  • From: Alfonso Afonso
• SQLNestedException: Cannot get a connection, pool error Timeout waiting for idle object
  • From: itishree sukla
• Query planner ignoring constraints on partitioned tables when joining
  • From: Michael Okner
• Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
  • From: Tom Lane
• Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
  • From: Richard Huxton
• "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
  • From: dmitry potapov
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Franck Routier
• Re: Poor performance on an aggregate query
  • From: Peter Geoghegan
• Poor performance on an aggregate query
  • From: Anne Rosset
• Re: INDEX Performance Issue
  • From: Jeff Janes
• Re: INDEX Performance Issue
  • From: Jeff Janes
• Re: INDEX Performance Issue
  • From: Jeff Janes
• Re: Advice on testing buffer spin lock contention
  • From: Atri Sharma
• Advice on testing buffer spin lock contention
  • From: Atri Sharma
• Re: slow bitmap heap scans on pg 9.2
  • From: Steve Singer
• Re: Segment best size
  • From: Rodrigo Barboza
• Re: Segment best size
  • From: Jeff Janes
• Re: limit is sometimes not pushed in view with order
  • From: Rikard Pavelic
• Re: Segment best size
  • From: Scott Marlowe
• Re: Segment best size
  • From: Rodrigo Barboza
• Re: slow bitmap heap scans on pg 9.2
  • From: Jeff Janes
• Re: Segment best size
  • From: Jeff Janes
• Re: limit is sometimes not pushed in view with order
  • From: Rikard Pavelic
• Re: Segment best size
  • From: Rodrigo Barboza
• Re: slow bitmap heap scans on pg 9.2
  • From: Steve Singer
• Re: limit is sometimes not pushed in view with order
  • From: Julian
• Re: limit is sometimes not pushed in view with order
  • From: Tom Lane
• limit is sometimes not pushed in view with order
  • From: Rikard Pavelic
• Re: slow bitmap heap scans on pg 9.2
  • From: Jeff Janes
• Re: Segment best size
  • From: Jeff Janes
• Re: Recommended Swap space
  • From: Scott Marlowe
• Default value checkpoint_completion_target
  • From: Rodrigo Barboza
• Re: Recommended Swap space
  • From: Claudio Freire
• Re: Recommended Swap space
  • From: Scott Marlowe
• Recommended Swap space
  • From: Nik Tek
• Re: Changing ORDER BY column slows query dramatically
  • From: brick pglists
• Re: Changing ORDER BY column slows query dramatically
  • From: Shaun Thomas
• Re: Segment best size
  • From: Rodrigo Barboza
• Re: Segment best size
  • From: Ben Chobot
• Changing ORDER BY column slows query dramatically
  • From: brick pglists
• Segment best size
  • From: Rodrigo Barboza
• Re: PsqL8.3
  • From: Richard Huxton
• Re: Postgres log(pg_logs) have lots of message
  • From: Jeff Janes
• PsqL8.3
  • From: Thiyagarajan, Palaniappan
• Re: Performance ts_vector fulltext search
  • From: Tom Lane
• Re: slow bitmap heap scans on pg 9.2
  • From: Steve Singer
• Performance ts_vector fulltext search
  • From: Luigi Saggese
• Re: slow bitmap heap scans on pg 9.2
  • From: Steve Singer
• Re: [ADMIN] Postgres log(pg_logs) have lots of message
  • From: Nik Tek
• Postgres log(pg_logs) have lots of message
  • From: Nik Tek
• Re: Postgresql.conf file from like 7.x to 9.2
  • From: Tory M Blue
• Re: Postgresql.conf file from like 7.x to 9.2
  • From: Shaun Thomas
• Postgresql.conf file from like 7.x to 9.2
  • From: Tory M Blue
• Re: slow bitmap heap scans on pg 9.2
  • From: Jeff Janes
• Re: slow bitmap heap scans on pg 9.2
  • From: Jeff Janes
• Re: slow bitmap heap scans on pg 9.2
  • From: ktm@xxxxxxxx
• Re: slow bitmap heap scans on pg 9.2
  • From: Steve Singer
• Re: slow bitmap heap scans on pg 9.2
  • From: ktm@xxxxxxxx
• slow bitmap heap scans on pg 9.2
  • From: Steve Singer
• Re: Find how much memory is postgres using
  • From: Nik Tek
• Re: Find how much memory is postgres using
  • From: hubert depesz lubaczewski
• Re: Find how much memory is postgres using
  • From: Nik Tek
• Re: Picking out the most recent row using a time stamp column
  • From: Dave Johansen
• Re: INDEX Performance Issue
  • From: Mark Davidson
• Re: INDEX Performance Issue
  • From: Mark Davidson
• Re: INDEX Performance Issue
  • From: Jeff Janes
• Re: INDEX Performance Issue
  • From: Vasilis Ventirozos
• Re: INDEX Performance Issue
  • From: Mark Davidson
• Re: INDEX Performance Issue
  • From: Vasilis Ventirozos
• Re: INDEX Performance Issue
  • From: Mark Davidson
• Re: INDEX Performance Issue
  • From: Vasilis Ventirozos
• Re: INDEX Performance Issue
  • From: Mark Davidson
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Tom Lane
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Jeff Janes
• Re: Find how much memory is postgres using
  • From: hubert depesz lubaczewski
• Re: INDEX Performance Issue
  • From: Mark Davidson
• Re: INDEX Performance Issue
  • From: Kevin Grittner
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: INDEX Performance Issue
  • From: Greg Williamson
• Re: INDEX Performance Issue
  • From: Mark Davidson
• Re: Find how much memory is postgres using
  • From: hubert depesz lubaczewski
• Re: Find how much memory is postgres using
  • From: Yetkin Öztürk
• Find how much memory is postgres using
  • From: Nik Tek
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Tom Lane
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Kevin Grittner
• Re: slow joins?
  • From: Julien Cigar
• Re: slow joins?
  • From: Kevin Grittner
• Re: slow joins?
  • From: Julien Cigar
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: slow joins?
  • From: Greg Williamson
• Re: slow joins?
  • From: Joe Van Dyk
• Re: slow joins?
  • From: Greg Williamson
• Re: slow joins?
  • From: Joe Van Dyk
• Re: slow joins?
  • From: Joe Van Dyk
• slow joins?
  • From: Joe Van Dyk
• Re: Picking out the most recent row using a time stamp column
  • From: Merlin Moncure
• Re: Picking out the most recent row using a time stamp column
  • From: Dave Johansen
• Re: INDEX Performance Issue
  • From: Kevin Grittner
• INDEX Performance Issue
  • From: Mark Davidson
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Nikolas Everett
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Merlin Moncure
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Tom Lane
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Merlin Moncure
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Tom Lane
• Re: What happens between end of explain analyze and end of query execution ?
  • From: nik9000
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Tom Lane
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: What happens between end of explain analyze and end of query execution ?
  • From: Nikolas Everett
• What happens between end of explain analyze and end of query execution ?
  • From: Franck Routier
• Re: Postgres upgrade, security release, where?
  • From: Ian Lawrence Barwick
• Re: Postgres upgrade, security release, where?
  • From: Mark Kirkwood
• Re: Planner is getting wrong row count
  • From: Kevin Grittner
• Re: Join between 2 tables always executes a sequential scan on the larger table
  • From: Vasilis Ventirozos
• Re: Join between 2 tables always executes a sequential scan on the larger table
  • From: Dieter Rehbein
• Re: Join between 2 tables always executes a sequential scan on the larger table
  • From: Dieter Rehbein
• Planner is getting wrong row count
  • From: AI Rumman
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Re: Join between 2 tables always executes a sequential scan on the larger table
  • From: Tom Lane
• Re: Join between 2 tables always executes a sequential scan on the larger table
  • From: Igor Neyman
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Join between 2 tables always executes a sequential scan on the larger table
  • From: Dieter Rehbein
• Re: Postgres upgrade, security release, where?
  • From: Mark Kirkwood
• Re: Postgres upgrade, security release, where?
  • From: Dave Page
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Problems with pg_locks explosion
  • From: Mark Kirkwood
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Problems with pg_locks explosion
  • From: Mark Kirkwood
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Problems with pg_locks explosion
  • From: Jeff Janes
• Re: Problems with pg_locks explosion
  • From: Jeff Janes
• Re: Postgres upgrade, security release, where?
  • From: Mark Kirkwood
• Re: Fwd: Problems with pg_locks explosion
  • From: Mark Kirkwood
• Re: Postgres upgrade, security release, where?
  • From: Tory M Blue
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Problems with pg_locks explosion
  • From: Steven Crandell
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Postgres upgrade, security release, where?
  • From: Bruce Momjian
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Postgres upgrade, security release, where?
  • From: Ian Lawrence Barwick
• Fwd: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Postgres upgrade, security release, where?
  • From: Bruce Momjian
• Re: Problems with pg_locks explosion
  • From: Jeff Janes
• Re: Problems with pg_locks explosion
  • From: Mark Kirkwood
• Postgres upgrade, security release, where?
  • From: Tory M Blue
• Re: Problems with pg_locks explosion
  • From: Vasilis Ventirozos
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Problems with pg_locks explosion
  • From: Armand du Plessis
• Fwd: Problems with pg_locks explosion
  • From: Vasilis Ventirozos
• Problems with pg_locks explosion
  • From: Armand du Plessis
• Re: Question about postmaster's CPU usage
  • From: Merlin Moncure
• Re: query plan estimate
  • From: Tom Lane
• query plan estimate
  • From: pg noob
• Re: 9.2.3 upgrade reduced pgbench performance by 60%
  • From: Jeff Janes
• Re: Question about postmaster's CPU usage
  • From: Kelphet Xiong
• Re: Question about postmaster's CPU usage
  • From: Ants Aasma
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Jeff Janes
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Cédric Villemain
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Guillaume Cottenceau
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Jeff Janes
• Re: how to help the planner
  • From: Igor Neyman
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Franck Routier
• Re: [OT] linux 3.10 kernel will improve ipc,sysv semaphore scalability
  • From: Andrea Suisani
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Guillaume Cottenceau
• Re: Postgresql performance degrading... how to diagnose the root cause
  • From: Julien Cigar
• Postgresql performance degrading... how to diagnose the root cause
  • From: Franck Routier
• Re: how to help the planner
  • From: Stephen Frost
• Re: Question about postmaster's CPU usage
  • From: ktm@xxxxxxxx
• Re: Question about postmaster's CPU usage
  • From: Kevin Grittner
• Re: how to help the planner
  • From: Marty Frasier
• Question about postmaster's CPU usage
  • From: kelphet xiong
• Re: how to help the planner
  • From: Tom Lane
• how to help the planner
  • From: Marty Frasier
• Re: 9.2.3 upgrade reduced pgbench performance by 60%
  • From: Josh Berkus
• Re: Reg: Slow query
  • From: Vasilis Ventirozos
• Reg: Slow query
  • From: Prakash Chinnakannan
• 9.2.3 upgrade reduced pgbench performance by 60%
  • From: Colin Currie
• Re: Performance of query
  • From: Jeff Janes
• Re: Performance of query
  • From: Cindy Makarowsky
• Proof of concept: Evolving postgresql.conf using genetic algorithm
  • From: Greg Jaskiewicz
• Setting vacuum_freeze_min_age really low
  • From: Josh Berkus
• Re: 9.2.3 upgrade reduced pgbench performance by 60%
  • From: Josh Berkus
• [OT] linux 3.10 kernel will improve ipc,sysv semaphore scalability
  • From: Andrea Suisani
• Re: [OT] linux 3.10 kernel will improve ipc,sysv semaphore scalability
  • From: Shaun Thomas
• Re: 9.2.3 upgrade reduced pgbench performance by 60%
  • From: Nicholson, Brad (Toronto, ON, CA)
• Re: Performance of query
  • From: Roman Konoval
• PostgreSQL planner
  • From: Misa Simic
• Re: Performance of query
  • From: Misa Simic
• Re: Performance of query
  • From: Jeff Janes
• Re: Index usage for tstzrange?
  • From: Tom Lane
• Re: Index usage for tstzrange?
  • From: Josh Berkus
• Performance of query
  • From: Cindy Makarowsky
• Re: Performance of query
  • From: Josh Berkus
• Re: Index usage for tstzrange?
  • From: Heikki Linnakangas
• Re: Performance of query
  • From: Cindy Makarowsky
• Re: Performance of query
  • From: Misa Simic
• Re: Performance of query
  • From: Cindy Makarowsky
• Re: Index usage for tstzrange?
  • From: Heikki Linnakangas
• Re: Index usage for tstzrange?
  • From: Josh Berkus
• Re: Index usage for tstzrange?
  • From: Heikki Linnakangas
• Re: Index usage for tstzrange?
  • From: Vasilis Ventirozos
• Re: Index usage for tstzrange?
  • From: Tom Lane
• Re: New server setup
  • From: Mark Kirkwood
• Re: New server setup
  • From: Scott Marlowe
• Re: New server setup
  • From: Karl Denninger
• Re: New server setup
  • From: David Boreham
• Re: New server setup
  • From: David Rees
• Index usage for tstzrange?
  • From: Josh Berkus
• Re: effective_cache_size on 32-bits postgres
  • From: Rodrigo Barboza
• Re: effective_cache_size on 32-bits postgres
  • From: Pavel Stehule
• Re: effective_cache_size on 32-bits postgres
  • From: Claudio Freire
• Re: effective_cache_size on 32-bits postgres
  • From: Kevin Grittner
• Re: effective_cache_size on 32-bits postgres
  • From: Pavel Stehule
• Re: effective_cache_size on 32-bits postgres
  • From: Rodrigo Barboza
• Re: effective_cache_size on 32-bits postgres
  • From: Pavel Stehule
• Re: effective_cache_size on 32-bits postgres
  • From: Rodrigo Barboza
• Re: effective_cache_size on 32-bits postgres
  • From: Pavel Stehule
• Re: effective_cache_size on 32-bits postgres
  • From: Rob Wultsch
• effective_cache_size on 32-bits postgres
  • From: Rodrigo Barboza
• Re: Why is my pg_xlog directory so huge?
  • From: Niels Kristian Schjødt
• Re: Why is my pg_xlog directory so huge?
  • From: Magnus Hagander
• Re: Why is my pg_xlog directory so huge?
  • From: Niels Kristian Schjødt
• Re: Why is my pg_xlog directory so huge?
  • From: Magnus Hagander
• Why is my pg_xlog directory so huge?
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Mark Kirkwood
• Re: New server setup
  • From: Scott Marlowe
• Re: New server setup
  • From: Bruce Momjian
• Re: Pre-sorting COPY FROM input
  • From: Heikki Linnakangas
• Re: New server setup
  • From: Rick Otten
• Pre-sorting COPY FROM input
  • From: Florian Weimer
• Re: Join the master table with other table is very slow (partitioning)
  • From: Ao Jianwang
• Re: Join the master table with other table is very slow (partitioning)
  • From: Tom Lane
• Re: Join the master table with other table is very slow (partitioning)
  • From: Ao Jianwang
• Re: Join the master table with other table is very slow (partitioning)
  • From: Ao Jianwang
• Re: Join the master table with other table is very slow (partitioning)
  • From: AI Rumman
• Re: Join the master table with other table is very slow (partitioning)
  • From: Ao Jianwang
• Join the master table with other table is very slow (partitioning)
  • From: Ao Jianwang
• Re: New server setup
  • From: David Boreham
• Re: New server setup
  • From: Mark Kirkwood
• Re: New server setup
  • From: Bruce Momjian
• Re: New server setup
  • From: Mark Kirkwood
• Re: New server setup
  • From: Mark Kirkwood
• Re: Speed of EXCECUTE in PL/PGSQL
  • From: Andrew Dunstan
• Re: Speed of EXCECUTE in PL/PGSQL
  • From: Merlin Moncure
• Speed of EXCECUTE in PL/PGSQL
  • From: Artur Zając
• Re: New server setup
  • From: Bruce Momjian
• Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Emre Hasegeli
• PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Jeff Janes
• Re: New server setup
  • From: David Boreham
• Re: New server setup
  • From: Mark Kirkwood
• Re: Risk of data corruption/loss?
  • From: Joshua Berkus
• Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Joshua Berkus
• Re: New server setup
  • From: David Boreham
• Re: New server setup
  • From: John Lister
• Re: New server setup
  • From: CSS
• Re: New server setup
  • From: Karl Denninger
• Re: Setup of four 15k SAS disk with LSI raid controller
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Steve Crawford
• Re: Setup of four 15k SAS disk with LSI raid controller
  • From: Joshua D. Drake
• Re: Setup of four 15k SAS disk with LSI raid controller
  • From: Vasilis Ventirozos
• Re: Setup of four 15k SAS disk with LSI raid controller
  • From: Niels Kristian Schjødt
• Re: Setup of four 15k SAS disk with LSI raid controller
  • From: Vasilis Ventirozos
• Setup of four 15k SAS disk with LSI raid controller
  • From: Niels Kristian Schjødt
• Re: Risk of data corruption/loss?
  • From: Niels Kristian Schjødt
• Re: Risk of data corruption/loss?
  • From: Jeff Janes
• Re: New server setup
  • From: John Lister
• Re: New server setup
  • From: Greg Jaskiewicz
• Re: New server setup
  • From: John Lister
• Risk of data corruption/loss?
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Gregg Jaskiewicz
• Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Emre Hasegeli
• Re: Slow concurrent processing
  • From: Misa Simic
• Re: Slow concurrent processing
  • From: Misa Simic
• Re: Slow concurrent processing
  • From: Jeff Janes
• Re: Slow concurrent processing
  • From: Steve Crawford
• Re: Slow concurrent processing
  • From: Misa Simic
• Re: Slow concurrent processing
  • From: Steve Crawford
• Re: Slow concurrent processing
  • From: Misa Simic
• Re: Slow query when used in a view
  • From: Shaun Thomas
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Victor Yegorov
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Jeff Adams - NOAA Affiliate
• Slow concurrent processing
  • From: Misa Simic
• Re: Slow query when used in a view
  • From: Tom Lane
• Slow query when used in a view
  • From: Shaun Thomas
• The dreaded semwait on FreeBSD
  • From: Benjamin Krajmalnik
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Jeff Adams - NOAA Affiliate
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Pavel Stehule
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Jeff Adams - NOAA Affiliate
• Re: Large Table - Slow Window Functions (Better Approach?)
  • From: Pavel Stehule
• Re: sniff test on some PG 8.4 numbers
  • From: Jon Nelson
• Large Table - Slow Window Functions (Better Approach?)
  • From: Jeff Adams - NOAA Affiliate
• Re: sniff test on some PG 8.4 numbers
  • From: Greg Smith
• Re: sniff test on some PG 8.4 numbers
  • From: Scott Marlowe
• Re: sniff test on some PG 8.4 numbers
  • From: Jon Nelson
• Re: New server setup
  • From: Greg Smith
• Re: sniff test on some PG 8.4 numbers
  • From: Greg Smith
• Re: New server setup
  • From: Gregg Jaskiewicz
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Emre Hasegeli
• Re: Poor plan when joining against a union containing a join
  • From: David Leverton
• PostgreSQL 9.2.3 performance problem caused Exclusive locks
  • From: Emre Hasegeli
• Re: Anyone running Intel S3700 SSDs?
  • From: Yeb Havinga
• Anyone running Intel S3700 SSDs?
  • From: CSS
• Re: Poor plan when joining against a union containing a join
  • From: Tom Lane
• Re: Poor plan when joining against a union containing a join
  • From: David Leverton
• Re: Poor plan when joining against a union containing a join
  • From: Tom Lane
• Re: Poor plan when joining against a union containing a join
  • From: Josh Berkus
• Re: Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Jeff Janes
• Poor plan when joining against a union containing a join
  • From: David Leverton
• Re: Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Julien Cigar
• Re: sniff test on some PG 8.4 numbers
  • From: Jon Nelson
• Re: sniff test on some PG 8.4 numbers
  • From: Jon Nelson
• Re: sniff test on some PG 8.4 numbers
  • From: Josh Berkus
• Re: Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Joshua D. Drake
• Re: Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Jeff Janes
• Re: Are bitmap index scans slow to start?
  • From: Jeff Janes
• sniff test on some PG 8.4 numbers
  • From: Jon Nelson
• Re: New server setup
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Benjamin Krajmalnik
• Re: Are bitmap index scans slow to start?
  • From: Jeff Janes
• Re: New server setup
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Scott Marlowe
• Re: New server setup
  • From: Kevin Grittner
• Re: Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Julien Cigar
• Re: Poor performance after update from SLES11 SP1 to SP2
  • From: Mark Smith
• Optimize SELECT * from table WHERE foreign_key_id IN (key1,key2,key3,key4...)
  • From: Niels Kristian Schjødt
• Re: hardware upgrade, performance degrade?
  • From: Steven Crandell
• Re: hardware upgrade, performance degrade?
  • From: Scott Marlowe
• Re: hardware upgrade, performance degrade?
  • From: Steven Crandell
• Re: hardware upgrade, performance degrade?
  • From: Scott Marlowe
• Re: hardware upgrade, performance degrade?
  • From: John Rouillard
• Re: hardware upgrade, performance degrade?
  • From: Sergey Konoplev
• Re: hardware upgrade, performance degrade?
  • From: Mark Kirkwood
• Re: hardware upgrade, performance degrade?
  • From: Steven Crandell
• Re: pgbench intriguing results: better tps figures for larger scale factor
  • From: Greg Smith
• Re: Schema obfuscator for performance question
  • From: Claudio Freire
• Re: Schema obfuscator for performance question
  • From: Victor Yegorov
• Schema obfuscator for performance question
  • From: Joseph Pravato
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: Niels Kristian Schjødt
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: Scott Marlowe
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: AJ Weber
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: Scott Marlowe
• Re: pgbench intriguing results: better tps figures for larger scale factor
  • From: Merlin Moncure
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: Richard Neill
• Re: What setup would you choose for postgresql 9.2 installation?
  • From: AJ Weber
• What setup would you choose for postgresql 9.2 installation?
  • From: Niels Kristian Schjødt
• Re: New server setup
  • From: Niels Kristian Schjødt
• Re: hardware upgrade, performance degrade?
  • From: Jean-David Beyer
• Re: hardware upgrade, performance degrade?
  • From: Josh Berkus
• Re: hardware upgrade, performance degrade?
  • From: Jesper Krogh
• Re: hardware upgrade, performance degrade?
  • From: Scott Marlowe
• Re: New server setup
  • From: Wales Wang
• Re: hardware upgrade, performance degrade?
  • From: Steven Crandell
• Re: hardware upgrade, performance degrade?
  • From: Craig James
• Re: New server setup
  • From: Craig James
• Re: xmlconcat performance
  • From: Merlin Moncure
• New server setup
  • From: Niels Kristian Schjødt
• Re: hardware upgrade, performance degrade?
  • From: Guillaume Smet
• hardware upgrade, performance degrade?
  • From: Steven Crandell
• Processing of subqueries in union
  • From: Markus Hervén
• Re: SELECT is slow on smaller table?
  • From: Ao Jianwang
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Wrong actual number of rows in the Query Plan
  • From: Tom Lane
• Re: xmlconcat performance
  • From: Merlin Moncure
• Re: pgbench intriguing results: better tps figures for larger scale factor
  • From: Pavan Deolasee
• xmlconcat performance
  • From: Davide Berra
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Glyn Astill
• Re: Are bitmap index scans slow to start?
  • From: Marc Mamin
• Bad query plan with high-cardinality column
  • From: Alexander Staubo
• Re: Are bitmap index scans slow to start?
  • From: Gavin Flower
• Using a window function in a view
  • From: Chris Hanks
• pgbench intriguing results: better tps figures for larger scale factor
  • From: Costin Oproiu
• Wrong actual number of rows in the Query Plan
  • From: Vahe Evoyan
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Scott Marlowe
• Re: Estimation question...
  • From: Matt Daw
• Re: SELECT is slow on smaller table?
  • From: Julien Cigar
• SELECT is slow on smaller table?
  • From: Ao Jianwang
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Server stalls, all CPU 100% system time
  • From: Josh Berkus
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Are bitmap index scans slow to start?
  • From: Jeff Janes
• Re: Estimation question...
  • From: Matt Daw
• Re: seqscan on UNION'ed views
  • From: Tom Lane
• Re: Server stalls, all CPU 100% system time
  • From: Andre
• seqscan on UNION'ed views
  • From: Dmitry Karasik
• Re: Server stalls, all CPU 100% system time
  • From: Scott Marlowe
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Server stalls, all CPU 100% system time
  • From: Josh Berkus
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Scott Marlowe
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Jeff Janes
• Estimation question...
  • From: Matt Daw
• Re: Are bitmap index scans slow to start?
  • From: Jeff Janes
• Re: Server stalls, all CPU 100% system time
  • From: Andre
• Re: Very slow update statement on 40mio rows
  • From: Florian Schröck
• Re: High CPU usage / load average after upgrading to Ubuntu 12.04
  • From: Jeff Frost
• Re: Avoiding Recheck Cond when using Select Distinct
  • From: Jeff Janes
• Re: Avoiding Recheck Cond when using Select Distinct
  • From: Maciek Sakrejda
• Re: Are bitmap index scans slow to start?
  • From: Carlo Stonebanks
• Re: Server stalls, all CPU 100% system time
  • From: Scott Marlowe
• Re: Server stalls, all CPU 100% system time
  • From: Tom Lane
• Re: Server stalls, all CPU 100% system time
  • From: Andre
• Re: Server stalls, all CPU 100% system time
  • From: Bèrto ëd Sèra