pgsql-performance  

Messages by Thread

• • Re: [PERFORM] PGBOUNCER ISSUE PLEASE HELP(Slowing down the site) k...@rice.edu
  • Re: [PERFORM] PGBOUNCER ISSUE PLEASE HELP(Slowing down the site) Sheena, Prabhjot
  • Re: [PERFORM] PGBOUNCER ISSUE PLEASE HELP(Slowing down the site) k...@rice.edu
  • Re: [PERFORM] PGBOUNCER ISSUE PLEASE HELP(Slowing down the site) Sheena, Prabhjot
  • Re: [PERFORM] PGBOUNCER ISSUE PLEASE HELP(Slowing down the site) Jerry Sievers
  • Re: [PERFORM] PGBOUNCER ISSUE PLEASE HELP(Slowing down the site) Sheena, Prabhjot
  • Re: [PERFORM] PGBOUNCER ISSUE PLEASE HELP(Slowing down the site) Igor Neyman
  • Re: [PERFORM] PGBOUNCER ISSUE PLEASE HELP(Slowing down the site) k...@rice.edu
  • Re: [PERFORM] PGBOUNCER ISSUE PLEASE HELP(Slowing down the site) Will Platnick
• [PERFORM] Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux? Kaijiang Chen
  • Re: [PERFORM] Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux? Joshua D. Drake
  • Re: [PERFORM] Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux? Joe Conway
  • Re: [PERFORM] Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux? Kaijiang Chen
  • Re: [PERFORM] Do work_mem and shared buffers have 1g or 2g limit on 64 bit linux? Tomas Vondra
• [PERFORM] Are there tuning parameters that don't take effect immediately? Michael Nolan
  • Re: [PERFORM] Are there tuning parameters that don't take effect immediately? David G. Johnston
  • Re: [PERFORM] Are there tuning parameters that don't take effect immediately? Michael Nolan
  • Re: [PERFORM] Are there tuning parameters that don't take effect immediately? Joshua D. Drake
• [PERFORM] pg bouncer issue what does sv_used column means Sheena, Prabhjot
  • Re: [PERFORM] pg bouncer issue what does sv_used column means Xenofon Papadopoulos
  • Re: [PERFORM] pg bouncer issue what does sv_used column means Sheena, Prabhjot
  • Re: [PERFORM] pg bouncer issue what does sv_used column means Andrew Dunstan
  • Re: [PERFORM] pg bouncer issue what does sv_used column means k...@rice.edu
• [PERFORM] Slow query: Postgres chooses nested loop over hash join, whery by hash join is much faster, wrong number of rows estimated Sasa Vilic
  • Re: [PERFORM] Slow query: Postgres chooses nested loop over hash join, whery by hash join is much faster, wrong number of rows estimated Merlin Moncure
• [PERFORM] Row estimates off by two orders of magnitude with hstore Patrick Krecker
  • Re: [PERFORM] Row estimates off by two orders of magnitude with hstore Merlin Moncure
  • Re: [PERFORM] Row estimates off by two orders of magnitude with hstore Josh Berkus
  • Re: [PERFORM] Row estimates off by two orders of magnitude with hstore Merlin Moncure
  • Re: [PERFORM] Row estimates off by two orders of magnitude with hstore Patrick Krecker
  • Re: [PERFORM] Row estimates off by two orders of magnitude with hstore Merlin Moncure
  • Re: [PERFORM] Row estimates off by two orders of magnitude with hstore Patrick Krecker
  • Re: [PERFORM] Row estimates off by two orders of magnitude with hstore Merlin Moncure
• [PERFORM] Slow query - lots of temporary files. Johann Spies
  • Re: [PERFORM] Slow query - lots of temporary files. Claudio Freire
  • Re: [PERFORM] Slow query - lots of temporary files. Johann Spies
  • Re: [PERFORM] Slow query - lots of temporary files. Tomas Vondra
  • Re: [PERFORM] Slow query - lots of temporary files. Johann Spies
