Postgres Performance Date Index

• Thread Index

• 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
• Optimize query for listing un-read messages
  • From: Andreas Joseph Krogh
• Checkpoints and slow queries
  • From: Elanchezhiyan Elango
• Re: Adding new field to big table
  • From: RichmondDyes
• Re: Slow queries on 9.3.1 despite use of index
  • From: Michael van Rooyen
• Re: Revisiting disk layout on ZFS systems
  • From: Karl Denninger
• Re: Revisiting disk layout on ZFS systems
  • From: Albe Laurenz
• Re: Slow queries on 9.3.1 despite use of index
  • From: Tom Lane
• Re: Slow queries on 9.3.1 despite use of index
  • From: Michael van Rooyen
• Re: Checkpoints and slow queries
  • From: Tomas Vondra
• Re: Checkpoints and slow queries
  • From: Tomas Vondra
• Re: Checkpoints and slow queries
  • From: Tomas Vondra
• Re: Checkpoints and slow queries
  • From: Jeff Janes
• Re: Checkpoints and slow queries
  • From: Tomas Vondra
• Re: Revisiting disk layout on ZFS systems
  • From: Karl Denninger
• Re: Revisiting disk layout on ZFS systems
  • From: Jeff Janes
• Re: Revisiting disk layout on ZFS systems
  • From: Karl Denninger
• Re: Revisiting disk layout on ZFS systems
  • From: Heikki Linnakangas
• Re: Revisiting disk layout on ZFS systems
  • From: Karl Denninger
• Re: Revisiting disk layout on ZFS systems
  • From: Heikki Linnakangas
• Re: Slow queries on 9.3.1 despite use of index
  • From: Jeff Janes
• Re: Slow queries on 9.3.1 despite use of index
  • From: Tom Lane
• Slow queries on 9.3.1 despite use of index
  • From: Michael van Rooyen
• Revisiting disk layout on ZFS systems
  • From: Karl Denninger
• Re: Checkpoints and slow queries
  • From: Tom Lane
• Varying performacne results after instance restart
  • From: MadDamon
• Re: Checkpoints and slow queries
  • From: Elanchezhiyan Elango
• Re: Checkpoints and slow queries
  • From: Tomas Vondra
• Checkpoints and slow queries
  • From: Elanchezhiyan Elango
• Re: pl/pgsql performance
  • From: Michael Paquier
• Re: Poor performance for delete query
  • From: Tom Lane
• Re: Server vacuuming the same table again and again
  • From: Дмитрий Шалашов
• Re: Server vacuuming the same table again and again
  • From: Ilya Kosmodemiansky
• Re: Server vacuuming the same table again and again
  • From: Ilya Kosmodemiansky
• Re: Server vacuuming the same table again and again
  • From: Ilya Kosmodemiansky
• Re: Server vacuuming the same table again and again
  • From: Torsten Förtsch
• Re: Server vacuuming the same table again and again
  • From: Дмитрий Шалашов
• Re: pl/pgsql performance
  • From: Pavel Stehule
• pl/pgsql performance
  • From: Mehdi Ravanbakhsh
• Re: Server vacuuming the same table again and again
  • From: Дмитрий Шалашов
• Re: Server vacuuming the same table again and again
  • From: Дмитрий Шалашов
• Re: Server vacuuming the same table again and again
  • From: Ilya Kosmodemiansky
• Server vacuuming the same table again and again
  • From: Дмитрий Шалашов
• Re: tsearch2, large data and indexes
  • From: Heikki Linnakangas
• Re: Poor performance for delete query
  • From: Jonatan Evald Buus
• Re: Poor performance for delete query
  • From: Tom Lane
• Re: Poor performance for delete query
  • From: Jonatan Evald Buus
• Re: Poor performance for delete query
  • From: Tom Lane
• Re: tsearch2, large data and indexes
  • From: Sergey Konoplev
• Poor performance for delete query
  • From: Jonatan Evald Buus
• Re: tsearch2, large data and indexes
  • From: Sergey Konoplev
• Re: tsearch2, large data and indexes
  • From: Ivan Voras
• Re: tsearch2, large data and indexes
  • From: Heikki Linnakangas
• Re: tsearch2, large data and indexes
  • From: Sergey Konoplev
• Re: HFS+ pg_test_fsync performance
  • From: Josh Berkus
• Re: HFS+ pg_test_fsync performance
  • From: Mel Llaguno
• Re: HFS+ pg_test_fsync performance
  • From: Josh Berkus
• Re: tsearch2, large data and indexes
  • From: Heikki Linnakangas
• Re: tsearch2, large data and indexes
  • From: Matheus de Oliveira
• Re: tsearch2, large data and indexes
  • From: Ivan Voras
• Re: Best practices for update timestamp with/without triggers
  • From: hubert depesz lubaczewski
