Postgres Performance Date Index

• Thread Index

• Re: ERROR: out of memory | with 23GB cached 7GB reserved on 30GB machine
  • From: Montana Low
• Re: ERROR: out of memory | with 23GB cached 7GB reserved on 30GB machine
  • From: Tomas Vondra
• Re: ERROR: out of memory | with 23GB cached 7GB reserved on 30GB machine
  • From: Tom Lane
• ERROR: out of memory | with 23GB cached 7GB reserved on 30GB machine
  • From: Montana Low
• Re: Query with large number of joins
  • From: Igor Neyman
• Re: Query with large number of joins
  • From: Marco Di Cesare
• Re: Query with large number of joins
  • From: Marco Di Cesare
• Re: extremly bad select performance on huge table
  • From: Igor Neyman
• Re: extremly bad select performance on huge table
  • From: Björn Wittich
• Re: extremly bad select performance on huge table
  • From: Tom Lane
• Re: extremly bad select performance on huge table
  • From: Igor Neyman
• Re: extremly bad select performance on huge table
  • From: Björn Wittich
• extremly bad select performance on huge table
  • From: Björn Wittich
• Re: Query with large number of joins
  • From: Tom Lane
• Re: Query with large number of joins
  • From: Tom Lane
• Re: Query with large number of joins
  • From: Andrew Dunstan
• Re: Query with large number of joins
  • From: Marco Di Cesare
• Re: Query with large number of joins
  • From: Merlin Moncure
• Re: Query Performance Problem
  • From: Felipe Santos
• Query Performance Problem
  • From: john
• Re: Query with large number of joins
  • From: Felipe Santos
• Re: IS NOT NULL and LEFT JOIN
  • From: David Rowley
• Re: Query with large number of joins
  • From: Tom Lane
• Re: IS NOT NULL and LEFT JOIN
  • From: David G Johnston
• Re: IS NOT NULL and LEFT JOIN
  • From: David G Johnston
• Re: IS NOT NULL and LEFT JOIN
  • From: Laurent Martelli
• Query with large number of joins
  • From: Marco Di Cesare
• Re: IS NOT NULL and LEFT JOIN
  • From: Tom Lane
• Re: IS NOT NULL and LEFT JOIN
  • From: Laurent Martelli
• Re: Yet another abort-early plan disaster on 9.3
  • From: Greg Stark
• Re: IS NOT NULL and LEFT JOIN
  • From: David Rowley
• IS NOT NULL and LEFT JOIN
  • From: Laurent Martelli
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Greg Stark
• 9.4 performance improvements test
  • From: Josh Berkus
• CopyManager(In/out) vs. delete/insert directly
  • From: Emi Lu
• Re: Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: Дмитрий Шалашов
• Re: Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: Felipe Santos
• Re: Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: Jeff Janes
• Re: Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: Дмитрий Шалашов
• Re: Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: François Beausoleil
• Partitioned tables and SELECT ... ORDER BY ... LIMIT
  • From: Дмитрий Шалашов
• Re: Partitions and work_mem?
  • From: Tom Lane
• Re: Partitions and work_mem?
  • From: Josh Berkus
• Re: Partitions and work_mem?
  • From: Igor Neyman
• Re: Partitions and work_mem?
  • From: Dave Johansen
• Re: Partitions and work_mem?
  • From: Igor Neyman
• Re: Partitions and work_mem?
  • From: Dave Johansen
• Re: Partitions and work_mem?
  • From: Igor Neyman
• Re: Partitions and work_mem?
  • From: Dave Johansen
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Partitions and work_mem?
  • From: Josh Berkus
• Re: Partitions and work_mem?
  • From: Jeff Janes
• Partitions and work_mem?
  • From: Dave Johansen
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Craig James
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Craig James
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Greg Stark
• Re: char(N), varchar(N), varchar, text
  • From: Emi Lu
• Re: char(N), varchar(N), varchar, text
  • From: Andrew Dunstan
• char(N), varchar(N), varchar, text
  • From: Emi Lu
• Re: query plan question, nested loop vs hash join
  • From: Andrey Lizenko
• Re: Performance degradation in 324577f39bc8738ed0ec24c36c5cb2c2f81ec660
  • From: Vladimir Kamarzin
• Bad optimization/planning on Postgres window-based queries (partition by(, group by?)) - 1000x speedup
  • From: and
• Re: help: function failing
  • From: Andrew Dunstan
• Re: help: function failing
  • From: Sergey Konoplev
• Re: query plan question, nested loop vs hash join
  • From: Marti Raudsepp
• Re: pg_basebackup - odd performance
  • From: Mike Blackwell
• query plan question, nested loop vs hash join
  • From: Andrey Lizenko
• help: function failing
  • From: George Neuner
• Re: Performance degradation in 324577f39bc8738ed0ec24c36c5cb2c2f81ec660
  • From: Tom Lane
• Performance degradation in 324577f39bc8738ed0ec24c36c5cb2c2f81ec660
  • From: Vladimir Kamarzin
• Re: pg_basebackup - odd performance
  • From: Jov
• Re: <idle> issue?
  • From: jaime soler
• pg_basebackup - odd performance
  • From: Mike Blackwell
• Re: <idle> issue?
  • From: Felipe Santos
• <idle> issue?
  • From: Emi Lu
• Re: query plan question, nested loop vs hash join
  • From: Andrey Lizenko
• Re: query plan question, nested loop vs hash join
  • From: Andrey Lizenko
• Re: query plan question, nested loop vs hash join
  • From: Tom Lane