• [PERFORM] Query running slow for only one specific id. (Postgres 9.3) version Sheena, Prabhjot
  • [PERFORM] Re: Query running slow for only one specific id. (Postgres 9.3) version Igor Neyman
  • [PERFORM] Re: Query running slow for only one specific id. (Postgres 9.3) version Sheena, Prabhjot
  • [PERFORM] Re: Query running slow for only one specific id. (Postgres 9.3) version Igor Neyman
  • [PERFORM] Re: [GENERAL] Re: Query running slow for only one specific id. (Postgres 9.3) version Steve Crawford
  • Re: [PERFORM] Re: [GENERAL] Re: Query running slow for only one specific id. (Postgres 9.3) version Steve Crawford
  • Re: [PERFORM] Query running slow for only one specific id. (Postgres 9.3) version Steve Crawford
  • Re: [PERFORM] Query running slow for only one specific id. (Postgres 9.3) version Matheus de Oliveira
• [PERFORM] Need more IOPS? This should get you drooling... (5xnvme drives) Graeme B. Bell
  • Re: [PERFORM] Need more IOPS? This should get you drooling... (5xnvme drives) Graeme B. Bell
  • Re: [PERFORM] Need more IOPS? This should get you drooling... (5xnvme drives) Dorian Hoxha
  • Re: [PERFORM] Need more IOPS? This should get you drooling... (5xnvme drives) Graeme B. Bell
• [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) ben.play
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) David G. Johnston
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) amulsul
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) chiru r
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Tomas Vondra
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) ben.play
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Tomas Vondra
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Scott Marlowe
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Tomas Vondra
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Scott Marlowe
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Claudio Freire
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Tomas Vondra
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Joshua D. Drake
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Yves Dorfsman
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Tomas Vondra
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Scott Marlowe
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Scott Marlowe
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Mark Kirkwood
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Tomas Vondra
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Claudio Freire
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) ben.play
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Claudio Freire
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) ben.play
  • Re: [PERFORM] How to reduce writing on disk ? (90 gb on pgsql_tmp) Claudio Freire
• Re: [PERFORM] Postgres is using 100% CPU Graeme B. Bell
  • Re: [PERFORM] Postgres is using 100% CPU Graeme B. Bell
  • Re: [PERFORM] Postgres is using 100% CPU Ashik S L
• [PERFORM] Connection time when using SSL Marco Di Cesare
  • Re: [PERFORM] Connection time when using SSL Tomas Vondra
• [PERFORM] Slow hash join performance with many batches Alex Adriaanse
  • Re: [PERFORM] Slow hash join performance with many batches Tom Lane
• [PERFORM] Postmaster eating up all my cpu birimblongas
  • Re: [PERFORM] Postmaster eating up all my cpu Tomas Vondra
• [PERFORM] Fwd: Postgres is using 100% CPU Ashik S L
  • [PERFORM] Postgres is using 100% CPU Ashik S L
  • Re: [PERFORM] Postgres is using 100% CPU Yves Dorfsman
  • Re: [PERFORM] Postgres is using 100% CPU Tomas Vondra
  • Re: [PERFORM] Postgres is using 100% CPU Ashik S L
  • Re: [PERFORM] Postgres is using 100% CPU Tomas Vondra
  • Re: [PERFORM] Postgres is using 100% CPU Jean-David Beyer
  • Re: [PERFORM] Postgres is using 100% CPU Yves Dorfsman
  • Re: [PERFORM] Postgres is using 100% CPU Ashik S L
  • Re: [PERFORM] Postgres is using 100% CPU Merlin Moncure
  • Re: [PERFORM] Postgres is using 100% CPU Scott Marlowe