• Best practices for update timestamp with/without triggers
  • From: Verghese, Riya
• Help on migrating data from MSSQL2008R2 to PostgreSQL 9.3
  • From: Wureka JI
• Re: tsearch2, large data and indexes
  • From: Jeff Janes
• Re: Stalls on PGSemaphoreLock
  • From: Matheus de Oliveira
• Re: Stalls on PGSemaphoreLock
  • From: Matthew Spilich
• Re: Workaround: Planner preference for tsquery filter vs. GIN index in fast text search
  • From: Tom Lane
• Query on partitioned table not using index
  • From: Souquieres Adam
• Re: tsearch2, large data and indexes
  • From: Ivan Voras
• Re: Workaround: Planner preference for tsquery filter vs. GIN index in fast text search
  • From: Oleg Bartunov
• Re: tsearch2, large data and indexes
  • From: Heikki Linnakangas
• Re: Workaround: Planner preference for tsquery filter vs. GIN index in fast text search
  • From: Heikki Linnakangas
• Re: Best practice question
  • From: Sergey Konoplev
• Re: Best practice question
  • From: David G Johnston
• Best practice question
  • From: Tory M Blue
• Re: Fast distinct not working as expected
  • From: Merlin Moncure
• Re: IP addresses, NetBlocks, and ASNs
  • From: Gary Warner
• Re: IP addresses, NetBlocks, and ASNs
  • From: Steve Atkins
• Re: Workaround: Planner preference for tsquery filter vs. GIN index in fast text search
  • From: Laurence Parry
• Re: Workaround: Planner preference for tsquery filter vs. GIN index in fast text search
  • From: Oleg Bartunov
• Workaround: Planner preference for tsquery filter vs. GIN index in fast text search
  • From: Laurence Parry
• IP addresses, NetBlocks, and ASNs
  • From: Gary Warner
• Re: Hot standby 9.2.1 PANIC: WAL contains references to invalid pages
  • From: Sergey Konoplev
• tsearch2, large data and indexes
  • From: Ivan Voras
• Hot standby 9.2.1 PANIC: WAL contains references to invalid pages
  • From: Vishalakshi Navaneethakrishnan
• Re: Fast distinct not working as expected
  • From: Franck Routier
• Re: Fast distinct not working as expected
  • From: Franck Routier
• Re: Fast distinct not working as expected
  • From: Jeff Janes
• Re: Fast distinct not working as expected
  • From: Franck Routier
• Re: Fast distinct not working as expected
  • From: Jeff Janes
• Fast distinct not working as expected
  • From: Franck Routier
• Re: Workaround for working_mem max value in windows?
  • From: amul sul
• Re: Workaround for working_mem max value in windows?
  • From: Nick Eubank
• Re: Workaround for working_mem max value in windows?
  • From: Jeff Janes
• Re: Workaround for working_mem max value in windows?
  • From: Martin French
• Re: Workaround for working_mem max value in windows?
  • From: Nick Eubank
• Re: unneeded joins on view
  • From: Linos
• Re: unneeded joins on view
  • From: Heikki Linnakangas
• unneeded joins on view
  • From: Linos
• Queries very slow after data size increases
  • From: sheishere b
• Re: Workaround for working_mem max value in windows?
  • From: amulsul
• Re: Workaround for working_mem max value in windows?
  • From: Martin French
• Workaround for working_mem max value in windows?
  • From: Nick Eubank
• Re: Testing strategies
  • From: Matheus de Oliveira
• Tuning Postgres for Single connection use
  • From: Nick Eubank
• Re: Tuning Postgres for Single connection use
  • From: Tom Lane
• Re: Tuning Postgres for Single connection use
  • From: Schnabel, Robert D.
• Re: Tuning Postgres for Single connection use
  • From: Jeff Janes
• Re: Tuning Postgres for Single connection use
  • From: Nick Eubank
• Testing strategies
  • From: Dave Cramer
• Re: [GENERAL] Approach to Data Summary and Analysis
  • From: Robert DiFalco
• Re: [GENERAL] Approach to Data Summary and Analysis
  • From: Chris Curvey
• Re: [GENERAL] Approach to Data Summary and Analysis
  • From: Chris Curvey
• Re: HFS+ pg_test_fsync performance
  • From: Mel Llaguno
• Re: HFS+ pg_test_fsync performance
  • From: desmodemone
• Re: Checkpoint distribution
  • From: Borodin Vladimir
• Re: SSI slows down over time
  • From: Ryan Johnson
• Re: Tuning Postgres for Single connection use
  • From: Nick Eubank
• Re: Tuning Postgres for Single connection use
  • From: Gavin Flower
• Re: Tuning Postgres for Single connection use
  • From: Jeff Janes
