Postgres Performance Date Index

• Thread Index

• Re: Query Plan Performance on Partitioned Table
  • From: Rural Hunter
• Re: Query Plan Performance on Partitioned Table
  • From: Maxim Boguk
• Re: Query Plan Performance on Partitioned Table
  • From: Rural Hunter
• Re: Query Plan Performance on Partitioned Table
  • From: Maxim Boguk
• Query Plan Performance on Partitioned Table
  • From: Rural Hunter
• Re: Slow HashAggregate/cache access
  • From: David Rowley
• Re: Slow HashAggregate/cache access
  • From: Andreas Joseph Krogh
• Re: Slow HashAggregate/cache access
  • From: Alexandre de Arruda Paes
• Re: Slow HashAggregate/cache access
  • From: Alexandre de Arruda Paes
• Re: Slow HashAggregate/cache access
  • From: David Rowley
• Re: Slow HashAggregate/cache access
  • From: David Rowley
• Re: Slow HashAggregate/cache access
  • From: Andreas Joseph Krogh
• Re: Slow HashAggregate/cache access
  • From: Alexandre de Arruda Paes
• Re: Slow HashAggregate/cache access
  • From: Andreas Joseph Krogh
• Re: Slow HashAggregate/cache access
  • From: Alexandre de Arruda Paes
• Re: Slow HashAggregate/cache access
  • From: Maxim Boguk
• Re: Slow HashAggregate/cache access
  • From: Kevin Grittner
• Re: Performance issue with NestedLoop query
  • From: Qingqing Zhou
• Re: Performance issue with NestedLoop query
  • From: Ram N
• Slow HashAggregate/cache access
  • From: Alexandre de Arruda Paes
• Re: Performance issue with NestedLoop query
  • From: Qingqing Zhou
• Re: Performance issue with NestedLoop query
  • From: Matheus de Oliveira
• Re: Performance issue with NestedLoop query
  • From: Matheus de Oliveira
• Re: Performance issue with NestedLoop query
  • From: Ram N
• Re: Performance issue with NestedLoop query
  • From: Qingqing Zhou
• Performance issue with NestedLoop query
  • From: Ram N
• Re: Are many idle connections bad?
  • From: Alex Hunsaker
• incredible surprise news from intel/micron right now...
  • From: Graeme B. Bell
• Re: autofreeze/vacuuming - avoiding the random performance hit
  • From: Graeme B. Bell
• Re: autofreeze/vacuuming - avoiding the random performance hit
  • From: Wei Shan
• autofreeze/vacuuming - avoiding the random performance hit
  • From: Graeme B. Bell
• Re: Any ideas how can I speed up this query?
  • From: 林士博
• Re: Any ideas how can I speed up this query?
  • From: Graeme B. Bell
• Any ideas how can I speed up this query?
  • From: Priyank Tiwari
• Re: Are many idle connections bad?
  • From: Jeff Janes
• Re: Are many idle connections bad?
  • From: Craig James
• Re: Are many idle connections bad?
  • From: Tom Lane
• Are many idle connections bad?
  • From: Craig James
• Re: hyperthreadin low performance
  • From: Mark Kirkwood
• Re: bitmap heap scan recheck for gin/fts with no lossy blocks
  • From: Jeff Janes
• Re: bitmap heap scan recheck for gin/fts with no lossy blocks
  • From: Laurent Debacker
• Re: bitmap heap scan recheck for gin/fts with no lossy blocks
  • From: Jeff Janes
• bitmap heap scan recheck for gin/fts with no lossy blocks
  • From: Laurent Debacker
• parallelisation provides postgres performance (script example + ppt slides)
  • From: Graeme B. Bell
• Re: hyperthreadin low performance (and some discussion about benchmarking)
  • From: Graeme B. Bell
• Re: hyperthreadin low performance
  • From: domenico febbo
• Re: How to find the culprit in server load spikes?
  • From: Jeff Janes
• Re: How to find the culprit in server load spikes?
  • From: Kevin Grittner
• How to find the culprit in server load spikes?
  • From: Moreno Andreo
• Re: hyperthreadin low performance
  • From: Mark Kirkwood
• Re: hyperthreadin low performance
  • From: David Rowley
• hyperthreadin low performance
  • From: Jeison Bedoya Delgado
• Re: Different plan for very similar queries
  • From: Peter J. Holzer
• Re: intel s3500 -- hot stuff
  • From: Julien Rouhaud
• Re: Insert vs Update
  • From: Guillaume Lelarge
• Re: Insert vs Update
  • From: David G. Johnston
• Re: Insert vs Update
  • From: Michael Nolan
• Re: Insert vs Update
  • From: Robert DiFalco
