pgsql-performance  

Messages by Thread

• Performance Mehmet COKCEVIK
  • Re: Performance Samed YILDIRIM
  • Weird performance differences between cloud vendors Dirk Krautschick
  • Re: Weird performance differences between cloud vendors Laurenz Albe
• Slow query in table where many rows were deleted. VACUUM FULL fixes it Pavlos Kallis
  • Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it Laurenz Albe
  • Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it Philip Semanchuk
  • Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it David Rowley
  • Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it Divya Sharma
• I don't understand that EXPLAIN PLAN timings Jean-Christophe Boggio
  • Re: I don't understand that EXPLAIN PLAN timings Jean-Christophe Boggio
  • Re: I don't understand that EXPLAIN PLAN timings David Rowley
  • Re: I don't understand that EXPLAIN PLAN timings Jean-Christophe Boggio
  • Re: I don't understand that EXPLAIN PLAN timings David Rowley
  • Re: I don't understand that EXPLAIN PLAN timings Tom Lane
  • Re: I don't understand that EXPLAIN PLAN timings Jean-Christophe Boggio
  • Re: I don't understand that EXPLAIN PLAN timings Jean-Christophe Boggio
  • Re: I don't understand that EXPLAIN PLAN timings David Rowley
• Why is a sort required for this query? (IS NULL predicate on leading key column) Jerry Brenner
  • Re: Why is a sort required for this query? (IS NULL predicate on leading key column) Jerry Brenner
  • Re: Why is a sort required for this query? (IS NULL predicate on leading key column) Tom Lane
• Selection not "pushed down into" CTE Clemens Eisserer
  • Re: Selection not "pushed down into" CTE Tom Lane
  • Re: Selection not "pushed down into" CTE Clemens Eisserer
• Questions about "Output" in EXPLAIN ANALYZE VERBOSE Jerry Brenner
  • Re: Questions about "Output" in EXPLAIN ANALYZE VERBOSE Jeff Janes
  • Re: Questions about "Output" in EXPLAIN ANALYZE VERBOSE Tom Lane
  • Re: Questions about "Output" in EXPLAIN ANALYZE VERBOSE Jerry Brenner
• Slow GroupAggregate and Sort Darwin Correa
  • Re: Slow GroupAggregate and Sort Jeff Janes
  • Re: Slow GroupAggregate and Sort Darwin Correa
  • Re: Slow GroupAggregate and Sort Jeff Janes
  • Re: Slow GroupAggregate and Sort Darwin Correa
• Need help with performance tuning pg12 on linux Wilson, Maria Louise (LARC-E301)[RSES]
  • Re: Need help with performance tuning pg12 on linux Frits Hoogland
  • Re: [EXTERNAL] Need help with performance tuning pg12 on linux Matheus de Oliveira
  • Re: [EXTERNAL] Need help with performance tuning pg12 on linux Wilson, Maria Louise (LARC-E301)[RSES]
  • Re: [EXTERNAL] Need help with performance tuning pg12 on linux Ranier Vilela
  • Re: [EXTERNAL] Need help with performance tuning pg12 on linux Wilson, Maria Louise (LARC-E301)[RSES]
  • Re: [EXTERNAL] Need help with performance tuning pg12 on linux Matheus de Oliveira
  • Re: [EXTERNAL] Need help with performance tuning pg12 on linux Matheus de Oliveira
• Parallel hints in PostgreSQL with consistent perfromance mohini mane
  • Re: Parallel hints in PostgreSQL with consistent perfromance Tomas Vondra
  • Re: Parallel hints in PostgreSQL with consistent perfromance Jeff Janes
  • Re: Parallel hints in PostgreSQL with consistent perfromance mohini mane
  • Re: Parallel hints in PostgreSQL with consistent perfromance Matheus de Oliveira
  • Re: Parallel hints in PostgreSQL with consistent perfromance David G. Johnston
  • Re: Parallel hints in PostgreSQL with consistent perfromance Jeff Janes
  • Re: Parallel hints in PostgreSQL with consistent perfromance mohini mane
  • Re: Parallel hints in PostgreSQL with consistent perfromance David G. Johnston
  • Re: Parallel hints in PostgreSQL with consistent perfromance mohini mane
  • Re: Parallel hints in PostgreSQL with consistent perfromance Jeff Janes
  • Re: Parallel hints in PostgreSQL with consistent perfromance mohini mane