• Re: query plan question, nested loop vs hash join
  • From: Victor Yegorov
• query plan question, nested loop vs hash join
  • From: Andrey Lizenko
• Re: auto vaccum is dying
  • From: Jeff Janes
• Re: auto vaccum is dying
  • From: Rodrigo Barboza
• Re: auto vaccum is dying
  • From: Rodrigo Barboza
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tomas Vondra
• Re: Yet another abort-early plan disaster on 9.3
  • From: Jeff Janes
• Re: Planning for Scalability
  • From: Claudio Freire
• Re: Planning for Scalability
  • From: Graeme B. Bell
• Re: Planning for Scalability
  • From: Roberto Grandi
• Re: Planning for Scalability
  • From: ktm@xxxxxxxx
• Planning for Scalability
  • From: Roberto Grandi
• Re: performance of SELECT * much faster than SELECT <colname> with large offset
  • From: Marti Raudsepp
• Re: performance of SELECT * much faster than SELECT <colname> with large offset
  • From: Tom Lane
• performance of SELECT * much faster than SELECT <colname> with large offset
  • From: Marc Slemko
• Re: Yet another abort-early plan disaster on 9.3
  • From: Peter Geoghegan
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: auto vaccum is dying
  • From: Jeff Janes
• Re: Yet another abort-early plan disaster on 9.3
  • From: Ryan Johnson
• Re: Yet another abort-early plan disaster on 9.3
  • From: Peter Geoghegan
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: auto vaccum is dying
  • From: Dorian Hoxha
• Re: auto vaccum is dying
  • From: Heikki Linnakangas
• auto vaccum is dying
  • From: Rodrigo Barboza
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Yet another abort-early plan disaster on 9.3
  • From: Merlin Moncure
• Re: Yet another abort-early plan disaster on 9.3
  • From: Gavin Flower
• Re: Yet another abort-early plan disaster on 9.3
  • From: Graeme B. Bell
• Re: Yet another abort-early plan disaster on 9.3
  • From: Jeff Janes
• Re: Yet another abort-early plan disaster on 9.3
  • From: Jeff Janes
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tom Lane
• Re: Yet another abort-early plan disaster on 9.3
  • From: Claudio Freire
• Re: Yet another abort-early plan disaster on 9.3
  • From: Graeme B. Bell
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Yet another abort-early plan disaster on 9.3
  • From: Greg Stark
• Re: Very slow postgreSQL 9.3.4 query
  • From: Burgess, Freddie
• Re: Yet another abort-early plan disaster on 9.3
  • From: Gavin Flower
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tom Lane
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: Very slow postgreSQL 9.3.4 query
  • From: Graeme B. Bell
• Re: Yet another abort-early plan disaster on 9.3
  • From: Merlin Moncure
• Re: after upgrade 8.4->9.3 query is slow not using index scan
  • From: Matúš Svrček
• Re: Very slow postgreSQL 9.3.4 query
  • From: Burgess, Freddie
• Re: Very slow postgreSQL 9.3.4 query
  • From: Burgess, Freddie
• Re: after upgrade 8.4->9.3 query is slow not using index scan
  • From: Victor Yegorov
• Re: Very slow postgreSQL 9.3.4 query
  • From: Burgess, Freddie
• Re: Very slow postgreSQL 9.3.4 query
  • From: Graeme B. Bell
• after upgrade 8.4->9.3 query is slow not using index scan
  • From: Matúš Svrček
• Very slow postgreSQL 9.3.4 query
  • From: Burgess, Freddie
• Re: Yet another abort-early plan disaster on 9.3
  • From: Simon Riggs
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Imre Samu
• Re: Which update action quicker?
  • From: Emi Lu
• Re: Which update action quicker?
  • From: Heikki Linnakangas
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Which update action quicker?
  • From: Emi Lu
• Re: postgres 9.3 vs. 9.4
  • From: Merlin Moncure
• Re: Slow query
  • From: David G Johnston
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Slow query
  • From: Ross Elliott
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Merlin Moncure
• Re: postgres 9.3 vs. 9.4
  • From: Merlin Moncure
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Tom Lane
• Re: Yet another abort-early plan disaster on 9.3
  • From: Claudio Freire
• Re: query a table with lots of coulmns
  • From: Björn Wittich
• Re: query a table with lots of coulmns
  • From: Marc Mamin
• Re: query a table with lots of coulmns
  • From: Björn Wittich
• Re: Yet another abort-early plan disaster on 9.3
  • From: Greg Stark
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: query a table with lots of coulmns
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Yet another abort-early plan disaster on 9.3
  • From: Merlin Moncure
• Re: query a table with lots of coulmns
  • From: Pavel Stehule
• Re: query a table with lots of coulmns
  • From: Björn Wittich
• Re: query a table with lots of coulmns
  • From: Szymon Guz
• query a table with lots of coulmns
  • From: Björn Wittich
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Jeff Janes
• Re: postgres 9.3 vs. 9.4
  • From: didier
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• Re: postgres 9.3 vs. 9.4
  • From: Merlin Moncure
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Andrew Dunstan
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Josh Berkus
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Jeff Janes
• Re: postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: postgres 9.3 vs. 9.4
  • From: Mark Kirkwood
• postgres 9.3 vs. 9.4
  • From: Mkrtchyan, Tigran
• Re: Aggregating tsqueries
  • From: Heikki Linnakangas
• Aggregating tsqueries
  • From: Alexander Hill
• Yet another abort-early plan disaster on 9.3
  • From: Josh Berkus
• Re: Postgres Replaying WAL slowly
  • From: Simon Riggs