• [PERFORM] Different plan for very similar queries Peter J. Holzer
  • Re: [PERFORM] Different plan for very similar queries Peter J. Holzer
  • Re: [PERFORM] Different plan for very similar queries Tomas Vondra
  • Re: [PERFORM] Different plan for very similar queries Tom Lane
  • Re: [PERFORM] Different plan for very similar queries Peter J. Holzer
  • Re: [PERFORM] Different plan for very similar queries Tom Lane
  • Re: [PERFORM] Different plan for very similar queries Tomas Vondra
  • Re: [PERFORM] Different plan for very similar queries Tom Lane
  • Re: [PERFORM] Different plan for very similar queries Tomas Vondra
  • Re: [PERFORM] Different plan for very similar queries Peter J. Holzer
• [PERFORM] Partitioning and performance Ravi Krishna
  • Re: [PERFORM] Partitioning and performance Ravi Krishna
  • Re: [PERFORM] Partitioning and performance Jim Nasby
• [PERFORM] Fastest Backup & Restore for perf testing Wes Vaske (wvaske)
  • Re: [PERFORM] Fastest Backup & Restore for perf testing Andrew Dunstan
  • Re: [PERFORM] Fastest Backup & Restore for perf testing Steve Atkins
  • Re: [PERFORM] Fastest Backup & Restore for perf testing Jim Nasby
• [PERFORM] ERROR: missing chunk number 0 for toast value 1821556134 in pg_toast_17881 Tory M Blue
  • Re: [PERFORM] ERROR: missing chunk number 0 for toast value 1821556134 in pg_toast_17881 Josh Berkus
• [PERFORM] MAX() and multi-column index on a partitioned table? Dave Johansen
  • Re: [PERFORM] MAX() and multi-column index on a partitioned table? Tom Lane
  • Re: [PERFORM] MAX() and multi-column index on a partitioned table? Dave Johansen
  • Re: [PERFORM] MAX() and multi-column index on a partitioned table? Tom Lane
• [PERFORM] union all and filter / index scan -> seq scan Florian Lohoff
  • Re: [PERFORM] union all and filter / index scan -> seq scan Vitalii Tymchyshyn
  • Re: [PERFORM] union all and filter / index scan -> seq scan Tom Lane
• Re: [PERFORM] Fastest way / best practice to calculate "next birthdays" er.tejaspate...@gmail.com
  • Re: [PERFORM] Fastest way / best practice to calculate "next birthdays" David G. Johnston
  • Re: [PERFORM] Fastest way / best practice to calculate "next birthdays" Bosco Rama
  • Re: [PERFORM] Fastest way / best practice to calculate "next birthdays" David G. Johnston
  • Re: [PERFORM] Fastest way / best practice to calculate "next birthdays" Jim Nasby
  • Re: [PERFORM] Fastest way / best practice to calculate "next birthdays" Kevin Grittner
• [PERFORM] How to clean/truncate / VACUUM FULL pg_largeobject without (much) downtime? Muthusamy, Sivaraman
  • Re: [PERFORM] How to clean/truncate / VACUUM FULL pg_largeobject without (much) downtime? Jim Nasby
• [PERFORM] optimization join on random value Anton Bushmelev
  • Re: [PERFORM] optimization join on random value Heikki Linnakangas
• [PERFORM] Index Scan Backward Slow David Osborne
  • Re: [PERFORM] Index Scan Backward Slow Evgeniy Shishkin
  • Re: [PERFORM] Index Scan Backward Slow David Osborne
  • Re: [PERFORM] Index Scan Backward Slow Robert Klemme