• Re: Insert vs Update
  • From: David G. Johnston
• Re: Insert vs Update
  • From: Robert DiFalco
• Re: Insert vs Update
  • From: David G. Johnston
• Re: Insert vs Update
  • From: Robert DiFalco
• Re: Insert vs Update
  • From: David G. Johnston
• Re: Insert vs Update
  • From: Michael Nolan
• Re: Insert vs Update
  • From: David G. Johnston
• Insert vs Update
  • From: Robert DiFalco
• Re: Query planner not using indexes with JOIN query and OR clause
  • From: Ben Hoyt
• Re: Query planner not using indexes with JOIN query and OR clause
  • From: Merlin Moncure
• Re: [ADMIN] could not create shared memory segment: Invalid argument
  • From: Scott Whitney
• Re: [ADMIN] could not create shared memory segment: Invalid argument
  • From: Ryan King - NOAA Affiliate
• Re: Query planner not using indexes with JOIN query and OR clause
  • From: Merlin Moncure
• Query planner not using indexes with JOIN query and OR clause
  • From: Ben Hoyt
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: James Cloos
• Re: QUERY PLANNER - Indexe mono column VS composite Index
  • From: Jeff Janes
• Re: QUERY PLANNER - Indexe mono column VS composite Index
  • From: Nicolas Paris
• Re: QUERY PLANNER - Indexe mono column VS composite Index
  • From: Guillaume Lelarge
• QUERY PLANNER - Indexe mono column VS composite Index
  • From: Nicolas Paris
• Re: pg_stat_all_indexes understand
  • From: Jeff Janes
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: [BUGS] BUG #13493: pl/pgsql doesn't scale with cpus (PG9.3, 9.4)
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Thomas Kellerer
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• pg_stat_all_indexes understand
  • From: Nicolas Paris
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Andres Freund
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Andres Freund
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Tom Lane
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Andres Freund
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Craig James
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Andres Freund
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Craig James
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Joshua D. Drake
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Craig James
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Andres Freund
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: wildcard text filter switched to boolean column, performance is way worse
  • From: Marc Mamin
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Joshua D. Drake
• Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Craig James
• Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Heikki Linnakangas
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Heikki Linnakangas
• Re: New server: SSD/RAID recommendations?
  • From: Merlin Moncure
• Re: New server: SSD/RAID recommendations?
  • From: Wes Vaske (wvaske)
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Scott Marlowe
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Michael Nolan
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Scott Marlowe
• Re: New server: SSD/RAID recommendations?
  • From: Karl Denninger
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Wei Shan
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Merlin Moncure
• Re: wildcard text filter switched to boolean column, performance is way worse
  • From: Mike Broers
• Re: New server: SSD/RAID recommendations?
  • From: Vitalii Tymchyshyn
• Re: wildcard text filter switched to boolean column, performance is way worse
  • From: Mike Broers
• Re: wildcard text filter switched to boolean column, performance is way worse
  • From: Tom Lane
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• wildcard text filter switched to boolean column, performance is way worse
  • From: Mike Broers
• Re: New server: SSD/RAID recommendations?
  • From: Heikki Linnakangas
• Re: New server: SSD/RAID recommendations?
  • From: Wes Vaske (wvaske)
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Merlin Moncure
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Karl Denninger
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: eudald_v
• Re: New server: SSD/RAID recommendations?
  • From: Karl Denninger
• Re: New server: SSD/RAID recommendations?
  • From: Mkrtchyan, Tigran
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: New server: SSD/RAID recommendations?
  • From: Mkrtchyan, Tigran
• Re: New server: SSD/RAID recommendations?
  • From: Graeme B. Bell
• Re: 9.5alpha1 vs 9.4
  • From: Mkrtchyan, Tigran
• Re: New server: SSD/RAID recommendations?
  • From: Joshua D. Drake
• Re: New server: SSD/RAID recommendations?
  • From: Steve Crawford
• Re: 9.5alpha1 vs 9.4
  • From: Josh Berkus
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Merlin Moncure
• Re: 9.5alpha1 vs 9.4
  • From: Mkrtchyan, Tigran
• Re: pgbouncer issue
  • From: Greg Sabino Mullane
• Re: 9.5alpha1 vs 9.4
  • From: Tom Lane
• Re: 9.5alpha1 vs 9.4
  • From: Andres Freund
• Re: 9.5alpha1 vs 9.4
  • From: Mkrtchyan, Tigran
• 9.5alpha1 vs 9.4
  • From: Mkrtchyan, Tigran
• Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Marc Mamin
• Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
  • From: Graeme B. Bell
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Scott Marlowe
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Kevin Grittner
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Josh Berkus
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Josh Berkus
• Re: New server: SSD/RAID recommendations?
  • From: Wes Vaske (wvaske)