• How to interpret view pg_stat_bgwriter
  • From: Huang, Suya
• Re: Strange performance problem with query
  • From: Van Der Berg, Stefan
• Re: Strange performance problem with query
  • From: Kevin Grittner
• Strange performance problem with query
  • From: Van Der Berg, Stefan
• Re: weird execution plan
  • From: Huang, Suya
• Re: weird execution plan
  • From: David G Johnston
• Re: weird execution plan
  • From: Huang, Suya
• Re: how to change the provoke table in hash join
  • From: Huang, Suya
• Re: weird execution plan
  • From: David G Johnston
• weird execution plan
  • From: Huang, Suya
• Re: how to change the provoke table in hash join
  • From: Jeff Janes
• Re: how to change the provoke table in hash join
  • From: Matheus de Oliveira
• how to change the provoke table in hash join
  • From: Huang, Suya
• Re: query performance with hstore vs. non-hstore
  • From: Huang, Suya
• Re: Performance issue: index not used on GROUP BY...
  • From: gmb
• Re: why after increase the hash table partitions, tpmc decrease
  • From: Takashi Horikawa
• Implementing a functionality for processing heavy insertion
  • From: Shadin A
• why after increase the hash table partitions, tpmc decrease
  • From: Xiaoyulei
• Re: query performance with hstore vs. non-hstore
  • From: David G Johnston
• Re: query performance with hstore vs. non-hstore
  • From: Huang, Suya
• Re: query performance with hstore vs. non-hstore
  • From: Pavel Stehule
• Re: query performance with hstore vs. non-hstore
  • From: Huang, Suya
• Re: query performance with hstore vs. non-hstore
  • From: Pavel Stehule
• query performance with hstore vs. non-hstore
  • From: Huang, Suya
• Re: Very slow running query PostgreSQL 9.3.4
  • From: Victor Yegorov
• Very slow running query PostgreSQL 9.3.4
  • From: Burgess, Freddie
• Re: Performance issue: index not used on GROUP BY...
  • From: Josh Berkus
• Re: autocommit (true/false) for more than 1 million records
  • From: Emi Lu
• Re: Performance issue: index not used on GROUP BY...
  • From: Victor Yegorov
• Re: Performance issue: index not used on GROUP BY...
  • From: gmb
• Re: Performance issue: index not used on GROUP BY...
  • From: Marti Raudsepp
• Re: Performance issue: index not used on GROUP BY...
  • From: Victor Yegorov
• Re: Performance issue: index not used on GROUP BY...
  • From: gmb
• Re: Performance issue: index not used on GROUP BY...
  • From: Victor Yegorov
• Performance issue: index not used on GROUP BY...
  • From: gmb
• Re: autocommit (true/false) for more than 1 million records
  • From: Kevin Grittner
• Re: autocommit (true/false) for more than 1 million records
  • From: Albe Laurenz
• Re: autocommit (true/false) for more than 1 million records
  • From: Felipe Santos
• Re: autocommit (true/false) for more than 1 million records
  • From: Albe Laurenz
• Re: autocommit (true/false) for more than 1 million records
  • From: David Johnston
• Re: autocommit (true/false) for more than 1 million records
  • From: Alex Goncharov
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: autocommit (true/false) for more than 1 million records
  • From: David G Johnston
• Re: autocommit (true/false) for more than 1 million records
  • From: Alex Goncharov
• Re: autocommit (true/false) for more than 1 million records
  • From: Kevin Grittner
• Re: autocommit (true/false) for more than 1 million records
  • From: Alex Goncharov
• Re: tuning postgresql 9.3.5 and multiple cores
  • From: Mark Kirkwood
• Re: tuning postgresql 9.3.5 and multiple cores
  • From: Soni M
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: tuning postgresql 9.3.5 and multiple cores
  • From: Jeff Janes
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Josh Berkus
• tuning postgresql 9.3.5 and multiple cores
  • From: Jeison Bedoya Delgado
• Re: autocommit (true/false) for more than 1 million records
  • From: Jeff Janes
• Re: autocommit (true/false) for more than 1 million records
  • From: Felipe Santos
• Re: autocommit (true/false) for more than 1 million records
  • From: David Johnston
• Re: autocommit (true/false) for more than 1 million records
  • From: Emi Lu
• Re: autocommit (true/false) for more than 1 million records
  • From: Stephen Frost
• Re: autocommit (true/false) for more than 1 million records
  • From: Emi Lu
• Re: autocommit (true/false) for more than 1 million records
  • From: Stephen Frost
• Re: autocommit (true/false) for more than 1 million records
  • From: David G Johnston
• autocommit (true/false) for more than 1 million records
  • From: Emi Lu
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Andres Freund
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Shaun Thomas
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Scott Marlowe
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Joshua D. Drake
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Josh Berkus
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Steve Crawford
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Josh Berkus
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Graeme B. Bell
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Scott Marlowe
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Scott Marlowe
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Bruce Momjian
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Josh Berkus
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Bruce Momjian
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Josh Berkus
• Re: Window functions, partitioning, and sorting performance
  • From: Marti Raudsepp
• Re: Window functions, partitioning, and sorting performance
  • From: Eli Naeher
• Re: Window functions, partitioning, and sorting performance
  • From: Eli Naeher
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Shaun Thomas
• Re: Window functions, partitioning, and sorting performance
  • From: Shaun Thomas
• Re: Window functions, partitioning, and sorting performance
  • From: Marti Raudsepp
