pgsql-performance  

Messages by Thread

• • Re: Partitioning update-heavy queue with hash partitions vs partial indexes Dorian Hoxha
• Function call very slow from JDBC/java but super fast from DBear An, Hongguo (CORP)
  • Re: Function call very slow from JDBC/java but super fast from DBear Dave Cramer
  • Re: Function call very slow from JDBC/java but super fast from DBear An, Hongguo (CORP)
  • Re: Function call very slow from JDBC/java but super fast from DBear David G. Johnston
• Plan weirdness. A sort produces more rows than the node beneath it Dane Foster
  • Re: Plan weirdness. A sort produces more rows than the node beneath it Jeff Janes
  • Re: Plan weirdness. A sort produces more rows than the node beneath it Dane Foster
  • Re: Plan weirdness. A sort produces more rows than the node beneath it Tom Lane
  • Re: Plan weirdness. A sort produces more rows than the node beneath it Dane Foster
  • Re: Plan weirdness. A sort produces more rows than the node beneath it Tom Lane
  • Re: Plan weirdness. A sort produces more rows than the node beneath it Dane Foster
• Table copy with SERIALIZABLE is incredibly slow peter plachta
  • Re: Table copy with SERIALIZABLE is incredibly slow Laurenz Albe
• Results of experiments with UUIDv7, UUIDv8 peter plachta
• TOAST Fields serialisation/deserialization performance Piyush Katariya
  • Re: TOAST Fields serialisation/deserialization performance Laurenz Albe
  • Re: TOAST Fields serialisation/deserialization performance Piyush Katariya
• Entire index scanned, but only when in SQL function? Philip Semanchuk
• Performance implications of 8K pread()s Dimitrios Apostolou
  • Re: Performance implications of 8K pread()s Thomas Munro
  • Re: Performance implications of 8K pread()s Thomas Munro
  • Re: Performance implications of 8K pread()s Dimitrios Apostolou
  • Re: Performance implications of 8K pread()s Thomas Munro
  • Re: Performance implications of 8K pread()s Dimitrios Apostolou
  • Re: Performance implications of 8K pread()s Andres Freund
  • Re: Performance implications of 8K pread()s Thomas Munro
  • Re: Performance implications of 8K pread()s Dimitrios Apostolou
  • Re: Performance implications of 8K pread()s Dimitrios Apostolou
• Why is query performance on RLS enabled Postgres worse? Akash Anand
  • Re: Why is query performance on RLS enabled Postgres worse? Akash Anand
• Fwd: Helping planner to chose sequential scan when it improves performance Patrick O'Toole
• Index on (fixed size) bytea value Les
  • Re: Index on (fixed size) bytea value David G. Johnston
  • Re: Index on (fixed size) bytea value Les
  • Re: Index on (fixed size) bytea value Laurenz Albe
  • Re: Index on (fixed size) bytea value Les
• Merge David and Goliath tables efficiently Nicolas Paris
  • Re: Merge David and Goliath tables efficiently Tomas Vondra
  • Re: Merge David and Goliath tables efficiently nicolas paris
  • Re: Merge David and Goliath tables efficiently Tomas Vondra
  • Re: Merge David and Goliath tables efficiently nicolas paris
  • Re: Merge David and Goliath tables efficiently Alvaro Herrera
  • Re: Merge David and Goliath tables efficiently Tomas Vondra
  • Re: Merge David and Goliath tables efficiently nicolas paris
  • Re: Merge David and Goliath tables efficiently Tomas Vondra
  • Re: Merge David and Goliath tables efficiently nicolas paris
  • Re: Merge David and Goliath tables efficiently Tomas Vondra
  • Re: Merge David and Goliath tables efficiently nicolas paris
  • Re: Merge David and Goliath tables efficiently Tomas Vondra
  • Re: Merge David and Goliath tables efficiently Tomas Vondra
  • Re: Merge David and Goliath tables efficiently nicolas paris
• extended statistics n-distinct on multiple columns not used when join two tables James Pang (chaolpan)
  • Re: extended statistics n-distinct on multiple columns not used when join two tables Pavel Stehule
• Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT benoit
  • Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT Peter Geoghegan
  • RE: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT benoit
  • Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT Chris Hoover
  • RE: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT benoit
  • Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT Chris Hoover
  • RE: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT msalais
  • Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT Benoit Tigeot
• Postgresql equal join on function with columns not use index James Pang (chaolpan)
  • Re: Postgresql equal join on function with columns not use index Tom Lane
  • RE: Postgresql equal join on function with columns not use index James Pang (chaolpan)
  • Re: Postgresql equal join on function with columns not use index Tom Lane
  • Re: Postgresql equal join on function with columns not use index Pavel Stehule
  • Re: Postgresql equal join on function with columns not use index Pavel Stehule
  • RE: Postgresql equal join on function with columns not use index James Pang (chaolpan)
  • Re: Postgresql equal join on function with columns not use index Pavel Stehule