• Re: New server: SSD/RAID recommendations?
  • From: Craig James
• Re: New server: SSD/RAID recommendations?
  • From: Craig James
• Re: New server: SSD/RAID recommendations?
  • From: Craig James
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: eudald_v
• Re: New server: SSD/RAID recommendations?
  • From: Merlin Moncure
• Re: New server: SSD/RAID recommendations?
  • From: Wes Vaske (wvaske)
• Re: New server: SSD/RAID recommendations?
  • From: Scott Marlowe
• Re: New server: SSD/RAID recommendations?
  • From: Andreas Joseph Krogh
• New server: SSD/RAID recommendations?
  • From: Craig James
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Josh Berkus
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: eudald_v
• Re: Sudden connection and load average spikes with postgresql 9.3
  • From: Tom Lane
• Sudden connection and load average spikes with postgresql 9.3
  • From: eudald_v
• Does anyone have python code which digests pgbench -r output?
  • From: Josh Berkus
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Mark Kirkwood
• pgbouncer issue
  • From: Sheena, Prabhjot
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Jim Nasby
• Re: Techniques to Avoid Temp Files
  • From: Jeff Janes
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Igor Neyman
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Igor Neyman
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Ian Pushee
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Ian Pushee
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Andreas Kretschmer
• Re: Slow query (planner insisting on using 'external merge' sort type)
  • From: Igor Neyman
• Slow query (planner insisting on using 'external merge' sort type)
  • From: Ian Pushee
• Re: Techniques to Avoid Temp Files
  • From: Albe Laurenz
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Sheena, Prabhjot
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: ktm@xxxxxxxx
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Igor Neyman
• Re: How to calculate statistics for one column
  • From: Igor Neyman
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Jerry Sievers
• Techniques to Avoid Temp Files
  • From: Duane Murphy
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Sheena, Prabhjot
• Re: How to calculate statistics for one column
  • From: Irineu Ruiz
• Re: How to calculate statistics for one column
  • From: Igor Neyman
• Re: How to calculate statistics for one column
  • From: Irineu Ruiz
• Re: How to calculate statistics for one column
  • From: Igor Neyman
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: ktm@xxxxxxxx
• How to calculate statistics for one column
  • From: Irineu Ruiz
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Sheena, Prabhjot
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Will Platnick
• Re: PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: ktm@xxxxxxxx
• PGBOUNCER ISSUE PLEASE HELP(Slowing down the site)
  • From: Sheena, Prabhjot
• Re: Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux?
  • From: Tomas Vondra
• Re: Slow query: Postgres chooses nested loop over hash join, whery by hash join is much faster, wrong number of rows estimated
  • From: Merlin Moncure
• Re: Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux?
  • From: Kaijiang Chen
• Re: Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux?
  • From: Joe Conway
• Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux?
  • From: Kaijiang Chen
• Re: Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux?
  • From: Joshua D. Drake
• Re: pg bouncer issue what does sv_used column means
  • From: ktm@xxxxxxxx
• Re: pg bouncer issue what does sv_used column means
  • From: Andrew Dunstan
• Re: pg bouncer issue what does sv_used column means
  • From: Sheena, Prabhjot
• Re: Are there tuning parameters that don't take effect immediately?
  • From: Michael Nolan
• Re: Are there tuning parameters that don't take effect immediately?
  • From: Joshua D. Drake
• Re: Are there tuning parameters that don't take effect immediately?
  • From: David G. Johnston
• Are there tuning parameters that don't take effect immediately?
  • From: Michael Nolan
• Re: pg bouncer issue what does sv_used column means
  • From: Xenofon Papadopoulos
• pg bouncer issue what does sv_used column means
  • From: Sheena, Prabhjot
• Re: Slow query - lots of temporary files.
  • From: Johann Spies
• Slow query: Postgres chooses nested loop over hash join, whery by hash join is much faster, wrong number of rows estimated
  • From: Sasa Vilic
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Claudio Freire
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: ben.play
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Merlin Moncure
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Patrick Krecker
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Merlin Moncure
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Patrick Krecker
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Merlin Moncure
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Josh Berkus
• Re: Row estimates off by two orders of magnitude with hstore
  • From: Merlin Moncure
• Row estimates off by two orders of magnitude with hstore
  • From: Patrick Krecker
• Re: Slow query - lots of temporary files.
  • From: Tomas Vondra
• Re: Slow query - lots of temporary files.
  • From: Johann Spies
• Re: Slow query - lots of temporary files.
  • From: Claudio Freire