• Window functions, partitioning, and sorting performance
  • From: Eli Naeher
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: query on parent partition table has bad performance
  • From: Tom Lane
• Re: High rate of transaction failure with the Serializable Isolation Level
  • From: Reza Taheri
• Re: query on parent partition table has bad performance
  • From: Huang, Suya
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Tatsuo Ishii
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Bruce Momjian
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Peter Geoghegan
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: query against pg_locks leads to large memory alloc
  • From: Kevin Grittner
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Shaun Thomas
• Re: Turn off Hyperthreading! WAS: 60 core performance with 9.3
  • From: Josh Berkus
• Re: query against pg_locks leads to large memory alloc
  • From: Kevin Grittner
• Re: query against pg_locks leads to large memory alloc
  • From: Dave Owens
• Re: query on parent partition table has bad performance
  • From: Tom Lane
• Re: query on parent partition table has bad performance
  • From: David G Johnston
• query on parent partition table has bad performance
  • From: Huang, Suya
• Re: query against pg_locks leads to large memory alloc
  • From: Kevin Grittner
• Re: query against pg_locks leads to large memory alloc
  • From: Dave Owens
• Re: query against pg_locks leads to large memory alloc
  • From: Kevin Grittner
• Re: query against pg_locks leads to large memory alloc
  • From: Kevin Grittner
• Re: query against pg_locks leads to large memory alloc
  • From: Dave Owens
• Re: query against pg_locks leads to large memory alloc
  • From: Dave Owens
• Re: query against pg_locks leads to large memory alloc
  • From: Andres Freund
• Re: query against pg_locks leads to large memory alloc
  • From: Dave Owens
• Re: query against pg_locks leads to large memory alloc
  • From: Kevin Grittner
• Re: query against pg_locks leads to large memory alloc
  • From: Dave Owens
• Re: query against pg_locks leads to large memory alloc
  • From: Kevin Grittner
• Re: query against pg_locks leads to large memory alloc
  • From: Tom Lane
• Re: query against pg_locks leads to large memory alloc
  • From: Kevin Grittner
• Re: query against pg_locks leads to large memory alloc
  • From: Dave Owens
• Re: query against pg_locks leads to large memory alloc
  • From: Merlin Moncure
• Re: query against pg_locks leads to large memory alloc
  • From: Matheus de Oliveira
• query against pg_locks leads to large memory alloc
  • From: Dave Owens
• Re: select on index column,why PG still use seq scan?
  • From: Tom Lane
• select on index column,why PG still use seq scan?
  • From: Xiaoyulei
• Re: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: 60 core performance with 9.3
  • From: Josh Berkus
• Re: how does the planer to estimate row when i use order by and group by
  • From: Marti Raudsepp
• Re: 60 core performance with 9.3
  • From: Mark Kirkwood
• how does the planer to estimate row when i use order by and group by
  • From: 楊新波
• Re: Optimization idea for long IN() lists
  • From: Maxim Boguk
• Optimization idea for long IN() lists
  • From: Josh Berkus
• Re: two table join with order by on both tables attributes
  • From: Evgeniy Shishkin
• Re: two table join with order by on both tables attributes
  • From: Marti Raudsepp
• Re: two table join with order by on both tables attributes
  • From: Evgeniy Shishkin
• Re: two table join with order by on both tables attributes
  • From: Evgeniy Shishkin
• Re: two table join with order by on both tables attributes
  • From: Tom Lane
• Re: two table join with order by on both tables attributes
  • From: Evgeniy Shishkin
• Re: Building multiple indexes on one table.
  • From: Felipe Santos
• Re: Building multiple indexes on one table.
  • From: Claudio Freire
• Re: Building multiple indexes on one table.
  • From: Marc Mamin
• Re: Very slow planning performance on partition table
  • From: Douglas J Hunley
• Very slow planning performance on partition table
  • From: Rural Hunter
• Re: Blocking every 20 sec while mass copying.
  • From: Benjamin Dugast
• Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: johno
• estimate btree index size without creating
  • From: Евгений Селявка
• Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: Tom Lane
• Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: johno
• Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: Tom Lane
• Re: Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: johno
• Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: David G Johnston
• Re: Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: johno
• Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: David G Johnston
• Re: Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: johno
• Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: David G Johnston
• Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
  • From: johno
• Re: 60 core performance with 9.3
  • From: Kevin Grittner
• Re: Blocking every 20 sec while mass copying.
  • From: Albe Laurenz
• Re: Blocking every 20 sec while mass copying.
  • From: Jeff Janes
• Re: Blocking every 20 sec while mass copying.
  • From: Guillaume Cottenceau
• Re: Blocking every 20 sec while mass copying.
  • From: Albe Laurenz
• Blocking every 20 sec while mass copying.
  • From: Benjamin Dugast
• Re: Building multiple indexes on one table.
  • From: Claudio Freire
• Building multiple indexes on one table.
  • From: Chris Ruprecht
• Re: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: Query Performance question
  • From: Magers, James
• Re: Query Performance question
  • From: Tomas Vondra
• Re: Query Performance question
  • From: Magers, James
• Re: Query Performance question
  • From: Tomas Vondra
• Re: Query Performance question
  • From: Magers, James
• Re: Query Performance question
  • From: Thomas Kellerer
• Re: Query Performance question
  • From: Magers, James
• Re: Query Performance question
  • From: Thomas Kellerer
• Re: Query Performance question
  • From: Magers, James
• Re: Query Performance question
  • From: Tomas Vondra
• Query Performance question
  • From: Magers, James
• Re: GIN index not used
  • From: Emre Hasegeli
