pgsql-performance  

Messages by Thread

• sizing / capacity planning tipps related to expected request or transactions per second Dirk Krautschick
  • Re: sizing / capacity planning tipps related to expected request or transactions per second MichaelDBA
  • Re: sizing / capacity planning tipps related to expected request or transactions per second Pavel Stehule
• CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Jim Jarvie
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Michael Lewis
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Jim Jarvie
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Henrique Montenegro
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Michael Lewis
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Michael Lewis
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Jim Jarvie
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Michael Lewis
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Jim Jarvie
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Michael Lewis
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Jim Jarvie
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Michael Lewis
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED David Rowley
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Raj
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Jim Jarvie
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED David Rowley
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Alvaro Herrera
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Jeff Janes
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Laurenz Albe
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Thomas Munro
  • Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED Jim Jarvie
• Replication lag due to lagging restart_lsn Satyam Shekhar
  • Re: Replication lag due to lagging restart_lsn Kyotaro Horiguchi
  • Re: Replication lag due to lagging restart_lsn Kiran Singh
  • Re: Replication lag due to lagging restart_lsn milist ujang
  • Re: Replication lag due to lagging restart_lsn milist ujang
• Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query Ken Tanzer
  • Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query Justin Pryzby
  • Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query Ken Tanzer
  • Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query Justin Pryzby
  • Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query Jeff Janes
• Hstore index for full text search Burhan Akbulut
  • Re: Hstore index for full text search Michael Lewis
  • Re: Hstore index for full text search Tom Lane
  • Re: Hstore index for full text search Michael Lewis
  • Re: Hstore index for full text search Tom Lane
• Problems with Multixacts LWLocks Czarek
• Too few rows expected by Planner on partitioned tables Julian Wolf
  • Re: Too few rows expected by Planner on partitioned tables Justin Pryzby
  • Re: Too few rows expected by Planner on partitioned tables Julian Wolf
  • Re: Too few rows expected by Planner on partitioned tables Justin Pryzby
  • Re: Too few rows expected by Planner on partitioned tables Justin Pryzby
  • Re: Too few rows expected by Planner on partitioned tables Julian Wolf
  • Re: Too few rows expected by Planner on partitioned tables Julian Wolf
  • Re: Too few rows expected by Planner on partitioned tables Michael Lewis
• Re: Same query taking less time in low configuration machine Justin Pryzby
  • Re: Same query taking less time in low configuration machine Vishwa Kalyankar
  • Re: Same query taking less time in low configuration machine Justin Pryzby
  • Re: Same query taking less time in low configuration machine Vishwa Kalyankar
• Sudden insert performance degradation Henrique Montenegro
  • Re: Sudden insert performance degradation Sebastian Dressler
  • Re: Sudden insert performance degradation Henrique Montenegro
  • Re: Sudden insert performance degradation Sebastian Dressler
  • Re: Sudden insert performance degradation Henrique Montenegro
  • Re: Sudden insert performance degradation Michael Lewis
  • Re: Sudden insert performance degradation Henrique Montenegro
  • Re: Sudden insert performance degradation Jeff Janes
  • Re: Sudden insert performance degradation Henrique Montenegro
  • Re: Sudden insert performance degradation Henrique Montenegro
  • Re: Sudden insert performance degradation Sebastian Dressler
  • Re: Sudden insert performance degradation Henrique Montenegro
  • Re: Sudden insert performance degradation Henrique Montenegro
  • Re: Sudden insert performance degradation Justin Pryzby
• Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"? Gunther Schadow
  • Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"? Jim Jarvie
  • Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"? Kamil Dziedzic
  • Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"? Michael Lewis
  • Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"? Kamil Dziedzic
• Recommended value for pg_test_fsync Nikhil Shetty
  • Re: Recommended value for pg_test_fsync Bruce Momjian
  • Re: Recommended value for pg_test_fsync Nikhil Shetty
  • Re: Recommended value for pg_test_fsync Bruce Momjian
  • Re: Recommended value for pg_test_fsync Nikhil Shetty
  • Re: Recommended value for pg_test_fsync Jeff Janes
  • Re: Recommended value for pg_test_fsync Jeff Janes
  • Re: Recommended value for pg_test_fsync Nikhil Shetty
  • Re: Recommended value for pg_test_fsync Nikhil Shetty
  • Re: Recommended value for pg_test_fsync Haroldo Kerry
  • Re: Recommended value for pg_test_fsync Nikhil Shetty
  • Re: Recommended value for pg_test_fsync Nikhil Shetty
  • Re: Recommended value for pg_test_fsync Bruce Momjian
