pgsql-performance  

Messages by Thread

• • Re: Optimizing count(), but Explain estimates wildly off Chema
  • Re: Optimizing count(), but Explain estimates wildly off Greg Sabino Mullane
  • Re: Optimizing count(), but Explain estimates wildly off Chema
  • Re: Optimizing count(), but Explain estimates wildly off Greg Sabino Mullane
  • Re: Optimizing count(), but Explain estimates wildly off Chema
  • Re: Optimizing count(), but Explain estimates wildly off Alvaro Herrera
• sql statement not using all primary key values and poor performance James Pang
  • Re: sql statement not using all primary key values and poor performance James Pang
  • Re: sql statement not using all primary key values and poor performance Laurenz Albe
  • Re: sql statement not using all primary key values and poor performance James Pang
  • Re: sql statement not using all primary key values and poor performance Laurenz Albe
• "not related" code blocks for removal of dead rows when using vacuum and this kills the performance Lars Aksel Opsahl
  • Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance Laurenz Albe
  • Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance Lars Aksel Opsahl
  • Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance Lars Aksel Opsahl
  • Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance Laurenz Albe
  • Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance Lars Aksel Opsahl
  • Postgres index usage Dirschel, Steve
  • RE: Postgres index usage Dirschel, Steve
  • Re: Postgres index usage Tom Lane
  • Re: Postgres index usage Greg Sabino Mullane
• PostgreSQL doesn't use index-only scan if there is an expression in index Pavel Kulakov
  • Re: PostgreSQL doesn't use index-only scan if there is an expression in index Laurenz Albe
• Simple JOIN on heavy table not using expected index kimaidou
  • Re: Simple JOIN on heavy table not using expected index Burçin Yazıcı
  • Re: Simple JOIN on heavy table not using expected index kimaidou
  • Re: Simple JOIN on heavy table not using expected index Tom Lane
  • Re: Simple JOIN on heavy table not using expected index kimaidou
• Memory growth using many named prepared statements, in spite of using DISCARD ALL afterwards. Daniel Blanch Bataller
  • Re: Memory growth using many named prepared statements, in spite of using DISCARD ALL afterwards. Heikki Linnakangas
  • Re: Memory growth using many named prepared statements, in spite of using DISCARD ALL afterwards. Daniel Blanch Bataller
• huge SubtransSLRU and SubtransBuffer wait_event James Pang (chaolpan)
  • Re: huge SubtransSLRU and SubtransBuffer wait_event Laurenz Albe
  • RE: huge SubtransSLRU and SubtransBuffer wait_event James Pang (chaolpan)
  • RE: huge SubtransSLRU and SubtransBuffer wait_event James Pang (chaolpan)
  • Re: huge SubtransSLRU and SubtransBuffer wait_event Alvaro Herrera
  • Re: FW: huge SubtransSLRU and SubtransBuffer wait_event James Pang
  • Re: FW: huge SubtransSLRU and SubtransBuffer wait_event Alvaro Herrera
  • Re: FW: huge SubtransSLRU and SubtransBuffer wait_event James Pang
  • Re: huge SubtransSLRU and SubtransBuffer wait_event Lars Aksel Opsahl
  • Re: huge SubtransSLRU and SubtransBuffer wait_event Nikolay Samokhvalov
  • Re: huge SubtransSLRU and SubtransBuffer wait_event Laurenz Albe
  • RE: huge SubtransSLRU and SubtransBuffer wait_event James Pang (chaolpan)
  • Re: FW: huge SubtransSLRU and SubtransBuffer wait_event James Pang
• 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

• Earlier messages
• Later messages