• Re: 60 core performance with 9.3
  • From: Kevin Grittner
• Re: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: 60 core performance with 9.3
  • From: Andres Freund
• Re: GIN index not used
  • From: Huang, Suya
• Re: GIN index not used
  • From: Tom Lane
• Re: GIN index not used
  • From: Huang, Suya
• Re: GIN index not used
  • From: Andreas Kretschmer
• Re: GIN index not used
  • From: Tom Lane
• Re: GIN index not used
  • From: Andreas Kretschmer
• GIN index not used
  • From: Huang, Suya
• Re: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: PGSQL 9.3 - billion rows
  • From: Josh Berkus
• Re: DB sessions 100 times of DB connections
  • From: Steve Crawford
• Re: PGSQL 9.3 - billion rows
  • From: Sékine Coulibaly
• Re: stored procedure suddenly runs slowly in HOT STANDBY but fast in primary
  • From: piuschan
• Re: PGSQL 9.3 - billion rows
  • From: Felipe Santos
• PGSQL 9.3 - billion rows
  • From: Nicolas Paris
• Re: stored procedure suddenly runs slowly in HOT STANDBY but fast in primary
  • From: Tom Lane
• stored procedure suddenly runs slowly in HOT STANDBY but fast in primary
  • From: piuschan
• Re: DB sessions 100 times of DB connections
  • From: Huang, Suya
• DB sessions 100 times of DB connections
  • From: Huang, Suya
• Re: Hash Join node sometimes slow
  • From: Dave Roberge
• Re: Postgres Replaying WAL slowly
  • From: Simon Riggs
• Re: Postgres Replaying WAL slowly
  • From: Tom Lane
• Re: Postgres Replaying WAL slowly
  • From: Andres Freund
• Re: fragmention issue with ext4: e4defrag?
  • From: Kevin Grittner
• Re: Hash Join node sometimes slow
  • From: Tom Lane
• Hash Join node sometimes slow
  • From: Dave Roberge
• fragmention issue with ext4: e4defrag?
  • From: Marc Mamin
• Re: Guidelines on best indexing strategy for varying searches on 20+ columns
  • From: Niels Kristian Schjødt
• Re: Postgres Replaying WAL slowly
  • From: Tom Lane
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Volatility - docs vs behaviour?
  • From: Merlin Moncure
• Re: 60 core performance with 9.3
  • From: Andres Freund
• Re: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: GIST optimization to limit calls to operator on sub nodes
  • From: Pujol Mathieu
• Re: Volatility - docs vs behaviour?
  • From: Tom Lane
• Re: Volatility - docs vs behaviour?
  • From: Craig Ringer
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Postgres Replaying WAL slowly
  • From: Andres Freund
• Re: Postgres Replaying WAL slowly
  • From: Tom Lane
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Postgres Replaying WAL slowly
  • From: Tom Lane
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Postgres Replaying WAL slowly
  • From: Andres Freund
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Postgres Replaying WAL slowly
  • From: Matheus de Oliveira
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Postgres Replaying WAL slowly
  • From: Tom Lane
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Postgres Replaying WAL slowly
  • From: Pavel Stehule
• Re: Postgres Replaying WAL slowly
  • From: Andres Freund
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Guidelines on best indexing strategy for varying searches on 20+ columns
  • From: Jeff Janes
• Re: Postgres Replaying WAL slowly
  • From: Soni M
• Re: Postgres Replaying WAL slowly
  • From: Andres Freund
• Re: Postgres Replaying WAL slowly
  • From: Jeff Frost
• Re: Postgres Replaying WAL slowly
  • From: Heikki Linnakangas
• Re: Volatility - docs vs behaviour?
  • From: Tom Lane
• Re: Postgres Replaying WAL slowly
  • From: Soni M
• Re: GIST optimization to limit calls to operator on sub nodes
  • From: Tom Lane
• Volatility - docs vs behaviour?
  • From: Craig Ringer
• Re: GIST optimization to limit calls to operator on sub nodes
  • From: Pujol Mathieu
• Re: Guidelines on best indexing strategy for varying searches on 20+ columns
  • From: Niels Kristian Schjødt
• Re: GIST optimization to limit calls to operator on sub nodes
  • From: Pujol Mathieu
• Re: Postgres Replaying WAL slowly
  • From: Heikki Linnakangas
• Re: GIST optimization to limit calls to operator on sub nodes
  • From: Tom Lane
• Re: GIST optimization to limit calls to operator on sub nodes
  • From: Emre Hasegeli
• Re: Postgres Replaying WAL slowly
  • From: Soni M
• Re: Postgres Replaying WAL slowly
  • From: Soni M
• Re: Postgres Replaying WAL slowly
  • From: Heikki Linnakangas
• Postgres Replaying WAL slowly
  • From: Soni M
• Re: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: 60 core performance with 9.3
  • From: Andres Freund
• Can improve 'limit 1' ? with slow function
  • From: songtebo
• Re: 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: 60 core performance with 9.3
  • From: Scott Marlowe
• 60 core performance with 9.3
  • From: Mark Kirkwood
• Re: how to improve perf of 131MM row table?
  • From: Aaron Weber
• Re: how to improve perf of 131MM row table?
  • From: Aaron Weber
• Re: how to improve perf of 131MM row table?
  • From: Shaun Thomas
• Re: how to improve perf of 131MM row table?
  • From: Jeff Janes
• Re: how to improve perf of 131MM row table?
  • From: AJ Weber
• Re: how to improve perf of 131MM row table?
  • From: Sébastien Lorion