• PostgreSQL 12.3 slow index scan chosen Kenneth Marshall
  • Re: PostgreSQL 12.3 slow index scan chosen Tom Lane
  • Re: PostgreSQL 12.3 slow index scan chosen Kenneth Marshall
  • Re: PostgreSQL 12.3 slow index scan chosen Tom Lane
  • Re: PostgreSQL 12.3 slow index scan chosen Kenneth Marshall
  • Re: PostgreSQL 12.3 slow index scan chosen Tom Lane
  • Re: PostgreSQL 12.3 slow index scan chosen Kenneth Marshall
  • Re: PostgreSQL 12.3 slow index scan chosen Tom Lane
  • Re: PostgreSQL 12.3 slow index scan chosen Tom Lane
  • Re: PostgreSQL 12.3 slow index scan chosen Tom Lane
  • Re: PostgreSQL 12.3 slow index scan chosen Kenneth Marshall
  • Re: PostgreSQL 12.3 slow index scan chosen Alvaro Herrera
  • Re: PostgreSQL 12.3 slow index scan chosen Kenneth Marshall
  • Re: PostgreSQL 12.3 slow index scan chosen Tom Lane
  • Re: PostgreSQL 12.3 slow index scan chosen Kenneth Marshall
• Unclamped row estimates whith OR-ed subplans Benjamin Coutu
  • Re: Unclamped row estimates whith OR-ed subplans Laurenz Albe
  • Re: Unclamped row estimates whith OR-ed subplans David G. Johnston
  • Re: Unclamped row estimates whith OR-ed subplans Tom Lane
  • Re: Unclamped row estimates whith OR-ed subplans Benjamin Coutu
  • Re: Unclamped row estimates whith OR-ed subplans Tom Lane
  • Re: Unclamped row estimates whith OR-ed subplans Michael Lewis
  • Re: Unclamped row estimates whith OR-ed subplans Benjamin Coutu
• simple query running for ever Nagaraj Raj
  • Re: simple query running for ever Michael Lewis
  • Re: simple query running for ever Nagaraj Raj
  • Re: simple query running for ever Nagaraj Raj
  • Re: simple query running for ever Justin Pryzby
  • Re: simple query running for ever Nagaraj Raj
  • Re: simple query running for ever Justin Pryzby
  • Re: simple query running for ever Andreas Joseph Krogh
  • Re: simple query running for ever Justin Pryzby
  • Re: simple query running for ever Laurenz Albe
• Performance issue Nagaraj Raj
  • Re: Performance issue David Rowley
  • Re: Performance issue Justin Pryzby
• view reading information_schema is slow in PostgreSQL 12 regrog
  • Re: view reading information_schema is slow in PostgreSQL 12 Imre Samu
  • Re: view reading information_schema is slow in PostgreSQL 12 Tom Lane
  • Re: view reading information_schema is slow in PostgreSQL 12 David Rowley
  • Re: view reading information_schema is slow in PostgreSQL 12 Tom Lane
  • Re: view reading information_schema is slow in PostgreSQL 12 David Rowley
  • Re: view reading information_schema is slow in PostgreSQL 12 David Rowley
  • Re: view reading information_schema is slow in PostgreSQL 12 Tom Lane
  • Re: view reading information_schema is slow in PostgreSQL 12 Justin Pryzby
  • Re: view reading information_schema is slow in PostgreSQL 12 Pavel Stehule
  • Re: view reading information_schema is slow in PostgreSQL 12 Pavel Stehule
  • Re: view reading information_schema is slow in PostgreSQL 12 Pavel Stehule
  • Re: view reading information_schema is slow in PostgreSQL 12 David Rowley
  • Re: view reading information_schema is slow in PostgreSQL 12 Michael Lewis
  • Re: view reading information_schema is slow in PostgreSQL 12 regrog