• Which side of a Merge Join gets executed first? Do both sides always get executed? Jerry Brenner
  • Re: Which side of a Merge Join gets executed first? Do both sides always get executed? Frédéric Yhuel
  • Re: Which side of a Merge Join gets executed first? Do both sides always get executed? Frédéric Yhuel
  • Re: Which side of a Merge Join gets executed first? Do both sides always get executed? Jerry Brenner
  • Re: Which side of a Merge Join gets executed first? Do both sides always get executed? Frédéric Yhuel
• 2 json explain plans for the same query/plan - why does one have constants while the other has parameter markers? Jerry Brenner
  • Re: 2 json explain plans for the same query/plan - why does one have constants while the other has parameter markers? Tom Lane
  • Re: 2 json explain plans for the same query/plan - why does one have constants while the other has parameter markers? Jerry Brenner
  • Re: 2 json explain plans for the same query/plan - why does one have constants while the other has parameter markers? Jerry Brenner
• Question about semantics of $ variables in json explain plans in 13 Jerry Brenner
  • Re: Question about semantics of $ variables in json explain plans in 13 Tom Lane
• Include a timestamp in future versions of pg_stat_statements when when a query entered the cache? Jerry Brenner
  • Re: Include a timestamp in future versions of pg_stat_statements when when a query entered the cache? Julien Rouhaud
• Does Postgres have consistent identifiers (plan hash value) for explain plans? Jerry Brenner
  • Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? Tom Lane
  • Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? Michael Paquier
  • Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? Tom Lane
  • Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? Jerry Brenner
  • Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? Julien Rouhaud
• Strange "actual time" in simple CTE Jean-Christophe Boggio
  • Re: Strange "actual time" in simple CTE Jeff Janes
• Performance degradation with CTEs, switching from PG 11 to PG 15 Jean-Christophe Boggio
  • Re: Performance degradation with CTEs, switching from PG 11 to PG 15 John Naylor
  • Re: Performance degradation with CTEs, switching from PG 11 to PG 15 Jean-Christophe Boggio
  • Re: Performance degradation with CTEs, switching from PG 11 to PG 15 Andreas Kretschmer
  • Re: Performance degradation with CTEs, switching from PG 11 to PG 15 Jean-Christophe Boggio
  • Re: Performance degradation with CTEs, switching from PG 11 to PG 15 Tom Lane
• simple query running long time within a long transaction. James Pang (chaolpan)
  • Re: simple query running long time within a long transaction. Andreas Kretschmer
  • RE: simple query running long time within a long transaction. James Pang (chaolpan)
  • Re: simple query running long time within a long transaction. Frits Hoogland
• Awkward Join between generate_series and long table Lincoln Swaine-Moore
  • Re: Awkward Join between generate_series and long table David G. Johnston
  • Re: Awkward Join between generate_series and long table Lincoln Swaine-Moore
  • Re: Awkward Join between generate_series and long table Philip Semanchuk
  • Re: Awkward Join between generate_series and long table Lincoln Swaine-Moore
• GIN JSONB path index is not always used Tomasz Szymański
  • Re: GIN JSONB path index is not always used Laurenz Albe
  • Re: GIN JSONB path index is not always used Jeff Janes
  • Re: GIN JSONB path index is not always used Tomasz Szymański
  • Re: GIN JSONB path index is not always used Jeff Janes
• Underestimated number of output rows with an aggregate function Philippe BEAUDOIN
  • Re: Underestimated number of output rows with an aggregate function Tom Lane
  • Re: Underestimated number of output rows with an aggregate function Philippe BEAUDOIN
• Postgres 15 SELECT query doesn't use index under RLS Alexander Okulovich
  • Re: Postgres 15 SELECT query doesn't use index under RLS Tom Lane
  • Re: Postgres 15 SELECT query doesn't use index under RLS Alexander Okulovich
  • Re: Postgres 15 SELECT query doesn't use index under RLS Tom Lane
  • Re: Postgres 15 SELECT query doesn't use index under RLS Alexander Okulovich
  • Re: Postgres 15 SELECT query doesn't use index under RLS Tom Lane
  • 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

• Earlier messages
• Later messages