• Re: how to improve perf of 131MM row table?
  • From: Shaun Thomas
• Re: how to improve perf of 131MM row table?
  • From: Claudio Freire
• Re: how to improve perf of 131MM row table?
  • From: AJ Weber
• Re: how to improve perf of 131MM row table?
  • From: Claudio Freire
• Re: how to improve perf of 131MM row table?
  • From: AJ Weber
• Re: how to improve perf of 131MM row table?
  • From: Claudio Freire
• Re: how to improve perf of 131MM row table?
  • From: AJ Weber
• Re: how to improve perf of 131MM row table?
  • From: Shaun Thomas
• Re: how to improve perf of 131MM row table?
  • From: AJ Weber
• Re: how to improve perf of 131MM row table?
  • From: Matheus de Oliveira
• Re: how to improve perf of 131MM row table?
  • From: AJ Weber
• Re: how to improve perf of 131MM row table?
  • From: Shaun Thomas
• Re: how to improve perf of 131MM row table?
  • From: Matheus de Oliveira
• Re: how to improve perf of 131MM row table?
  • From: AJ Weber
• Re: how to improve perf of 131MM row table?
  • From: Aaron Weber
• Re: how to improve perf of 131MM row table?
  • From: Shaun Thomas
• Re: Guidelines on best indexing strategy for varying searches on 20+ columns
  • From: Merlin Moncure
• Re: how to improve perf of 131MM row table?
  • From: Aaron Weber
• Re: how to improve perf of 131MM row table?
  • From: Shaun Thomas
• how to improve perf of 131MM row table?
  • From: AJ Weber
• Guidelines on best indexing strategy for varying searches on 20+ columns
  • From: Niels Kristian Schjødt
• Re: postgres files in use not staying in linux file cache
  • From: Brio
• Re: huge pgstat.stat file on PostgreSQL 8.3.24
  • From: Huang, Suya
• Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: tim_wilson
• GIST optimization to limit calls to operator on sub nodes
  • From: Pujol Mathieu
• Re: huge pgstat.stat file on PostgreSQL 8.3.24
  • From: Tomas Vondra
• Re: huge pgstat.stat file on PostgreSQL 8.3.24
  • From: Pavel Stehule
• Re: huge pgstat.stat file on PostgreSQL 8.3.24
  • From: Huang, Suya
• Re: huge pgstat.stat file on PostgreSQL 8.3.24
  • From: Tomas Vondra
• Re: huge pgstat.stat file on PostgreSQL 8.3.24
  • From: Pavel Stehule
• Re: huge pgstat.stat file on PostgreSQL 8.3.24
  • From: Huang, Suya
• Re: huge pgstat.stat file on PostgreSQL 8.3.24
  • From: Pavel Stehule
• huge pgstat.stat file on PostgreSQL 8.3.24
  • From: Huang, Suya
• Re: Unable to allocate 2G of shared memory on wheezy
  • From: Tom Lane
• Re: Unable to allocate 2G of shared memory on wheezy
  • From: Dave Cramer
• Re: Unable to allocate 2G of shared memory on wheezy
  • From: Dave Cramer
• Re: Unable to allocate 2G of shared memory on wheezy
  • From: Tom Lane
• Unable to allocate 2G of shared memory on wheezy
  • From: Dave Cramer
• Re: 1 machine + master DB with postgres_fdw + multiple DB instances on different ports
  • From: Gezeala M. Bacuño II
• Re: 1 machine + master DB with postgres_fdw + multiple DB instances on different ports
  • From: Albe Laurenz
• 1 machine + master DB with postgres_fdw + multiple DB instances on different ports
  • From: Gezeala M. Bacuño II
• Re: postgres files in use not staying in linux file cache
  • From: Jeff Janes
• Re: Query memory usage greatly in excess of work_mem * query plan steps
  • From: Tom Lane
• Re: Query memory usage greatly in excess of work_mem * query plan steps
  • From: Franklin, Dan
• Re: postgres files in use not staying in linux file cache
  • From: Shaun Thomas
• Re: postgres files in use not staying in linux file cache
  • From: Tim Kane
• Re: OFFSET/LIMIT - Disparate Performance w/ Go application
  • From: Matt Silverlock
• Re: OFFSET/LIMIT - Disparate Performance w/ Go application
  • From: Jeff Janes
• Re: OFFSET/LIMIT - Disparate Performance w/ Go application
  • From: Merlin Moncure
• Re: OFFSET/LIMIT - Disparate Performance w/ Go application
  • From: Andreas Joseph Krogh
• Re: OFFSET/LIMIT - Disparate Performance w/ Go application
  • From: Merlin Moncure
• Re: OFFSET/LIMIT - Disparate Performance w/ Go application
  • From: Tom Lane
• OFFSET/LIMIT - Disparate Performance w/ Go application
  • From: Matt Silverlock
• Query memory usage greatly in excess of work_mem * query plan steps
  • From: Timothy Garnett
• Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: tim_wilson
• Re: Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: Tom Lane
• Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: tim_wilson
• Re: postgres files in use not staying in linux file cache
  • From: Shaun Thomas
• Re: UNION and bad performance
  • From: David G Johnston
• Re: UNION and bad performance
  • From: pinker
• Re:
  • From: Scott Marlowe
• Re:
  • From: Tom Lane
• [no subject]
  • From: Scott Marlowe
• Re: CPU load spikes when CentOS tries to reclaim 'cached' memory
  • From: Merlin Moncure
• Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: tim_wilson
• Re: CPU load spikes when CentOS tries to reclaim 'cached' memory
  • From: Steven Crandell
• Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: tim_wilson
• Re: Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: Tom Lane
• Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: tim_wilson
• Re: CPU load spikes when CentOS tries to reclaim 'cached' memory
  • From: Vincent Lasmarias
• postgres files in use not staying in linux file cache
  • From: Brio
• Re: Seqscan on big table, when an Index-Usage should be possible
  • From: Igor Neyman
• Re: High CPU load when 'free -m' shows low 'free' memory even though large 'cached' memory still available
  • From: Merlin Moncure
• Re: CPU load spikes when CentOS tries to reclaim 'cached' memory
  • From: Merlin Moncure
• Re: CPU load spikes when CentOS tries to reclaim 'cached' memory
  • From: Deron
• Seqscan on big table, when an Index-Usage should be possible
  • From: Weinzierl Stefan
• Re: CPU load spikes when CentOS tries to reclaim 'cached' memory
  • From: Merlin Moncure
• Re: CPU load spikes when CentOS tries to reclaim 'cached' memory
  • From: Jeff Janes
• Re: High CPU load when 'free -m' shows low 'free' memory even though large 'cached' memory still available
  • From: Tom Lane
• Re: Possible performance regression in PostgreSQL 9.2/9.3?
  • From: Linos
• Re: Possible performance regression in PostgreSQL 9.2/9.3?
  • From: Igor Neyman
• Re: parse/bind/execute
  • From: David Johnston
• Re: parse/bind/execute
  • From: Huang, Suya
• Re: parse/bind/execute
  • From: David G Johnston
• parse/bind/execute
  • From: Huang, Suya
• CPU load spikes when CentOS tries to reclaim 'cached' memory
  • From: vlasmarias
• Re: Possible performance regression in PostgreSQL 9.2/9.3?
  • From: Linos
• Re: Possible performance regression in PostgreSQL 9.2/9.3?
  • From: Merlin Moncure
• Re: Possible performance regression in PostgreSQL 9.2/9.3?
  • From: Linos
• Re: group commit
  • From: David G Johnston
• Re: Possible performance regression in PostgreSQL 9.2/9.3?
  • From: Merlin Moncure
• group commit
  • From: Evgeny Shishkin
• Possible performance regression in PostgreSQL 9.2/9.3?
  • From: Linos
• High CPU load when 'free -m' shows low 'free' memory even though large 'cached' memory still available
  • From: Vince Lasmarias
• Re[2]: [PERFORM] SELECT outage in semop
  • From: Suren Arustamyan
• Re: SELECT outage in semop
  • From: Albe Laurenz
• Re: SELECT outage in semop
  • From: Сурен Арустамян
• SELECT outage in semop
  • From: Сурен Арустамян
• Re: NFS, file system cache and shared_buffers
  • From: Albe Laurenz
• Re: NFS, file system cache and shared_buffers
  • From: Josh Berkus
• Re: Planner doesn't take indexes into account
  • From: Grzegorz Olszewski
• Re: Planner doesn't take indexes into account
  • From: Shaun Thomas
• Re: Planner doesn't take indexes into account
  • From: Heikki Linnakangas
• Re: Planner doesn't take indexes into account
  • From: Grzegorz Olszewski
• Re: NFS, file system cache and shared_buffers
  • From: Albe Laurenz
• Re: NFS, file system cache and shared_buffers
  • From: Albe Laurenz
• Re: Planner doesn't take indexes into account
  • From: AI Rumman
• Planner doesn't take indexes into account
  • From: Grzegorz Olszewski
• Re: NFS, file system cache and shared_buffers
  • From: John Melesky
• Re: NFS, file system cache and shared_buffers
  • From: Jeff Janes
• Re: NFS, file system cache and shared_buffers
  • From: Jeff Janes
• Re: NFS, file system cache and shared_buffers
  • From: David Boreham
• Re: NFS, file system cache and shared_buffers
  • From: Shaun Thomas
• Re: NFS, file system cache and shared_buffers
  • From: Albe Laurenz
• Re: NFS, file system cache and shared_buffers
  • From: Stephen Frost
• Re: NFS, file system cache and shared_buffers
  • From: Heikki Linnakangas
• NFS, file system cache and shared_buffers
  • From: Albe Laurenz
• Re: Profiling PostgreSQL
  • From: Matheus de Oliveira
• Re: Profiling PostgreSQL
  • From: Dimitris Karampinas
• Re: Profiling PostgreSQL
  • From: Jeff Janes
• Re: Profiling PostgreSQL
  • From: Dimitris Karampinas
• Re: Profiling PostgreSQL
  • From: Jeff Janes
• Re: Profiling PostgreSQL
  • From: Pavel Stehule
• Re: Profiling PostgreSQL
  • From: Dimitris Karampinas
• Re: same query different execution plan (hash join vs. semi-hash join)
  • From: Huang, Suya
• Re: Profiling PostgreSQL
  • From: Michael Paquier
• Re: Profiling PostgreSQL
  • From: Tom Lane
• Re: Profiling PostgreSQL
  • From: David Boreham
• Profiling PostgreSQL
  • From: Dimitris Karampinas
• Re: View has different query plan than select statement
  • From: Geoff Hull
• Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: Tom Lane
• Re: Query plan good in 8.4, bad in 9.2 and better in 9.3
  • From: Scott Marlowe
• Re: same query different execution plan (hash join vs. semi-hash join)
  • From: Tom Lane
• Re: View has different query plan than select statement
  • From: David Rowley
• Re: same query different execution plan (hash join vs. semi-hash join)
  • From: Huang, Suya