• wrong rows estimation by hash join James Pang (chaolpan)
  • Re: wrong rows estimation by hash join Tomas Vondra
• Weird behavior of INSERT QUERY Satalabaha Postgres
  • Re: Weird behavior of INSERT QUERY Satalabaha Postgres
  • Re: Weird behavior of INSERT QUERY Julien Rouhaud
  • Re: Weird behavior of INSERT QUERY Satalabaha Postgres
  • Re: Weird behavior of INSERT QUERY Julien Rouhaud
  • Re: Weird behavior of INSERT QUERY Tom Lane
  • Re: Weird behavior of INSERT QUERY Satalabaha Postgres
  • Re: Weird behavior of INSERT QUERY Ranier Vilela
  • Re: Weird behavior of INSERT QUERY Satalabaha Postgres
  • Re: Weird behavior of INSERT QUERY Ranier Vilela
  • Re: Weird behavior of INSERT QUERY Satalabaha Postgres
• Understand time taken by individual SQL statements in a procedure Satalabaha Postgres
  • Re: Understand time taken by individual SQL statements in a procedure Julien Rouhaud
  • Re: Understand time taken by individual SQL statements in a procedure Satalabaha Postgres
• Re: thousands of CachedPlan entry per backend Laurenz Albe
  • Re: thousands of CachedPlan entry per backend Pavel Stehule
  • RE: thousands of CachedPlan entry per backend James Pang (chaolpan)
  • Re: thousands of CachedPlan entry per backend Laurenz Albe
  • RE: thousands of CachedPlan entry per backend James Pang (chaolpan)
  • Re: thousands of CachedPlan entry per backend Pavel Stehule
  • RE: thousands of CachedPlan entry per backend James Pang (chaolpan)
  • Re: thousands of CachedPlan entry per backend Jeff Janes
• How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server Sergio Rus
  • Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server Kenneth Marshall
  • Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server Sergio Rus
  • Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server Imre Samu
  • Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server Andres Freund
  • Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server Ranier Vilela
  • Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server Sergio Rus
• Unaccounted regression from postgresql 11 in later versions Bob Jolliffe
  • Re: Unaccounted regression from postgresql 11 in later versions Michael Christofides
  • Re: Unaccounted regression from postgresql 11 in later versions Bob Jolliffe
• PostgreSQL performance on ARM i.MX6 Druckenmueller, Marc
  • Re: PostgreSQL performance on ARM i.MX6 Daniele Varrazzo
  • Re: PostgreSQL performance on ARM i.MX6 Tom Lane
  • Re: PostgreSQL performance on ARM i.MX6 Richard Huxton
  • Re: PostgreSQL performance on ARM i.MX6 Ranier Vilela
• Connection drops on postgres 11.16 aditya desai
• Fsync IO issue ProfiVPS Support
  • Re: Fsync IO issue ProfiVPS Support
  • Re: Fsync IO issue Andres Freund
  • Re: Fsync IO issue ProfiVPS Support
  • Re: Fsync IO issue Thomas Munro
  • Re: Fsync IO issue Merlin Moncure
• Performance issues in query with multiple joins Παρασκευη Πασσαρη
  • Performance issues in query with multiple joins David G. Johnston
  • Re: Performance issues in query with multiple joins Tom Lane
  • Re: Performance issues in query with multiple joins Laurenz Albe
• How do Monitoring tools capture explain plan of a query kunwar singh
  • Re: How do Monitoring tools capture explain plan of a query kyle Hailey
  • Re: How do Monitoring tools capture explain plan of a query kunwar singh
• What is equivalent of v$sesstat and v$sql_plan in postgres? kunwar singh
  • Re: What is equivalent of v$sesstat and v$sql_plan in postgres? MichaelDBA
• High QPS, random index writes and vacuum peter plachta
  • Re: High QPS, random index writes and vacuum Peter Geoghegan
  • Re: High QPS, random index writes and vacuum Tom Lane
  • Re: High QPS, random index writes and vacuum peter plachta
  • Re: High QPS, random index writes and vacuum Thomas Munro
  • Re: High QPS, random index writes and vacuum Peter Geoghegan
  • Re: High QPS, random index writes and vacuum David Rowley
  • Re: High QPS, random index writes and vacuum peter plachta
