Discussion of PostgreSQL's performance issues. Please see Guide to reporting problems and Slow Query Questions for some tips on how to write your performance question.
Thread | Author | Time |
---|---|---|
Re: FW: query pg_stat_ssl hang 100%cpu | Thomas Munro | 22:37 |
Re: FW: query pg_stat_ssl hang 100%cpu | Michael Paquier | 22:47 |
Thread | Author | Time |
---|---|---|
Re: Planning time is time-consuming | Laurenz Albe | 01:15 |
Re: Planning time is time-consuming | Anupam b | 01:23 |
Re: Planning time is time-consuming | Andreas Kretschmer | 04:45 |
Fwd: Planning time is time-consuming | Mikhail Balayan | 04:55 |
Fwd: Planning time is time-consuming | Mikhail Balayan | 04:57 |
Re: Fwd: Planning time is time-consuming | Laurenz Albe | 08:13 |
Re: Planning time is time-consuming | David Rowley | 08:24 |
Re: Planning time is time-consuming | David Rowley | 10:17 |
Re: Range partitioning query performance with date_trunc (vs timescaledb) | Philippe Pepiot | 12:21 |
Re: Planning time is time-consuming | Frits Hoogland | 13:54 |
Re: Planning time is time-consuming | Tom Lane | 14:27 |
Re: Planning time is time-consuming | Imre Samu | 15:17 |
Thread | Author | Time |
---|---|---|
Re: Planning time is time-consuming | David Rowley | 03:06 |
Thread | Author | Time |
---|---|---|
Re: FW: query pg_stat_ssl hang 100%cpu | Thomas Munro | 03:11 |
Multixact wraparound monitoring | bruno da silva | 12:21 |
Thread | Author | Time |
---|---|---|
Re: Multixact wraparound monitoring | Wyatt Alt | 05:14 |
Re: Multixact wraparound monitoring | Alvaro Herrera | 11:23 |
Re: Multixact wraparound monitoring | bruno da silva | 19:35 |
Thread | Author | Time |
---|---|---|
Re: Multixact wraparound monitoring | Alvaro Herrera | 09:48 |
pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit | Achilleas Mantzios - cloud | 14:30 |
Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit | Tom Lane | 15:23 |
Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit | Achilleas Mantzios | 19:31 |
Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit | Tom Lane | 19:42 |
Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit | Achilleas Mantzios | 20:36 |
Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit | Thomas Munro | 23:08 |
Thread | Author | Time |
---|---|---|
Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit | Achilleas Mantzios | 03:27 |
Thread | Author | Time |
---|---|---|
Dirty reads on index scan, | Koen De Groote | 15:05 |
Re: Dirty reads on index scan, | Laurenz Albe | 19:30 |
Thread | Author | Time |
---|---|---|
Re: Dirty reads on index scan, | Koen De Groote | 08:35 |
Re: Dirty reads on index scan, | Laurenz Albe | 09:14 |
Re: Dirty reads on index scan, | Frits Hoogland | 13:22 |
Re: Dirty reads on index scan, | Koen De Groote | 13:54 |
Thread | Author | Time |
---|---|---|
Re: Dirty reads on index scan, | Jeff Janes | 20:17 |
Thread | Author | Time |
---|---|---|
Unexpected termination looping over table. | Matt Gibbins | 00:57 |
Re: Unexpected termination looping over table. | Tom Lane | 01:09 |
Re: Unexpected termination looping over table. | Matt Gibbins | 02:36 |
Thread | Author | Time |
---|---|---|
Postgres 15 SELECT query doesn't use index under RLS | Alexander Okulovich | 16:41 |
Thread | Author | Time |
---|---|---|
Re: Postgres 15 SELECT query doesn't use index under RLS | Tom Lane | 20:26 |
Thread | Author | Time |
---|---|---|
Underestimated number of output rows with an aggregate function 📎 | Philippe BEAUDOIN | 08:38 |
Re: Underestimated number of output rows with an aggregate function | Tom Lane | 16:37 |
Thread | Author | Time |
---|---|---|
Re: Underestimated number of output rows with an aggregate function | Philippe BEAUDOIN | 16:52 |
Thread | Author | Time |
---|---|---|
GIN JSONB path index is not always used | Tomasz Szymański | 13:48 |
Re: GIN JSONB path index is not always used | Laurenz Albe | 14:17 |
Re: GIN JSONB path index is not always used | Jeff Janes | 17:05 |
Thread | Author | Time |
---|---|---|
Re: Postgres 15 SELECT query doesn't use index under RLS | Alexander Okulovich | 10:29 |
Re: Postgres 15 SELECT query doesn't use index under RLS | Alexander Okulovich | 14:07 |
Re: Postgres 15 SELECT query doesn't use index under RLS | Tom Lane | 20:35 |
Thread | Author | Time |
---|---|---|
Re: Postgres 15 SELECT query doesn't use index under RLS | Tomek | 07:43 |
Re: Postgres 15 SELECT query doesn't use index under RLS | Alexander Okulovich | 09:58 |
Thread | Author | Time |
---|---|---|
Re: GIN JSONB path index is not always used | Tomasz Szymański | 10:33 |
Re: GIN JSONB path index is not always used | Jeff Janes | 14:05 |
Thread | Author | Time |
---|---|---|
Re: Postgres 15 SELECT query doesn't use index under RLS | Alexander Okulovich | 13:47 |
Re: Postgres 15 SELECT query doesn't use index under RLS | Tom Lane | 14:09 |
Thread | Author | Time |
---|---|---|
Re: Postgres 15 SELECT query doesn't use index under RLS | Alexander Okulovich | 16:01 |
Postgres Locking | Dirschel, Steve | 21:12 |
RE: Postgres Locking | Smith, Travis | 21:43 |
Re: Postgres Locking | Tom Lane | 21:45 |
Thread | Author | Time |
---|---|---|
Performance down with JDBC 42 | Abraham, Danny | 19:08 |
Re: Performance down with JDBC 42 | Laurenz Albe | 21:07 |
Thread | Author | Time |
---|---|---|
RE: [EXTERNAL] Re: Performance down with JDBC 42 | Abraham, Danny | 16:20 |
Re: [EXTERNAL] Re: Performance down with JDBC 42 | Andreas Kretschmer | 16:52 |
Re: [EXTERNAL] Re: Performance down with JDBC 42 | Frits Hoogland | 17:34 |
Re: [EXTERNAL] Re: Performance down with JDBC 42 | Jeff Janes | 19:11 |
RE: [EXTERNAL] Re: Performance down with JDBC 42 | Abraham, Danny | 19:37 |
Re: [EXTERNAL] Re: Performance down with JDBC 42 | David Rowley | 19:47 |
Thread | Author | Time |
---|---|---|
Re: [EXTERNAL] Performance down with JDBC 42 | Frits Hoogland | 09:24 |
Performance problems with Postgres JDBC 42.4.2 | Jose Osinde | 14:59 |
Thread | Author | Time |
---|---|---|
Re: Performance problems with Postgres JDBC 42.4.2 | Dave Cramer | 16:55 |
Thread | Author | Time |
---|---|---|
Awkward Join between generate_series and long table | Lincoln Swaine-Moore | 01:26 |
Re: Awkward Join between generate_series and long table | David G. Johnston | 01:44 |
Re: Awkward Join between generate_series and long table | Lincoln Swaine-Moore | 02:19 |
Re: Awkward Join between generate_series and long table | Philip Semanchuk | 13:54 |
RE: [EXTERNAL] Performance down with JDBC 42 | Abraham, Danny | 14:00 |
Re: Awkward Join between generate_series and long table | Lincoln Swaine-Moore | 18:00 |
Thread | Author | Time |
---|---|---|
simple query running long time within a long transaction. | James Pang (chaolpan) | 08:10 |
Re: simple query running long time within a long transaction. | Andreas Kretschmer | 09:17 |
Thread | Author | Time |
---|---|---|
RE: simple query running long time within a long transaction. | James Pang (chaolpan) | 11:13 |
[No subject] | Gulp | 11:18 |
Re: simple query running long time within a long transaction. | Frits Hoogland | 11:46 |
Thread | Author | Time |
---|---|---|
Performance degradation with CTEs, switching from PG 11 to PG 15 | Jean-Christophe Boggio | 11:38 |
Re: Performance degradation with CTEs, switching from PG 11 to PG 15 | John Naylor | 13:30 |
Re: Performance degradation with CTEs, switching from PG 11 to PG 15 | Jean-Christophe Boggio | 13:48 |
Re: Performance degradation with CTEs, switching from PG 11 to PG 15 | Andreas Kretschmer | 14:25 |
Re: Performance degradation with CTEs, switching from PG 11 to PG 15 | Jean-Christophe Boggio | 15:58 |
Re: Performance degradation with CTEs, switching from PG 11 to PG 15 | Tom Lane | 16:07 |
Thread | Author | Time |
---|---|---|
Strange "actual time" in simple CTE | Jean-Christophe Boggio | 16:50 |
Thread | Author | Time |
---|---|---|
Re: Strange "actual time" in simple CTE | Jeff Janes | 03:15 |
Does Postgres have consistent identifiers (plan hash value) for explain plans? | Jerry Brenner | 14:45 |
Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? | Tom Lane | 14:57 |
Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? | Julien Rouhaud | 17:30 |
Thread | Author | Time |
---|---|---|
Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? | Michael Paquier | 03:05 |
Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? | Tom Lane | 03:29 |
Re: Does Postgres have consistent identifiers (plan hash value) for explain plans? | Jerry Brenner | 14:03 |
Include a timestamp in future versions of pg_stat_statements when when a query entered the cache? | Jerry Brenner | 14:28 |
Thread | Author | Time |
---|---|---|
Re: Include a timestamp in future versions of pg_stat_statements when when a query entered the cache? | Julien Rouhaud | 06:45 |
Thread | Author | Time |
---|---|---|
Question about semantics of $ variables in json explain plans in 13 📎 | Jerry Brenner | 23:09 |
Thread | Author | Time |
---|---|---|
Re: Planning time is time-consuming | Merlin Moncure | 21:49 |
Thread | Author | Time |
---|---|---|
Re: Planning time is time-consuming | Michał Kłeczek | 04:59 |
Thread | Author | Time |
---|---|---|
Which side of a Merge Join gets executed first? Do both sides always get executed? 📎 | Jerry Brenner | 14:40 |
Re: Which side of a Merge Join gets executed first? Do both sides always get executed? | Frédéric Yhuel | 18:05 |
Re: Which side of a Merge Join gets executed first? Do both sides always get executed? | Frédéric Yhuel | 18:32 |
Re: Which side of a Merge Join gets executed first? Do both sides always get executed? | Jerry Brenner | 19:04 |
Thread | Author | Time |
---|---|---|
Re: Which side of a Merge Join gets executed first? Do both sides always get executed? | Frédéric Yhuel | 06:27 |
Thread | Author | Time |
---|---|---|
Slow GroupAggregate and Sort | Darwin Correa | 02:49 |
Thread | Author | Time |
---|---|---|
Re: Parallel hints in PostgreSQL with consistent perfromance | mohini mane | 12:46 |
Re: Parallel hints in PostgreSQL with consistent perfromance | Matheus de Oliveira | 13:12 |
Re: Parallel hints in PostgreSQL with consistent perfromance | David G. Johnston | 13:40 |
Re: Slow GroupAggregate and Sort | Jeff Janes | 18:06 |
Thread | Author | Time |
---|---|---|
Re: Parallel hints in PostgreSQL with consistent perfromance | Jeff Janes | 04:55 |
Thread | Author | Time |
---|---|---|
Re: Slow GroupAggregate and Sort | Darwin Correa | 14:57 |
Thread | Author | Time |
---|---|---|
Re: Parallel hints in PostgreSQL with consistent perfromance | mohini mane | 15:12 |
Re: Parallel hints in PostgreSQL with consistent perfromance | David G. Johnston | 16:14 |
Re: Parallel hints in PostgreSQL with consistent perfromance | mohini mane | 18:06 |
Questions about "Output" in EXPLAIN ANALYZE VERBOSE | Jerry Brenner | 18:28 |
Re: Questions about "Output" in EXPLAIN ANALYZE VERBOSE | Jeff Janes | 19:15 |
Re: Questions about "Output" in EXPLAIN ANALYZE VERBOSE | Tom Lane | 19:23 |
Re: Questions about "Output" in EXPLAIN ANALYZE VERBOSE 📎 | Jerry Brenner | 21:27 |
Thread | Author | Time |
---|---|---|
Re: Parallel hints in PostgreSQL with consistent perfromance | Jeff Janes | 01:43 |
Re: Slow GroupAggregate and Sort | Jeff Janes | 02:43 |
Re: Parallel hints in PostgreSQL with consistent perfromance | mohini mane | 07:52 |
Thread | Author | Time |
---|---|---|
Re: Slow GroupAggregate and Sort | Darwin Correa | 21:09 |
Thread | Author | Time |
---|---|---|
Selection not "pushed down into" CTE | Clemens Eisserer | 07:37 |
Re: Selection not "pushed down into" CTE | Tom Lane | 16:55 |
Thread | Author | Time |
---|---|---|
Re: Selection not "pushed down into" CTE | Clemens Eisserer | 17:48 |
Thread | Author | Time |
---|---|---|
Why is a sort required for this query? (IS NULL predicate on leading key column) | Jerry Brenner | 14:39 |
Re: Why is a sort required for this query? (IS NULL predicate on leading key column) | Jerry Brenner | 14:48 |
Re: Why is a sort required for this query? (IS NULL predicate on leading key column) | Tom Lane | 15:11 |
Thread | Author | Time |
---|---|---|
I don't understand that EXPLAIN PLAN timings | Jean-Christophe Boggio | 06:48 |
Thread | Author | Time |
---|---|---|
Re: I don't understand that EXPLAIN PLAN timings | Jean-Christophe Boggio | 07:45 |
Re: I don't understand that EXPLAIN PLAN timings | David Rowley | 10:41 |
Thread | Author | Time |
---|---|---|
Re: I don't understand that EXPLAIN PLAN timings | Jean-Christophe Boggio | 13:31 |
Re: I don't understand that EXPLAIN PLAN timings | David Rowley | 21:11 |
Re: I don't understand that EXPLAIN PLAN timings | Tom Lane | 21:32 |
Thread | Author | Time |
---|---|---|
Re: I don't understand that EXPLAIN PLAN timings | Jean-Christophe Boggio | 03:22 |
Re: I don't understand that EXPLAIN PLAN timings | Jean-Christophe Boggio | 04:22 |
Re: I don't understand that EXPLAIN PLAN timings | David Rowley | 04:46 |
Thread | Author | Time |
---|---|---|
Slow query in table where many rows were deleted. VACUUM FULL fixes it | Pavlos Kallis | 09:40 |
Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it | Laurenz Albe | 15:37 |
Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it | Philip Semanchuk | 20:08 |
Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it | David Rowley | 20:38 |
Thread | Author | Time |
---|---|---|
Performance | Mehmet COKCEVIK | 11:18 |
Re: Performance | Samed YILDIRIM | 12:10 |
Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it | Divya Sharma | 15:44 |
Thread | Author | Time |
---|---|---|
Weird performance differences between cloud vendors | Dirk Krautschick | 09:23 |
Re: Weird performance differences between cloud vendors | Laurenz Albe | 11:07 |
huge SubtransSLRU and SubtransBuffer wait_event | James Pang (chaolpan) | 11:50 |
Re: huge SubtransSLRU and SubtransBuffer wait_event | Laurenz Albe | 12:41 |
Memory growth using many named prepared statements, in spite of using DISCARD ALL afterwards. | Daniel Blanch Bataller | 13:40 |
Re: Memory growth using many named prepared statements, in spite of using DISCARD ALL afterwards. | Heikki Linnakangas | 13:51 |
RE: huge SubtransSLRU and SubtransBuffer wait_event | James Pang (chaolpan) | 15:34 |
Thread | Author | Time |
---|---|---|
RE: huge SubtransSLRU and SubtransBuffer wait_event | James Pang (chaolpan) | 06:47 |
Re: Memory growth using many named prepared statements, in spite of using DISCARD ALL afterwards. | Daniel Blanch Bataller | 07:45 |
Re: huge SubtransSLRU and SubtransBuffer wait_event | Alvaro Herrera | 08:12 |
Re: huge SubtransSLRU and SubtransBuffer wait_event | Lars Aksel Opsahl | 09:26 |
Re: huge SubtransSLRU and SubtransBuffer wait_event | Nikolay Samokhvalov | 10:04 |
Re: huge SubtransSLRU and SubtransBuffer wait_event | Laurenz Albe | 10:31 |
Thread | Author | Time |
---|---|---|
RE: huge SubtransSLRU and SubtransBuffer wait_event | James Pang (chaolpan) | 06:59 |
Thread | Author | Time |
---|---|---|
Simple JOIN on heavy table not using expected index | kimaidou | 14:14 |
Re: Simple JOIN on heavy table not using expected index | Burçin Yazıcı | 14:19 |
Re: Simple JOIN on heavy table not using expected index | kimaidou | 15:07 |
Re: Simple JOIN on heavy table not using expected index | Tom Lane | 15:12 |
Re: Simple JOIN on heavy table not using expected index | kimaidou | 15:44 |
Thread | Author | Time |
---|---|---|
PostgreSQL doesn't use index-only scan if there is an expression in index | Pavel Kulakov | 14:37 |
Re: PostgreSQL doesn't use index-only scan if there is an expression in index | Laurenz Albe | 15:01 |
Thread | Author | Time |
---|---|---|
"not related" code blocks for removal of dead rows when using vacuum and this kills the performance | Lars Aksel Opsahl | 16:14 |
Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance | Laurenz Albe | 17:46 |
Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance | Lars Aksel Opsahl | 18:36 |
Thread | Author | Time |
---|---|---|
Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance | Lars Aksel Opsahl | 05:46 |
Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance | Laurenz Albe | 07:29 |
Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance | Lars Aksel Opsahl | 10:46 |
Thread | Author | Time |
---|---|---|
sql statement not using all primary key values and poor performance | James Pang | 07:20 |
Re: sql statement not using all primary key values and poor performance | James Pang | 07:25 |
Re: sql statement not using all primary key values and poor performance | Laurenz Albe | 09:17 |
Re: sql statement not using all primary key values and poor performance | James Pang | 10:21 |
Re: sql statement not using all primary key values and poor performance | Laurenz Albe | 11:48 |
Thread | Author | Time |
---|---|---|
Re: FW: huge SubtransSLRU and SubtransBuffer wait_event | James Pang | 06:01 |
Thread | Author | Time |
---|---|---|
Optimizing count(), but Explain estimates wildly off | Chema | 00:25 |
Re: Optimizing count(), but Explain estimates wildly off | Vitalii Tymchyshyn | 04:36 |
Re: Optimizing count(), but Explain estimates wildly off | Laurenz Albe | 07:40 |