• Windows slowness? Mikkel Lauritsen
  • Re: Windows slowness? mountain the blue
  • Re: Windows slowness? David Rowley
  • Re: Windows slowness? Mikkel Lauritsen
• Postgresql server gets stuck at low load Krzysztof Olszewski
  • Re: Postgresql server gets stuck at low load luis . roberto
  • Re: Postgresql server gets stuck at low load Krzysztof Olszewski
  • Re: Postgresql server gets stuck at low load Pavel Stehule
  • Re: Postgresql server gets stuck at low load Krzysztof Olszewski
  • Re: Postgresql server gets stuck at low load Justin Pryzby
  • Re: Postgresql server gets stuck at low load Avinash Kumar
  • Re: Postgresql server gets stuck at low load Krzysztof Olszewski
• increased max_parallel_workers_per_gather results in fewer workers? Philip Semanchuk
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Justin Pryzby
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Philip Semanchuk
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Justin Pryzby
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Sebastian Dressler
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Luis Carril
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Philip Semanchuk
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Sebastian Dressler
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Philip Semanchuk
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Sebastian Dressler
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Philip Semanchuk
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Tomas Vondra
  • Re: increased max_parallel_workers_per_gather results in fewer workers? Magnus Hagander
• When to use PARTITION BY HASH? Oleksandr Shulgin
  • Re: When to use PARTITION BY HASH? Justin Pryzby
  • Re: When to use PARTITION BY HASH? Oleksandr Shulgin
  • Re: When to use PARTITION BY HASH? Justin Pryzby
  • Re: When to use PARTITION BY HASH? MichaelDBA
  • Re: When to use PARTITION BY HASH? David G. Johnston
  • Re: When to use PARTITION BY HASH? Michel Pelletier
  • Re: When to use PARTITION BY HASH? Imre Samu
  • Re: When to use PARTITION BY HASH? MichaelDBA
  • Re: When to use PARTITION BY HASH? David Rowley
  • Re: When to use PARTITION BY HASH? michael...@sqlexec.com
• Configuration sugnathi hai
  • Re: Configuration Filip Rembiałkowski
• Performance tunning sugnathi hai
  • Re: Performance tunning Pavel Stehule
  • Re: Performance tunning Justin Pryzby
  • Re: Performance tunning Jeff Janes
• PostgreSQL performance problem moving from 9.6.17 to 12.3 Kenneth Marshall
  • Re: PostgreSQL performance problem moving from 9.6.17 to 12.3 Tom Lane
• Date vs Timestamp without timezone Partition Key Cedric Leong
  • Re: Date vs Timestamp without timezone Partition Key Tom Lane
  • Re: Date vs Timestamp without timezone Partition Key Cedric Leong
  • Re: Date vs Timestamp without timezone Partition Key David Rowley
  • Re: Date vs Timestamp without timezone Partition Key Cedric Leong
  • Re: Date vs Timestamp without timezone Partition Key David Rowley
  • Re: Date vs Timestamp without timezone Partition Key Cedric Leong
• Strategy for materialisation and centralisation of data Rory Campbell-Lange
• Request to help on Query improvement suggestion. devchef2020 d
  • Re: Request to help on Query improvement suggestion. Laurenz Albe
  • Re: Request to help on Query improvement suggestion. Marlene Villanueva
• Request to help on GIS Query improvement suggestion. postggen2020 s
  • Re: Request to help on GIS Query improvement suggestion. Michael Lewis
• Suggestion to improve query performance for GIS query. postgann2020 s
  • Re: Suggestion to improve query performance for GIS query. David G. Johnston
  • Re: Suggestion to improve query performance for GIS query. Mohammed Afsar
  • Re: Suggestion to improve query performance for GIS query. postgann2020 s
• Suggestion to improve query performance of data validation in proc. postgann2020 s
• Re: Suggestion on index creation for TEXT data field David G. Johnston
  • Re: Suggestion on index creation for TEXT data field postgann2020 s
• Re: Suggestion on table analyze postgann2020 s

• Later messages