pgsql-performance  

Messages by Thread

• • Re: Planning time is time-consuming Michał Kłeczek
  • Re: Planning time is time-consuming David Rowley
  • Re: Planning time is time-consuming Imre Samu
• query pg_stat_ssl hang 100%cpu James Pang (chaolpan)
  • query pg_stat_ssl hang 100%cpu James Pang (chaolpan)
• Join order optimization Christian Beikov
• Queries containing ORDER BY and LIMIT started to work slowly Rondat Flyag
  • Re: Queries containing ORDER BY and LIMIT started to work slowly Jeff Janes
  • Re: Queries containing ORDER BY and LIMIT started to work slowly Rondat Flyag
  • Re: Queries containing ORDER BY and LIMIT started to work slowly Jeff Janes
  • Re: Queries containing ORDER BY and LIMIT started to work slowly Rondat Flyag
  • Re: Queries containing ORDER BY and LIMIT started to work slowly David Rowley
  • Re: Queries containing ORDER BY and LIMIT started to work slowly Rondat Flyag
  • Re: Queries containing ORDER BY and LIMIT started to work slowly Jeff Janes
  • Re: Queries containing ORDER BY and LIMIT started to work slowly Rondat Flyag
  • Re: Queries containing ORDER BY and LIMIT started to work slowly Rick Otten
  • Re: Queries containing ORDER BY and LIMIT started to work slowly Rondat Flyag
• Range partitioning query performance with date_trunc (vs timescaledb) Philippe Pepiot
  • Re: Range partitioning query performance with date_trunc (vs timescaledb) David Rowley
  • Re: Range partitioning query performance with date_trunc (vs timescaledb) Philippe Pepiot
• Index bloat and REINDEX/VACUUM optimization for partial index jayaprabhakar k
  • Re: Index bloat and REINDEX/VACUUM optimization for partial index Peter Geoghegan
  • Re: Index bloat and REINDEX/VACUUM optimization for partial index jayaprabhakar k
  • Re: Index bloat and REINDEX/VACUUM optimization for partial index Jeff Janes
  • Re: Index bloat and REINDEX/VACUUM optimization for partial index jayaprabhakar k
  • Re: Index bloat and REINDEX/VACUUM optimization for partial index Jeff Janes
  • Re: Index bloat and REINDEX/VACUUM optimization for partial index Maxim Boguk
  • Re: Index bloat and REINDEX/VACUUM optimization for partial index jayaprabhakar k
  • Re: Index bloat and REINDEX/VACUUM optimization for partial index Maxim Boguk
  • Re: Index bloat and REINDEX/VACUUM optimization for partial index jayaprabhakar k
  • Re: Index bloat and REINDEX/VACUUM optimization for partial index Jeff Janes
• Slow query, possibly not using index Les
  • Re: Slow query, possibly not using index Tom Lane
  • Re: Slow query, possibly not using index Les
  • Re: Slow query, possibly not using index Wael Khobalatte
  • Re: Slow query, possibly not using index Tom Lane
  • Re: Slow query, possibly not using index Les
  • Re: Slow query, possibly not using index Les
  • Re: Slow query, possibly not using index Les
  • Re: Slow query, possibly not using index Pavel Stehule
  • Re: Slow query, possibly not using index David Rowley
  • Re: Slow query, possibly not using index Les
• Question regarding writes when locking rows Martin Querleu
• slow delete Les
  • Re: slow delete Tom Lane
  • Re: slow delete Les
  • Re: slow delete Jeff Janes
• Partitioning update-heavy queue with hash partitions vs partial indexes Dorian Hoxha
  • Re: Partitioning update-heavy queue with hash partitions vs partial indexes David Rowley
  • Re: Partitioning update-heavy queue with hash partitions vs partial indexes burcinyazici
  • 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
• 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

• Earlier messages
• Later messages