pgsql-performance  

Messages by Thread

• • Re: Postgres 15 SELECT query doesn't use index under RLS Alexander Okulovich
  • Postgres Locking Dirschel, Steve
  • Re: Postgres Locking Tom Lane
  • Performance down with JDBC 42 Abraham, Danny
  • Re: Performance down with JDBC 42 Laurenz Albe
  • RE: [EXTERNAL] Re: Performance down with JDBC 42 Abraham, Danny
  • Re: [EXTERNAL] Re: Performance down with JDBC 42 Andreas Kretschmer
  • Re: [EXTERNAL] Re: Performance down with JDBC 42 Frits Hoogland
  • Re: [EXTERNAL] Re: Performance down with JDBC 42 Jeff Janes
  • RE: [EXTERNAL] Re: Performance down with JDBC 42 Abraham, Danny
  • Re: [EXTERNAL] Re: Performance down with JDBC 42 David Rowley
  • Re: [EXTERNAL] Performance down with JDBC 42 Frits Hoogland
  • RE: [EXTERNAL] Performance down with JDBC 42 Abraham, Danny
  • Performance problems with Postgres JDBC 42.4.2 Jose Osinde
  • Re: Performance problems with Postgres JDBC 42.4.2 Dave Cramer
  • RE: Postgres Locking Smith, Travis
  • Re: Postgres 15 SELECT query doesn't use index under RLS Alexander Okulovich
  • Re: Postgres 15 SELECT query doesn't use index under RLS Tomek
  • Re: Postgres 15 SELECT query doesn't use index under RLS Alexander Okulovich
• Unexpected termination looping over table. Matt Gibbins
  • Re: Unexpected termination looping over table. Tom Lane
  • Re: Unexpected termination looping over table. Matt Gibbins
• Dirty reads on index scan, Koen De Groote
  • Re: Dirty reads on index scan, Laurenz Albe
  • Re: Dirty reads on index scan, Koen De Groote
  • Re: Dirty reads on index scan, Laurenz Albe
  • Re: Dirty reads on index scan, Frits Hoogland
  • Re: Dirty reads on index scan, Koen De Groote
  • Re: Dirty reads on index scan, Jeff Janes
• pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit Achilleas Mantzios - cloud
  • Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit Tom Lane
  • Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit Achilleas Mantzios
  • Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit Tom Lane
  • Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit Achilleas Mantzios
  • Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit Thomas Munro
  • Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit Achilleas Mantzios
• Multixact wraparound monitoring bruno da silva
  • Re: Multixact wraparound monitoring Wyatt Alt
  • Re: Multixact wraparound monitoring Alvaro Herrera
  • Re: Multixact wraparound monitoring bruno da silva
  • Re: Multixact wraparound monitoring Alvaro Herrera
• Planning time is time-consuming Mikhail Balayan
  • Re: Planning time is time-consuming Laurenz Albe
  • Re: Planning time is time-consuming Anupam b
  • Fwd: Planning time is time-consuming Mikhail Balayan
  • Re: Fwd: Planning time is time-consuming Laurenz Albe
  • Re: Planning time is time-consuming Frits Hoogland
  • Re: Planning time is time-consuming Andreas Kretschmer
  • Fwd: Planning time is time-consuming Mikhail Balayan
  • Re: Planning time is time-consuming David Rowley
  • Re: Planning time is time-consuming Tom Lane
  • Re: Planning time is time-consuming David Rowley
  • Re: Planning time is time-consuming Merlin Moncure
  • 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
• 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

• Earlier messages
• Later messages