• speeding up grafana sensor-data query on raspberry pi 3 Clemens Eisserer
  • Re: speeding up grafana sensor-data query on raspberry pi 3 Justin Pryzby
  • Re: speeding up grafana sensor-data query on raspberry pi 3 David Rowley
  • Re: speeding up grafana sensor-data query on raspberry pi 3 Clemens Eisserer
  • Re: speeding up grafana sensor-data query on raspberry pi 3 Clemens Eisserer
  • Re: speeding up grafana sensor-data query on raspberry pi 3 Andres Freund
  • Re: speeding up grafana sensor-data query on raspberry pi 3 Luiz Felipph
• Postgres Metrics André Rodrigues
  • Re: Postgres Metrics Joe Conway
  • Re: Postgres Metrics Jesper Pedersen
• Re: Replication lag due to lagging restart_lsn milist ujang
  • Re: Replication lag due to lagging restart_lsn milist ujang
• Is there any tool which will help me run and explain analyze about 150 queries? kunwar singh
  • Re: Is there any tool which will help me run and explain analyze about 150 queries? Achilleas Mantzios
  • Re: Is there any tool which will help me run and explain analyze about 150 queries? kyle Hailey
  • Re: Is there any tool which will help me run and explain analyze about 150 queries? kunwar singh
  • Re: Is there any tool which will help me run and explain analyze about 150 queries? Jerry Sievers
  • Re: Is there any tool which will help me run and explain analyze about 150 queries? kyle Hailey
  • Re: Is there any tool which will help me run and explain analyze about 150 queries? kunwar singh
  • Re: Is there any tool which will help me run and explain analyze about 150 queries? Michael Christofides
• Query unable to utilize index without typecast to fixed length character ahi
  • Re: Query unable to utilize index without typecast to fixed length character Tom Lane
  • Re: Query unable to utilize index without typecast to fixed length character ahi
  • RE: Query unable to utilize index without typecast to fixed length character msalais
• Why are commits consuming most of the database time? Tim Slechta
  • Re: Why are commits consuming most of the database time? Tom Lane
  • Re: Why are commits consuming most of the database time? Tim Slechta
• Explain plan shows fewer shared blocks when index+table compared to index alone? Amin Jaffer
  • Re:Explain plan shows fewer shared blocks when index+table compared to index alone? Sergei Kornilov
• multicolumn partitioning help James Robertson
  • Re: multicolumn partitioning help Justin Pryzby
  • Re: multicolumn partitioning help Laurenz Albe
  • Re: multicolumn partitioning help James Robertson
  • Re: multicolumn partitioning help Laurenz Albe
  • Re: multicolumn partitioning help David Rowley
  • Re: multicolumn partitioning help David Rowley
• Huge Tables André Rodrigues
  • Re: Huge Tables Rick Otten
  • Re: Huge Tables André Rodrigues
• Planner choosing nested loop in place of Hashjoin Praneel Devisetty
  • Re: Planner choosing nested loop in place of Hashjoin Samed YILDIRIM
  • Re: Planner choosing nested loop in place of Hashjoin Jeff Janes
• INSERT statement going in IPC Wait_event aditya desai
  • Re: INSERT statement going in IPC Wait_event Andrew Dunstan
  • Re: INSERT statement going in IPC Wait_event Samed YILDIRIM
• BRIN index worse than sequential scan for large search set Mickael van der Beek
  • Re: BRIN index worse than sequential scan for large search set Justin Pryzby
  • Re: BRIN index worse than sequential scan for large search set Mickael van der Beek
  • Re: BRIN index worse than sequential scan for large search set Justin Pryzby
  • Re: BRIN index worse than sequential scan for large search set Tomas Vondra
• Connection forcibly closed remote server error. aditya desai
  • Re: Connection forcibly closed remote server error. aditya desai
  • Re: Connection forcibly closed remote server error. Tom Lane
  • Re: Connection forcibly closed remote server error. Jeff Janes
  • Re: Connection forcibly closed remote server error. aditya desai
  • Re: Connection forcibly closed remote server error. Ranier Vilela
• Performance of UPDATE operation Mkrtchyan, Tigran
  • Re: Performance of UPDATE operation Laurenz Albe
  • Re: Performance of UPDATE operation Oluwatobi Ogunsola
  • Re: Performance of UPDATE operation Jeff Janes
• For loop execution times in PostgreSQL 12 vs 15 Adithya Kumaranchath
  • Re: For loop execution times in PostgreSQL 12 vs 15 Pavel Stehule
  • Re: For loop execution times in PostgreSQL 12 vs 15 Pavel Stehule
  • Re: For loop execution times in PostgreSQL 12 vs 15 Andres Freund
  • Re: For loop execution times in PostgreSQL 12 vs 15 Pavel Stehule
• max_wal_senders Rick Otten
  • Re: max_wal_senders Laurenz Albe

• Earlier messages
• Later messages