• View has different query plan than select statement
  • From: Geoff Hull
• Re: autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: tim_wilson
• autovacuum vacuum creates bad statistics for planner when it log index scans: 0
  • From: tim_wilson
• Re: same query different execution plan (hash join vs. semi-hash join)
  • From: Tom Lane
• same query different execution plan (hash join vs. semi-hash join)
  • From: Huang, Suya
• Re: Stats collector constant I/O
  • From: Tomas Vondra
• Re: Query plan good in 8.4, bad in 9.2 and better in 9.3
  • From: Jeff Janes
• Re: Query plan good in 8.4, bad in 9.2 and better in 9.3
  • From: Tom Lane
• Query plan good in 8.4, bad in 9.2 and better in 9.3
  • From: Scott Marlowe
• Re: how do functions affect query plan?
  • From: changchao
• Re: FW: how do functions affect query plan?
  • From: 楊新波
• Re: Stats collector constant I/O
  • From: Pavel Stehule
• Re: Stats collector constant I/O
  • From: Jeff Janes
• Re: how do functions affect query plan?
  • From: changchao
• Re: how do functions affect query plan?
  • From: changchao
• Re: how do functions affect query plan?
  • From: David G Johnston
• how do functions affect query plan?
  • From: 常超
• Stats collector constant I/O
  • From: Craig James
• Re: CPU spikes and transactions
  • From: Jeff Janes
• Re: CPU spikes and transactions
  • From: Merlin Moncure
• Re: CPU spikes and transactions
  • From: Dave Owens
• Re: Constraint exclusion won't exclude parent table
  • From: Tim Kane
• Re: Adaptive query execution
  • From: Tim Kane
• Re: Constraint exclusion won't exclude parent table
  • From: Tom Lane
• Re: Adaptive query execution
  • From: Claudio Freire
• Adaptive query execution
  • From: Tim Kane
• Constraint exclusion won't exclude parent table
  • From: Tim Kane
• Re: Specifications for a new server
  • From: Jeff Janes
• Re: Specifications for a new server
  • From: Michael Stone
• Re: Check memory consumption of postgresql query
  • From: Matheus de Oliveira
• Re: 9.2.4 vs 9.3.0 query planning (sort merge join vs hash join)
  • From: Jeff Janes
• Re: 9.2.4 vs 9.3.0 query planning (sort merge join vs hash join)
  • From: Tim Kane
• Re: 9.2.4 vs 9.3.0 query planning (sort merge join vs hash join)
  • From: Tom Lane
• 9.2.4 vs 9.3.0 query planning (sort merge join vs hash join)
  • From: Tim Kane
• Re: Check memory consumption of postgresql query
  • From: Phan Công Minh
• Re: Postgresql 9.3 for a Mobile Backend
  • From: Tomas Vondra
• Re: Check memory consumption of postgresql query
  • From: Clinton Adams
• Re: Specifications for a new server
  • From: Dorian Hoxha
• Re: Specifications for a new server
  • From: Johann Spies
• Re: Specifications for a new server
  • From: Johann Spies
• Re: Postgresql 9.3 for a Mobile Backend
  • From: desmodemone
• Postgresql 9.3 for a Mobile Backend
  • From: Rajiv Kasera
• Check memory consumption of postgresql query
  • From: Phan Công Minh
• Re: [PERFORM] Specifications for a new server
  • From: r.etzenhammer@xxxxxxxxxxx
• Re: Specifications for a new server
  • From: Tomas Vondra
• Re: Re: recently and selectively slow, but very simple, update query....
  • From: Stelios Mavromichalis
• Re: Specifications for a new server
  • From: Dorian Hoxha
• Re: Re: recently and selectively slow, but very simple, update query....
  • From: Stelios Mavromichalis
• Re: Specifications for a new server
  • From: Michael Stone
• Re: Specifications for a new server
  • From: Dorian Hoxha
• Re: Specifications for a new server
  • From: Michael Stone
• Re: Specifications for a new server
  • From: DFE
• Specifications for a new server
  • From: Johann Spies
• Re: recently and selectively slow, but very simple, update query....
  • From: David G Johnston
• Re: Re: recently and selectively slow, but very simple, update query....
  • From: Stelios Mavromichalis
• Re: recently and selectively slow, but very simple, update query....
  • From: David G Johnston
• Re: recently and selectively slow, but very simple, update query....
  • From: Stelios Mavromichalis
• Re: PostgreSQL's query planner is using the wrong index, what can I do to improve this situation?
  • From: David G Johnston
• Re: Optimize query for listing un-read messages
  • From: Vitalii Tymchyshyn
• Re: Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Re: Optimize query for listing un-read messages
  • From: Craig James
• Re: Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Re: Optimize query for listing un-read messages
  • From: David G Johnston
• Re: Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Re: Optimize query for listing un-read messages
  • From: David G Johnston
• Re: Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Re: Optimize query for listing un-read messages
  • From: Tomas Vondra
• Re: Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Re: Optimize query for listing un-read messages
  • From: Tomas Vondra
• Re: Revisiting disk layout on ZFS systems
  • From: Josh Berkus
• Re: Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Re: Optimize query for listing un-read messages
  • From: David G Johnston
• Re: Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Re: Optimize query for listing un-read messages
  • From: Pavel Stehule
• Re: Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Re: Optimize query for listing un-read messages
  • From: Pavel Stehule
• Re: Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Re: Optimize query for listing un-read messages
  • From: Pavel Stehule
• Re: Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Re: Optimize query for listing un-read messages
  • From: Jochem Berndsen