• Slow query - lots of temporary files.
  • From: Johann Spies
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Claudio Freire
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: ben.play
• Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Matheus de Oliveira
• Re: Re: [GENERAL] Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Steve Crawford
• Re: [GENERAL] Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Steve Crawford
• Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Igor Neyman
• Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Sheena, Prabhjot
• Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Steve Crawford
• Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Igor Neyman
• Query running slow for only one specific id. (Postgres 9.3) version
  • From: Sheena, Prabhjot
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: Need more IOPS? This should get you drooling... (5xnvme drives)
  • From: Graeme B. Bell
• Re: Need more IOPS? This should get you drooling... (5xnvme drives)
  • From: Dorian Hoxha
• Re: Need more IOPS? This should get you drooling... (5xnvme drives)
  • From: Graeme B. Bell
• Need more IOPS? This should get you drooling... (5xnvme drives)
  • From: Graeme B. Bell
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Mark Kirkwood
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Scott Marlowe
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Scott Marlowe
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Yves Dorfsman
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Joshua D. Drake
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Claudio Freire
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Scott Marlowe
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Claudio Freire
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Scott Marlowe
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: ben.play
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: Tomas Vondra
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: chiru r
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: amulsul
• Re: How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: David G. Johnston
• How to reduce writing on disk ? (90 gb on pgsql_tmp)
  • From: ben.play
• Re: Postgres is using 100% CPU
  • From: Ashik S L
• Re: Postgres is using 100% CPU
  • From: Graeme B. Bell
• Re: Postgres is using 100% CPU
  • From: Graeme B. Bell
• Re: Connection time when using SSL
  • From: Tomas Vondra
• Connection time when using SSL
  • From: Marco Di Cesare
• Re: Postgres is using 100% CPU
  • From: Scott Marlowe
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: Kevin Grittner
• Re: Slow hash join performance with many batches
  • From: Tom Lane
• Slow hash join performance with many batches
  • From: Alex Adriaanse
• Re: Postgres is using 100% CPU
  • From: Merlin Moncure
• Re: Postgres is using 100% CPU
  • From: Ashik S L
• Re: Different plan for very similar queries
  • From: Tomas Vondra
• Re: Different plan for very similar queries
  • From: Tom Lane
• Re: Different plan for very similar queries
  • From: Tomas Vondra
• Re: Different plan for very similar queries
  • From: Tom Lane
• Re: Postgres is using 100% CPU
  • From: Yves Dorfsman
• Re: Postgres is using 100% CPU
  • From: Jean-David Beyer
• Re: Different plan for very similar queries
  • From: Peter J. Holzer
• Re: Postmaster eating up all my cpu
  • From: Tomas Vondra
• Postmaster eating up all my cpu
  • From: birimblongas
• Re: Different plan for very similar queries
  • From: Tom Lane
• Re: Postgres is using 100% CPU
  • From: Tomas Vondra
• Re: Postgres is using 100% CPU
  • From: Ashik S L
• Re: Different plan for very similar queries
  • From: Tomas Vondra
• Re: Postgres is using 100% CPU
  • From: Tomas Vondra
• Re: Postgres is using 100% CPU
  • From: Yves Dorfsman
• Postgres is using 100% CPU
  • From: Ashik S L
• Fwd: Postgres is using 100% CPU
  • From: Ashik S L
• Re: Different plan for very similar queries
  • From: Peter J. Holzer
• Different plan for very similar queries
  • From: Peter J. Holzer
• Re: Partitioning and performance
  • From: Jim Nasby
• Re: Fastest Backup & Restore for perf testing
  • From: Jim Nasby
• Re: Partitioning and performance
  • From: Ravi Krishna
• Partitioning and performance
  • From: Ravi Krishna
• Re: ERROR: missing chunk number 0 for toast value 1821556134 in pg_toast_17881
  • From: Josh Berkus
• Re: Fastest Backup & Restore for perf testing
  • From: Steve Atkins
• Re: Fastest Backup & Restore for perf testing
  • From: Andrew Dunstan
• Fastest Backup & Restore for perf testing
  • From: Wes Vaske (wvaske)
• ERROR: missing chunk number 0 for toast value 1821556134 in pg_toast_17881
  • From: Tory M Blue
• Re: MAX() and multi-column index on a partitioned table?
  • From: Tom Lane
• Re: MAX() and multi-column index on a partitioned table?
  • From: Dave Johansen
• Re: MAX() and multi-column index on a partitioned table?
  • From: Tom Lane