• Re: Tuning Postgres for Single connection use
  • From: Andrew Dunstan
• Re: Tuning Postgres for Single connection use
  • From: Nick Eubank
• Re: Tuning Postgres for Single connection use
  • From: Gavin Flower
• HFS+ pg_test_fsync performance
  • From: Mel Llaguno
• Tuning Postgres for Single connection use
  • From: Nick Eubank
• Re: SSI slows down over time
  • From: Ryan Johnson
• Re: Getting query plan alternatives from query planner?
  • From: Heikki Linnakangas
• Re: Getting query plan alternatives from query planner?
  • From: Stefan Keller
• Re: Checkpoint distribution
  • From: Jeff Janes
• Re: Checkpoint distribution
  • From: Borodin Vladimir
• Approach to Data Summary and Analysis
  • From: Robert DiFalco
• Re: SSI slows down over time
  • From: Kevin Grittner
• Re: Getting query plan alternatives from query planner?
  • From: Craig James
• Re: Checkpoint distribution
  • From: Jeff Janes
• Re: Getting query plan alternatives from query planner?
  • From: Eric Schwarzenbach
• Re: Getting query plan alternatives from query planner?
  • From: Kevin Grittner
• Re: SSI slows down over time
  • From: Ryan Johnson
• Re: SSI slows down over time
  • From: Kevin Grittner
• Re: Ye olde slow query
  • From: Murphy, Kevin
• Re: SSI slows down over time
  • From: Ryan Johnson
• SSI slows down over time
  • From: Ryan Johnson
• Checkpoint distribution
  • From: Borodin Vladimir
• Re: batch update query performance
  • From: Jeff Janes
• Re: query against large table not using sensible index to find very small amount of data
  • From: Andrew W. Gibbs
• Re: performance degradation after launching postgres cluster using pgpool-II
  • From: Cora Ma
• Re: batch update query performance
  • From: Hans Drexler
• Re: SSI slows down over time
  • From: Ryan Johnson
• Re: SSI slows down over time
  • From: Bruce Momjian
• Re: Optimizing Time Series Access
  • From: Robert Burgholzer
• Interesting case of index un-usage
  • From: Claudio Freire
• Re: PGSQL, checkpoints, and file system syncs
  • From: Bruce Momjian
• Re: PGSQL, checkpoints, and file system syncs
  • From: Bruce Momjian
• Re: Why shared_buffers max is 8GB?
  • From: Bruce Momjian
• Re: Performance regressions in PG 9.3 vs PG 9.0
  • From: Tom Lane
• Re: query against large table not using sensible index to find very small amount of data
  • From: 'Andrew W. Gibbs'
• Re: Performance regressions in PG 9.3 vs PG 9.0
  • From: uher dslij
• Re: Performance regressions in PG 9.3 vs PG 9.0
  • From: uher dslij
• Re: query against large table not using sensible index to find very small amount of data
  • From: Jeff Janes
• Re: Performance regressions in PG 9.3 vs PG 9.0
  • From: Tom Lane
• Optimizing Time Series Access
  • From: Robert Burgholzer
• Re: Nested loop issue
  • From: Dhananjay Singh
• Re: Performance regressions in PG 9.3 vs PG 9.0
  • From: uher dslij
• Re: [SQL] Re: performance drop when function argument is evaluated in WHERE clause
  • From: Tom Lane
• Re: performance drop when function argument is evaluated in WHERE clause
  • From: Gerardo Herzig
• Re: PGSQL, checkpoints, and file system syncs
  • From: Shaun Thomas
• Re: query against large table not using sensible index to find very small amount of data
  • From: Tom Lane
• Re: performance drop when function argument is evaluated in WHERE clause
  • From: Tom Lane
• Re: query against large table not using sensible index to find very small amount of data
  • From: Shaun Thomas
• query against large table not using sensible index to find very small amount of data
  • From: Andrew W. Gibbs
• performance drop when function argument is evaluated in WHERE clause
  • From: Gerardo Herzig
• Nested loop issue
  • From: Manoj Gadi
• Re: Batch update query performance
  • From: Jeff Janes
• Performance regressions in PG 9.3 vs PG 9.0
  • From: uher dslij
• Re: SSI slows down over time
  • From: Ryan Johnson
• Re: SSI slows down over time
  • From: Ryan Johnson
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: Graeme B. Bell
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: Nicolas Paris
• Re: performance degradation after launching postgres cluster using pgpool-II
  • From: Tatsuo Ishii
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: Graeme B. Bell
• Re: Batch update query performance
  • From: Heikki Linnakangas
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: Nicolas Paris
• Re: Batch update query performance
  • From: Albe Laurenz
• PGSQL, checkpoints, and file system syncs
  • From: Reza Taheri
• Batch update query performance
  • From: Hans Drexler