• [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows Jan Gunnar Dyrset
  • Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows Andres Freund
  • Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows Andres Freund
  • Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows Joshua D. Drake
  • Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows k...@rice.edu
  • Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows Andrew Dunstan
  • Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows Josh Berkus
  • Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows Andres Freund
  • Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows Vitalii Tymchyshyn
  • Re: [PERFORM] PostgreSQL disk fragmentation causes performance problems on Windows Josh Berkus
• [PERFORM] Postgresql Host Swapping Hard With Abundant Free Memory Christian Gough
  • Re: [PERFORM] Postgresql Host Swapping Hard With Abundant Free Memory Jim Nasby
• [PERFORM] Query plan with missing timespans Andomar
  • Re: [PERFORM] Query plan with missing timespans Kevin Grittner
  • Re: [PERFORM] Query plan with missing timespans Andomar
  • Re: [PERFORM] Query plan with missing timespans Jason Petersen
  • Re: [PERFORM] Query plan with missing timespans Kyotaro HORIGUCHI
• [PERFORM] extract(year from date) doesn't use index but maybe could? Jon Dufresne
  • Re: [PERFORM] extract(year from date) doesn't use index but maybe could? Tomas Vondra
  • Re: [PERFORM] extract(year from date) doesn't use index but maybe could? Jon Dufresne
  • Re: [PERFORM] extract(year from date) doesn't use index but maybe could? Adam Tauno Williams
  • Re: [PERFORM] extract(year from date) doesn't use index but maybe could? Tomas Vondra
  • Re: [PERFORM] extract(year from date) doesn't use index but maybe could? Tom Lane
  • Re: [PERFORM] extract(year from date) doesn't use index but maybe could? Yves Dorfsman
  • Re: [PERFORM] extract(year from date) doesn't use index but maybe could? Tom Lane
  • Re: [PERFORM] extract(year from date) doesn't use index but maybe could? Gavin Flower
  • Re: [PERFORM] extract(year from date) doesn't use index but maybe could? Jim Nasby
• [PERFORM] Performance of vacuumlo Andreas Joseph Krogh
• Re: [PERFORM] unlogged tables dgabriel
  • Re: [PERFORM] unlogged tables Matheus de Oliveira
  • Re: [PERFORM] unlogged tables dgabriel
  • Re: [PERFORM] unlogged tables Yves Dorfsman
  • Re: [PERFORM] unlogged tables Matheus de Oliveira
  • Re: [PERFORM] unlogged tables David G. Johnston
  • Re: [PERFORM] unlogged tables Jim Nasby
  • Re: [PERFORM] unlogged tables Alvaro Herrera
  • Re: [PERFORM] unlogged tables Jim Nasby
  • Re: [PERFORM] unlogged tables Jeff Janes
  • Re: [PERFORM] unlogged tables David G. Johnston
  • Re: [PERFORM] unlogged tables Jim Nasby
  • Re: [PERFORM] unlogged tables David G. Johnston
  • Re: [PERFORM] unlogged tables Jeff Janes
  • Re: [PERFORM] unlogged tables Yves Dorfsman
  • Re: [PERFORM] unlogged tables Jeff Janes
  • Re: [PERFORM] unlogged tables dgabriel
  • Re: [PERFORM] unlogged tables Jim Nasby
  • [PERFORM] Unlogged tables l...@laurent-hasson.com
  • Re: [PERFORM] Unlogged tables Michael Paquier
  • Re: [PERFORM] Unlogged tables David G. Johnston
  • Re: [PERFORM] Unlogged tables Stephen Frost
  • Re: [PERFORM] Unlogged tables Jeff Janes
  • Re: [PERFORM] Unlogged tables George Neuner
  • Re: [PERFORM] Unlogged tables l...@laurent-hasson.com
  • Re: [PERFORM] Unlogged tables George Neuner
  • Re: [PERFORM] Unlogged tables l...@laurent-hasson.com
  • Re: [PERFORM] Unlogged tables George Neuner
  • Re: [PERFORM] Unlogged tables George Neuner
• [PERFORM] NVMe or AHCI PCI-express? A comment for people benchmarking... Graeme B. Bell
• [PERFORM] Poor performing query re-write using tsrange index Burgess, Freddie
• [PERFORM] Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL Pietro Pugni
  • Re: [PERFORM] Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL Ilya Kosmodemiansky
  • Re: [PERFORM] Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL Pietro Pugni
  • Re: [PERFORM] Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL Mkrtchyan, Tigran
  • Re: [PERFORM] Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL Pietro Pugni
  • Re: [PERFORM] Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL Aidan Van Dyk
  • Re: [PERFORM] Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL Wei Shan

• Earlier messages
• Later messages