• MAX() and multi-column index on a partitioned table?
  • From: Dave Johansen
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: Jim Nasby
• Re: How to clean/truncate / VACUUM FULL pg_largeobject without (much) downtime?
  • From: Jim Nasby
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Josh Berkus
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Vitalii Tymchyshyn
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Andres Freund
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Josh Berkus
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: David G. Johnston
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: Bosco Rama
• Re: union all and filter / index scan -> seq scan
  • From: Tom Lane
• Re: union all and filter / index scan -> seq scan
  • From: Vitalii Tymchyshyn
• union all and filter / index scan -> seq scan
  • From: Florian Lohoff
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: David G. Johnston
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: er.tejaspatel88@xxxxxxxxx
• How to clean/truncate / VACUUM FULL pg_largeobject without (much) downtime?
  • From: Muthusamy, Sivaraman
• Re: optimization join on random value
  • From: Heikki Linnakangas
• optimization join on random value
  • From: Anton Bushmelev
• Re: Index Scan Backward Slow
  • From: Robert Klemme
• Re: Index Scan Backward Slow
  • From: David Osborne
• Re: Index Scan Backward Slow
  • From: Evgeniy Shishkin
• Index Scan Backward Slow
  • From: David Osborne
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Andrew Dunstan
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: ktm@xxxxxxxx
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Joshua D. Drake
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Andres Freund
• Re: PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Andres Freund
• PostgreSQL disk fragmentation causes performance problems on Windows
  • From: Jan Gunnar Dyrset
• Re: Query plan with missing timespans
  • From: Kyotaro HORIGUCHI
• Re: Postgresql Host Swapping Hard With Abundant Free Memory
  • From: Jim Nasby
• Postgresql Host Swapping Hard With Abundant Free Memory
  • From: Christian Gough
• Re: Query plan with missing timespans
  • From: Jason Petersen
• Re: Query plan with missing timespans
  • From: Andomar
• Re: Query plan with missing timespans
  • From: Kevin Grittner
• Query plan with missing timespans
  • From: Andomar
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Jim Nasby
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Gavin Flower
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Tom Lane
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Yves Dorfsman
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Tom Lane
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Tomas Vondra
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Adam Tauno Williams
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Jon Dufresne
• Re: extract(year from date) doesn't use index but maybe could?
  • From: Tomas Vondra
• extract(year from date) doesn't use index but maybe could?
  • From: Jon Dufresne
• Performance of vacuumlo
  • From: Andreas Joseph Krogh
• Re: unlogged tables
  • From: Jim Nasby
• Re: Some performance testing?
  • From: Josh Berkus
• Re: unlogged tables
  • From: Jeff Janes
• Re: unlogged tables
  • From: Jeff Janes
• Re: unlogged tables
  • From: dgabriel
• Re: unlogged tables
  • From: Yves Dorfsman
• Re: unlogged tables
  • From: David G. Johnston
• Re: unlogged tables
  • From: Jim Nasby
• Re: unlogged tables
  • From: David G. Johnston
• Re: unlogged tables
  • From: Jeff Janes
• Re: unlogged tables
  • From: Jim Nasby
• Re: unlogged tables
  • From: Alvaro Herrera
• Re: unlogged tables
  • From: Jim Nasby
• Re: unlogged tables
  • From: David G. Johnston
• Re: unlogged tables
  • From: Matheus de Oliveira
• Re: unlogged tables
  • From: Yves Dorfsman
• Re: unlogged tables
  • From: dgabriel
• Re: unlogged tables
  • From: Matheus de Oliveira
• Re: unlogged tables
  • From: dgabriel
• Re: Some performance testing?
  • From: Graeme B. Bell
• Re: Some performance testing?
  • From: Michael Nolan
• Cannot get query to use btree-gin index when ORDER BY
  • From: Andreas Joseph Krogh
• Re: Some performance testing?
  • From: Wes Vaske (wvaske)
• Re: Some performance testing?
  • From: Scott Marlowe
• NVMe or AHCI PCI-express? A comment for people benchmarking...
  • From: Graeme B. Bell
• Re: Some performance testing?
  • From: Graeme B. Bell
• Re: Some performance testing?
  • From: Przemysław Deć
• Re: Some performance testing?
  • From: Graeme B. Bell
• Re: Some performance testing?
  • From: Przemysław Deć
• Re: Some performance testing?
  • From: Graeme B. Bell
• Re: Some performance testing?
  • From: Michael Nolan
• Re: Some performance testing?
  • From: Mel Llaguno
• Re: Some performance testing?
  • From: Josh Berkus
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
  • From: Qingqing Zhou
• Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
  • From: Jim Nasby
• Re: views much slower in 9.3 than 8.4
  • From: Jim Nasby
• Re: Some performance testing?
  • From: Mel Llaguno
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Some performance testing?
  • From: Josh Berkus
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Some performance testing?
  • From: Mel Llaguno