• performance degradation after launching postgres cluster using pgpool-II
  • From: Cora Ma
• Re: The same query - much different runtimes
  • From: Pavan Deolasee
• Re: SSI slows down over time
  • From: Ryan Johnson
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: Graeme B. Bell
• The same query - much different runtimes
  • From: Johann Spies
• Re: Slow Count-Distinct Query
  • From: Varadharajan Mukundan
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: PARIS Nicolas
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: Thom Brown
• Slow Count-Distinct Query
  • From: Jeff Janes
• Re: SSI slows down over time
  • From: Tom Lane
• Re: SSI slows down over time
  • From: Heikki Linnakangas
• SSI slows down over time
  • From: Ryan Johnson
• Re: Fwd: Slow Count-Distinct Query
  • From: Varadharajan Mukundan
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: ktm@xxxxxxxx
• Re: PGSQL, checkpoints, and file system syncs
  • From: Reza Taheri
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: PARIS Nicolas
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: Thom Brown
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: PARIS Nicolas
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: Thom Brown
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: PARIS Nicolas
• Re: Fwd: Slow Count-Distinct Query
  • From: Jeff Janes
• Re: PGSQL 9.3 - Materialized View - multithreading
  • From: Thom Brown
• PGSQL 9.3 - Materialized View - multithreading
  • From: Nicolas Paris
• Fwd: Slow Count-Distinct Query
  • From: Varadharajan Mukundan
• Re: PGSQL, checkpoints, and file system syncs
  • From: Ilya Kosmodemiansky
• Re: PGSQL, checkpoints, and file system syncs
  • From: Reza Taheri
• Re: PGSQL, checkpoints, and file system syncs
  • From: Heikki Linnakangas
• PGSQL, checkpoints, and file system syncs
  • From: Reza Taheri
• Re: Sudden crazy high CPU usage
  • From: Michael Paquier
• Re: Why shared_buffers max is 8GB?
  • From: Alexey Klyukin
• Re: Slow Count-Distinct Query
  • From: Christopher Jackson
• Re: Slow Count-Distinct Query
  • From: Michael Paquier
• Re: Slow Count-Distinct Query
  • From: Christopher Jackson
• Re: Slow Count-Distinct Query
  • From: bricklen
• Re: Sudden crazy high CPU usage
  • From: Andres Freund
• Re: Sudden crazy high CPU usage
  • From: Niels Kristian Schjødt
• Re: Sudden crazy high CPU usage
  • From: Will Platnick
• Re: Sudden crazy high CPU usage
  • From: Sergey Konoplev
• Re: Sudden crazy high CPU usage
  • From: Niels Kristian Schjødt
• Re: Sudden crazy high CPU usage
  • From: Niels Kristian Schjødt
• Re: Slow Count-Distinct Query
  • From: Christopher Jackson
• Re: Sudden crazy high CPU usage
  • From: Scott Marlowe
• Re: Sudden crazy high CPU usage
  • From: Merlin Moncure
• Re: Sudden crazy high CPU usage
  • From: Niels Kristian Schjødt
• Re: Slow Count-Distinct Query
  • From: Tom Lane
• Re: Sudden crazy high CPU usage
  • From: Merlin Moncure
• Re: Slow Count-Distinct Query
  • From: Shaun Thomas
• Sudden crazy high CPU usage
  • From: Niels Kristian Schjødt
• Slow Count-Distinct Query
  • From: Christopher Jackson
• Re: Connection pooling - Number of connections
  • From: Brett Wooldridge
• Re: Connection pooling - Number of connections
  • From: Jeff Janes
• Partitions and prepared statements?
  • From: Dave Johansen
• Re: Stalls on PGSemaphoreLock
  • From: Gudmundsson Martin (mg)
• semaphore waits and performance stall
  • From: Matthew Spilich
• Re: Stalls on PGSemaphoreLock
  • From: Pavy Philippe
• RE : Stalls on PGSemaphoreLock
  • From: Pavy Philippe
• Re: Connection pooling - Number of connections
  • From: Brett Wooldridge
• Re: Connection pooling - Number of connections
  • From: Josh Berkus
• Re: Why shared_buffers max is 8GB?
  • From: Ilya Kosmodemiansky
• Re: Why shared_buffers max is 8GB?
  • From: Shaun Thomas
• Re: Why shared_buffers max is 8GB?
  • From: desmodemone
• Re: Why shared_buffers max is 8GB?
  • From: Scott Marlowe
• Re: Why shared_buffers max is 8GB?
  • From: Martin French
• Re: Why shared_buffers max is 8GB?
  • From: Markella Skempri
• Re: Why shared_buffers max is 8GB?
  • From: Martin French
• Re: Why shared_buffers max is 8GB?
  • From: Martin French