• Re: Some performance testing?
  • From: Josh Berkus
• Re: Some performance testing?
  • From: Mel Llaguno
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Josh Krupka
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Josh Krupka
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: didier
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Aidan Van Dyk
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Aidan Van Dyk
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: didier
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Mkrtchyan, Tigran
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Poor performing query re-write using tsrange index
  • From: Burgess, Freddie
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Gerardo Herzig
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Jeff Janes
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Wei Shan
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Aidan Van Dyk
• Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Ilya Kosmodemiansky
• Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL
  • From: Pietro Pugni
• Re: Some performance testing?
  • From: Przemysław Deć
• Re: Some performance testing?
  • From: Mel Llaguno
• Some performance testing?
  • From: Josh Berkus
• Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
  • From: David G. Johnston
• Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
  • From: Kevin Viraud
• Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
  • From: Tom Lane
• Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
  • From: Pavel Stehule
• Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
  • From: Kevin Viraud
• Re: Weird CASE WHEN behaviour causing query to be suddenly very slow
  • From: Pavel Stehule
• Weird CASE WHEN behaviour causing query to be suddenly very slow
  • From: Kevin Viraud
• Re: views much slower in 9.3 than 8.4
  • From: Tom Lane
• Re: views much slower in 9.3 than 8.4
  • From: Kevin Grittner
• Re: views much slower in 9.3 than 8.4
  • From: Tom Lane
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Tomas Vondra
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Jeff Janes
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Tomas Vondra
• query faster with a foreign table
  • From: Dominique Vallée
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Feike Steenbergen
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Feike Steenbergen
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Jeff Janes
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Jeff Janes
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Feike Steenbergen
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Jeff Janes
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Tom Lane
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Feike Steenbergen
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Feike Steenbergen
• Re: Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Tomas Vondra
• Index only scan sometimes switches to sequential scan for small amount of rows
  • From: Feike Steenbergen
• Re: Query RE: Optimising UUID Lookups
  • From: Maxim Boguk
• Re: Query RE: Optimising UUID Lookups
  • From: Roland Dunn
• Re: Query RE: Optimising UUID Lookups
  • From: David Rowley
• Re: Query RE: Optimising UUID Lookups
  • From: Maxim Boguk
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Query RE: Optimising UUID Lookups
  • From: Roland Dunn
• Re: Query RE: Optimising UUID Lookups
  • From: Maxim Boguk
• Re: Performance issues
  • From: Josh Krupka
• Query RE: Optimising UUID Lookups
  • From: Roland Dunn
• Re: [GENERAL] [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary
  • From: Vladimir Borodin
• Re: views much slower in 9.3 than 8.4
  • From: Tom Lane
• Re: Very slow checkpoints
  • From: Joao Junior
• Re: Merge Join chooses very slow index scan
  • From: Jake Magner
• Re: [GENERAL] Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary
  • From: Sergey Shchukin
• Re: views much slower in 9.3 than 8.4
  • From: Carson, Leonard
• Re: Merge Join chooses very slow index scan
  • From: Jake Magner
• Re: Merge Join chooses very slow index scan
  • From: Tom Lane
• Re: Merge Join chooses very slow index scan
  • From: Tom Lane
• Re: Merge Join chooses very slow index scan
  • From: Jake Magner
• Re: Merge Join chooses very slow index scan
  • From: Pavel Stehule
• Merge Join chooses very slow index scan
  • From: Jake Magner
• Re: Very slow checkpoints
  • From: Steven Jones
• Re: Fwd: views much slower in 9.3 than 8.4
  • From: Tom Lane
• Fwd: views much slower in 9.3 than 8.4
  • From: Carson, Leonard
• Re: Hardware Configuration and other Stuff
  • From: Pavel Stehule
• Re: Hardware Configuration and other Stuff
  • From: Tomas Vondra
• Re: [ADMIN] Hardware Configuration and other Stuff
  • From: Joshua D. Drake
• Re: Performance issues
  • From: Tomas Vondra
• Hardware Configuration and other Stuff
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Vitalii Tymchyshyn
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Jerry Sievers
• Re: Performance issues
  • From: Felipe Santos
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: views much slower in 9.3 than 8.4
  • From: Kevin Grittner
• views much slower in 9.3 than 8.4
  • From: Carson, Leonard
• Re: Very slow checkpoints
  • From: didier
• Re: Very slow checkpoints
  • From: Ilya Kosmodemiansky
• Re: Very slow checkpoints
  • From: Steven Jones
• Re: Very slow checkpoints
  • From: Steven Jones
• Re: Very slow checkpoints
  • From: Ilya Kosmodemiansky
• Re: Very slow checkpoints
  • From: Ilya Kosmodemiansky
• Re: Very slow checkpoints
  • From: Steven Jones
• Re: Very slow checkpoints
  • From: Ilya Kosmodemiansky
• Re: Very slow checkpoints
  • From: Steven Jones
• Very slow checkpoints
  • From: Steven Jones
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Thomas Kellerer
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Thomas Kellerer
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Jim Nasby
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Gunnlaugur Thor Briem
• Re: Performance issues
  • From: Tomas Vondra
• Re: MusicBrainz postgres performance issues
  • From: Scott Marlowe
• Re: MusicBrainz postgres performance issues
  • From: Jim Nasby
• Re: Performance issues
  • From: Jim Nasby
• Re: Best VPS provider for running performant PostgreSQL database server
  • From: Jim Nasby
• Re: MusicBrainz postgres performance issues
  • From: Joao Junior
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Jim Nasby
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Jim Nasby
• Re: Bad cost estimate with FALSE filter condition
  • From: Josh Berkus
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Bad cost estimate with FALSE filter condition
  • From: Tom Lane
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Marc Mamin
• Re: MusicBrainz postgres performance issues
  • From: Josh Berkus
• Re: Bad cost estimate with FALSE filter condition
  • From: Josh Berkus
• Re: MusicBrainz postgres performance issues
  • From: Robert Kaye
• Re: MusicBrainz postgres performance issues
  • From: Andreas Kretschmer
• Re: MusicBrainz postgres performance issues
  • From: Thomas Kellerer
• Re: MusicBrainz postgres performance issues
  • From: Robert Kaye
• Re: Performance issues
  • From: Vivekanand Joshi
• Best VPS provider for running performant PostgreSQL database server
  • From: Some Developer
• Re: MusicBrainz postgres performance issues
  • From: Roxanne Reid-Bennett
• Re: MusicBrainz postgres performance issues
  • From: Gavin Flower
• Re: MusicBrainz postgres performance issues
  • From: michael@xxxxxxxxxxx
• Re: MusicBrainz postgres performance issues
  • From: Andres Freund
• Re: MusicBrainz postgres performance issues
  • From: Tomas Vondra
• Re: MusicBrainz postgres performance issues
  • From: michael@xxxxxxxxxxx
• Re: MusicBrainz postgres performance issues
  • From: Tomas Vondra
• Re: MusicBrainz postgres performance issues
  • From: Andres Freund
• Re: MusicBrainz postgres performance issues
  • From: Tomas Vondra
• Re: MusicBrainz postgres performance issues
  • From: michael@xxxxxxxxxxx
• Re: MusicBrainz postgres performance issues
  • From: Andres Freund
• Re: MusicBrainz postgres performance issues
  • From: Scott Marlowe
• Re: MusicBrainz postgres performance issues
  • From: Ilya Kosmodemiansky
• Re: MusicBrainz postgres performance issues
  • From: Andres Freund
• Re: MusicBrainz postgres performance issues
  • From: Ilya Kosmodemiansky
• Re: MusicBrainz postgres performance issues
  • From: Andres Freund
• Re: MusicBrainz postgres performance issues
  • From: Scott Marlowe
• Re: MusicBrainz postgres performance issues
  • From: Scott Marlowe
• Re: MusicBrainz postgres performance issues
  • From: Joshua D. Drake
• Re: MusicBrainz postgres performance issues
  • From: Joshua D. Drake
• Re: MusicBrainz postgres performance issues
  • From: Scott Marlowe
• Re: MusicBrainz postgres performance issues
  • From: Andres Freund
• Re: MusicBrainz postgres performance issues
  • From: Ilya Kosmodemiansky
• Re: MusicBrainz postgres performance issues
  • From: Tomas Vondra
• Re: MusicBrainz postgres performance issues
  • From: Ilya Kosmodemiansky
• Re: MusicBrainz postgres performance issues
  • From: Josh Krupka
• Re: MusicBrainz postgres performance issues
  • From: Andres Freund
• Re: MusicBrainz postgres performance issues
  • From: Rural Hunter
• Re: MusicBrainz postgres performance issues
  • From: Robert Kaye
• Re: MusicBrainz postgres performance issues
  • From: Robert Kaye
• Re: MusicBrainz postgres performance issues
  • From: Andreas Kretschmer
• Re: MusicBrainz postgres performance issues
  • From: Josh Krupka
• MusicBrainz postgres performance issues
  • From: Robert Kaye
• Re: Performance issues
  • From: Gavin Flower
• Re: Performance issues
  • From: Varadharajan Mukundan
• Re: Performance issues
  • From: Gavin Flower
• Re: Anyone have experience using PG on a NetApp All-Flash FAS8000?
  • From: Varadharajan Mukundan
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Scott Marlowe
• Re: Postgres inconsistent use of Index vs. Seq Scan
  • From: Tom Lane
• Re: Performance issues
  • From: Varadharajan Mukundan
• Postgres inconsistent use of Index vs. Seq Scan
  • From: Jim Carroll
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Tomas Vondra
• Re: Performance issues
  • From: Vivekanand Joshi
• Anyone have experience using PG on a NetApp All-Flash FAS8000?
  • From: Mel Llaguno
• Re: Performance issues
  • From: Varadharajan Mukundan
• Re: Performance issues
  • From: Vivekanand Joshi
• Re: Performance issues
  • From: Varadharajan Mukundan
• Performance issues
  • From: Vivekanand Joshi
• Re: How to get explain plan to prefer Hash Join
  • From: atxcanadian
• Re: How to get explain plan to prefer Hash Join
  • From: Jeff Janes
• Re: How to get explain plan to prefer Hash Join
  • From: atxcanadian
• Re: How to get explain plan to prefer Hash Join
  • From: Jeff Janes
• Re: How to get explain plan to prefer Hash Join
  • From: atxcanadian
• Re: How to get explain plan to prefer Hash Join
  • From: Pavel Stehule
• Re: How to get explain plan to prefer Hash Join
  • From: atxcanadian
• Re: How to get explain plan to prefer Hash Join
  • From: Jeff Janes
• Re: How to get explain plan to prefer Hash Join
  • From: Nicholson, Brad (Toronto, ON, CA)
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tomas Vondra
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Jeff Janes
• How to get explain plan to prefer Hash Join
  • From: atxcanadian
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tom Lane
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Gunnlaugur Thor Briem
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Jim Nasby
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: CREATE INDEX uses INDEX ?
  • From: Guillaume Lelarge
• Re: CREATE INDEX uses INDEX ?
  • From: Nicolas Paris
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tomas Vondra
• Re: CREATE INDEX uses INDEX ?
  • From: Guillaume Lelarge
• CREATE INDEX uses INDEX ?
  • From: Nicolas Paris
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Jeff Janes
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tom Lane
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Kevin Grittner
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tom Lane
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Jeff Janes
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tomas Vondra
• Re: slow server : s_lock and _bt_checkkeys on perf top
  • From: Soni M
• Re: slow server : s_lock and _bt_checkkeys on perf top
  • From: Merlin Moncure
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Jim Nasby
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Jim Nasby
• Re: slow server : s_lock and _bt_checkkeys on perf top
  • From: Jim Nasby
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tom Lane
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Tomas Vondra
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Marc Mamin
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Vladimir Sitnikov
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Gunnlaugur Thor Briem
• Re: Reverse Key Index
  • From: Sven R. Kunze
• Re: EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Marc Mamin
• slow server : s_lock and _bt_checkkeys on perf top
  • From: Soni M
• EXPLAIN (no ANALYZE) taking an hour for INSERT FROM SELECT
  • From: Gunnlaugur Thor Briem
• Re: pushing order by + limit to union subqueries
  • From: Tom Lane
• pushing order by + limit to union subqueries
  • From: Paolo Losi
• Bad cost estimate with FALSE filter condition
  • From: Josh Berkus
• Re: Reverse Key Index
  • From: Sven R. Kunze
• Re: Reverse Key Index
  • From: Thomas Kellerer
• Re: Reverse Key Index
  • From: Heikki Linnakangas
• Re: Reverse Key Index
  • From: Sven R. Kunze
• Re: Reverse Key Index
  • From: Thomas Kellerer
• Re: Reverse Key Index
  • From: Sven R. Kunze
• Re: Reverse Key Index
  • From: Josh Berkus
• Re: Regarding "Point-in-time Recovery" feature
  • From: luis . sa
• Re: Regarding "Point-in-time Recovery" feature
  • From: Mathis, Jason
• Regarding "Point-in-time Recovery" feature
  • From: Saurabh Gupta A
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Matheus de Oliveira
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Matheus de Oliveira
• PG 9.3 materialized view VS Views, indexes, shared memory
  • From: Nicolas Paris
• Re: Configuration tips for very large database
  • From: Nico Sabbi
• Re: Reverse Key Index
  • From: Sven R. Kunze
• Re: Reverse Key Index
  • From: Tom Lane
• Reverse Key Index
  • From: Sven R. Kunze
• Re: Configuration tips for very large database
  • From: Graeme B. Bell
• Re: Configuration tips for very large database
  • From: ktm@xxxxxxxx
• Re: Yet another abort-early plan disaster on 9.3
  • From: Michael Paquier