pgsql-performance  

Messages by Thread

• • Re: many sessions wait on LWlock WALWrite suddenly Yura Sokolov
  • Re: many sessions wait on LWlock WALWrite suddenly Andres Freund
  • Re: many sessions wait on LWlock WALWrite suddenly Yura Sokolov
• Question on what Duration in the log Vitale, Anthony, Sony Music
  • Re: Question on what Duration in the log Tom Lane
  • RE: Question on what Duration in the log Vitale, Anthony, Sony Music
• Memory Not Released After Batch Completion – Checkpointer/Background Writer Behavior , postgres 15 Motog Plus
  • Re: Memory Not Released After Batch Completion – Checkpointer/Background Writer Behavior , postgres 15 Евгений Чекан
  • Re: Memory Not Released After Batch Completion – Checkpointer/Background Writer Behavior , postgres 15 Motog Plus
• partition table optimizer join cost misestimation James Pang
  • Re: partition table optimizer join cost misestimation Andrei Lepikhov
  • Re: partition table optimizer join cost misestimation James Pang
  • Re: partition table optimizer join cost misestimation Andrei Lepikhov
  • Re: partition table optimizer join cost misestimation James Pang
• Very slow query performance when using CTE Chris Joysn
  • Re: Very slow query performance when using CTE Tom Lane
  • Fwd: Very slow query performance when using CTE Chris Joysn
  • Re: Very slow query performance when using CTE Renan Alves Fonseca
  • Re: Very slow query performance when using CTE Michael Christofides
  • Re: Very slow query performance when using CTE Chris Joysn
• parallel pg_restore blocks on heavy random read I/O on all children processes Dimitrios Apostolou
  • Re: parallel pg_restore blocks on heavy random read I/O on all children processes Tom Lane
  • Re: parallel pg_restore blocks on heavy random read I/O on all children processes Dimitrios Apostolou
  • Re: parallel pg_restore blocks on heavy random read I/O on all children processes Tom Lane
  • Re: parallel pg_restore blocks on heavy random read I/O on all children processes Dimitrios Apostolou
  • Re: parallel pg_restore blocks on heavy random read I/O on all children processes Dimitrios Apostolou
  • Re: parallel pg_restore blocks on heavy random read I/O on all children processes Dimitrios Apostolou
  • Re: parallel pg_restore blocks on heavy random read I/O on all children processes Hannu Krosing
• PostgreSQL 16 - Detach partition with FK - Error Adithya Kumaranchath
  • Re: PostgreSQL 16 - Detach partition with FK - Error Álvaro Herrera
• Background writer not active Motog Plus
• Bad perf when using DECLARE CURSOR on big table kimaidou
  • Re: Bad perf when using DECLARE CURSOR on big table Tom Lane
  • Re: Bad perf when using DECLARE CURSOR on big table kimaidou
• Bulk DML performance bill.poole
  • Re: Bulk DML performance Laurenz Albe
  • RE: Bulk DML performance bill.poole
  • Re: Bulk DML performance Laurenz Albe
  • Re: Bulk DML performance Laurenz Albe
  • RE: Bulk DML performance bill.poole
  • Re: Bulk DML performance Álvaro Herrera
  • Re: Bulk DML performance Renan Alves Fonseca
  • Re: Bulk DML performance Greg Sabino Mullane
  • Re: Bulk DML performance Renan Alves Fonseca
  • RE: Bulk DML performance bill.poole
• Asking for OK for a nasty trick to resolve PG CVE-2025-1094 i Abraham, Danny
• Re: [PERFORM] Unused index influencing sequential scan plan Thom Brown
• Re: Slow performance of collate "en_US.utf8" Achilleas Mantzios - cloud
  • Re: Slow performance of collate "en_US.utf8" Laurenz Albe
  • Re: Slow performance of collate "en_US.utf8" Joe Conway
  • Re: Slow performance of collate "en_US.utf8" Thomas Munro
  • Re: Slow performance of collate "en_US.utf8" Joe Conway
  • Slow performance of collate "en_US.utf8" Alexey Borschev
• Efficient pagination using multi-column cursors large . goose2829
  • Re: Efficient pagination using multi-column cursors Peter Geoghegan
  • Re: Efficient pagination using multi-column cursors large . goose2829
  • Re: Efficient pagination using multi-column cursors Peter Geoghegan
  • Re: Efficient pagination using multi-column cursors Laurenz Albe
  • Re: Efficient pagination using multi-column cursors large . goose2829
• Unfortunate Nested Loop + Missing Autovacuum Lincoln Swaine-Moore
  • Re: Unfortunate Nested Loop + Missing Autovacuum Andrei Lepikhov
  • Re: Unfortunate Nested Loop + Missing Autovacuum Lincoln Swaine-Moore
  • Re: Unfortunate Nested Loop + Missing Autovacuum Jeff Janes
  • Re: Unfortunate Nested Loop + Missing Autovacuum Lincoln Swaine-Moore
  • Re: Unfortunate Nested Loop + Missing Autovacuum Andrei Lepikhov
• Poor performance with row wise comparisons Jon Emord
  • Re: Poor performance with row wise comparisons Greg Sabino Mullane
  • Re: Poor performance with row wise comparisons Jon Emord
  • Re: Poor performance with row wise comparisons Tom Lane
  • Re: Poor performance with row wise comparisons Laurenz Albe
  • Re: Poor performance with row wise comparisons Peter Geoghegan
  • Re: Poor performance with row wise comparisons lokesh
  • Re: Poor performance with row wise comparisons David G. Johnston
• Performance loss after upgrading from 12.15 to 17.2 Tobias Orlamünde
  • Re: Performance loss after upgrading from 12.15 to 17.2 Laurenz Albe
• High System CPU Usage on Selects Seemingly Caused By Vacuum of Same Table Joshua Banton
  • Re: High System CPU Usage on Selects Seemingly Caused By Vacuum of Same Table Peter Geoghegan
  • Re: High System CPU Usage on Selects Seemingly Caused By Vacuum of Same Table Joshua Banton
• Re: Simple query with Planner underestimating rows. Greg Sabino Mullane
  • Re: Simple query with Planner underestimating rows. Andrei Lepikhov
  • Re: Simple query with Planner underestimating rows. Andrei Lepikhov
• Why ORing with a false one-time filter turns an Index-Lookup into a SeqScan Clemens Eisserer
  • Re: Why ORing with a false one-time filter turns an Index-Lookup into a SeqScan Wetmore, Matthew (CTR)
  • Re: Why ORing with a false one-time filter turns an Index-Lookup into a SeqScan Clemens Eisserer
  • Re: Why ORing with a false one-time filter turns an Index-Lookup into a SeqScan Tom Lane
• Re: Reg pg_restore taking more time in windows compare to linux Laurenz Albe
  • Re: [EXTERNAL] - Re: Reg pg_restore taking more time in windows compare to linux Laurenz Albe
  • Re: [EXTERNAL] - Re: Reg pg_restore taking more time in windows compare to linux Laurenz Albe
• Read-only connectios optimizatios Edson Richter
  • Re: Read-only connectios optimizatios Laurenz Albe
  • Re: Read-only connectios optimizatios peter plachta
  • RE: [EXT] Re: Read-only connectios optimizatios Wong, Kam Fook (TR Technology)
• Any risk or overhead considerations for frequently executing queries against catalog tables? Frits Hoogland
  • Re: Any risk or overhead considerations for frequently executing queries against catalog tables? Pavel Stehule
  • Re: Any risk or overhead considerations for frequently executing queries against catalog tables? Frits Hoogland
  • Re: Any risk or overhead considerations for frequently executing queries against catalog tables? Pavel Stehule
  • Re: Any risk or overhead considerations for frequently executing queries against catalog tables? Frits Hoogland
  • Re: Any risk or overhead considerations for frequently executing queries against catalog tables? peter plachta
  • Re: Any risk or overhead considerations for frequently executing queries against catalog tables? frits . hoogland
  • Re: Any risk or overhead considerations for frequently executing queries against catalog tables? Jeremy Schneider
  • Re: Any risk or overhead considerations for frequently executing queries against catalog tables? Pavel Stehule
• Query planning read a large amount of buffers for partitioned tables bruno vieira da silva
  • Re: Query planning read a large amount of buffers for partitioned tables bruno vieira da silva
  • Re: Query planning read a large amount of buffers for partitioned tables David Rowley
  • Re: Query planning read a large amount of buffers for partitioned tables bruno vieira da silva
  • Re: Query planning read a large amount of buffers for partitioned tables bruno vieira da silva
  • Re: Query planning read a large amount of buffers for partitioned tables bruno vieira da silva
  • Re: Query planning read a large amount of buffers for partitioned tables bruno vieira da silva
  • Re: Query planning read a large amount of buffers for partitioned tables David Rowley
  • Re: Query planning read a large amount of buffers for partitioned tables bruno vieira da silva
• Unexpected Seq Scan's when using MERGE WHEN NOT MATCHED BY SOURCE Feike Steenbergen
  • Re: Unexpected Seq Scan's when using MERGE WHEN NOT MATCHED BY SOURCE Feike Steenbergen
  • Re: Unexpected Seq Scan's when using MERGE WHEN NOT MATCHED BY SOURCE David Mullineux
  • Re: Unexpected Seq Scan's when using MERGE WHEN NOT MATCHED BY SOURCE Tom Lane
  • Re: Unexpected Seq Scan's when using MERGE WHEN NOT MATCHED BY SOURCE Feike Steenbergen
• Question: consolidating strpos searches? James Addison
  • Re: Question: consolidating strpos searches? Tom Lane
  • Re: Question: consolidating strpos searches? Greg Sabino Mullane
  • Re: Question: consolidating strpos searches? James Addison
• huge shared_blocks_hit one select but manually run very fast James Pang
  • Re: huge shared_blocks_hit one select but manually run very fast David Mullineux
  • Re: huge shared_blocks_hit one select but manually run very fast James Pang
  • Re: huge shared_blocks_hit one select but manually run very fast David Mullineux
• Why a bitmap scan in this case? Jon Zeppieri
  • Re: Why a bitmap scan in this case? Greg Sabino Mullane
  • Re: Why a bitmap scan in this case? Jon Zeppieri
  • Re: Why a bitmap scan in this case? Jon Zeppieri
  • Re: Why a bitmap scan in this case? Frédéric Yhuel
  • Re: Why a bitmap scan in this case? Frédéric Yhuel
  • Re: Why a bitmap scan in this case? Jon Zeppieri
• Aggressive vacuum Graham Hay
  • Re: Aggressive vacuum Slava Mudry
  • Re: Aggressive vacuum Jeff Janes
• can a blocked transaction affect the performance of one that is blocking it? Eric Schwarzenbach
  • Re: can a blocked transaction affect the performance of one that is blocking it? Nikolay Samokhvalov
  • Re: can a blocked transaction affect the performance of one that is blocking it? David Mullineux
• PostgreSQL and a Catch-22 Issue related to dead rows Lars Aksel Opsahl
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows [email protected]
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Lars Aksel Opsahl
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Greg Sabino Mullane
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Lars Aksel Opsahl
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Rick Otten
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Lars Aksel Opsahl
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Christophe Pettus
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Tom Lane
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Lars Aksel Opsahl
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Lars Aksel Opsahl
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Greg Sabino Mullane
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Lars Aksel Opsahl
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Greg Sabino Mullane
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Hannu Krosing
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Lars Aksel Opsahl
  • Re: PostgreSQL and a Catch-22 Issue related to dead rows Lars Aksel Opsahl
• Reg. Postgres Unique contraint Sajjad Abid
  • Re: Reg. Postgres Unique contraint Diomedes Dominguez
  • Re: Reg. Postgres Unique contraint Sajjad Abid
  • Re: Reg. Postgres Unique contraint Burcin Yazici
  • Re: Reg. Postgres Unique contraint Vitalii Tymchyshyn
  • RE: Reg. Postgres Unique contraint msalais
  • Re: Reg. Postgres Unique contraint shammat
• Performance of TPC-DS Query 95 Ba Jinsheng
  • Re: Performance of TPC-DS Query 95 David Rowley
• CTE Inline On TPC-DS Query 95 Ba Jinsheng
  • Re: CTE Inline On TPC-DS Query 95 David Rowley
  • RE: CTE Inline On TPC-DS Query 95 msalais
  • Re: CTE Inline On TPC-DS Query 95 David Rowley
• Cardinality estimate of the inner relation Frédéric Yhuel
  • Re: Cardinality estimate of the inner relation Andrei Lepikhov
  • Re: Cardinality estimate of the inner relation Frédéric Yhuel
• Re: Performance of Query 60 on TPC-DS Benchmark Andrei Lepikhov
  • Re: Performance of Query 60 on TPC-DS Benchmark Nikita Malakhov
  • Re: Performance of Query 60 on TPC-DS Benchmark Nikita Malakhov
  • Re: Performance of Query 60 on TPC-DS Benchmark Andrei Lepikhov
• could not send data to client: Connection reset by peer James Pang
  • Re: could not send data to client: Connection reset by peer Tomas Vondra
• Re: Performance of Query 4 on TPC-DS Benchmark Thomas Munro
  • Re: Performance of Query 4 on TPC-DS Benchmark Ba Jinsheng
  • Re: Performance of Query 4 on TPC-DS Benchmark Alena Rybakina
  • Re: Performance of Query 4 on TPC-DS Benchmark Alena Rybakina
  • Re: Performance of Query 4 on TPC-DS Benchmark Andrei Lepikhov
  • Re: Performance of Query 4 on TPC-DS Benchmark Ba Jinsheng
  • Re: Performance of Query 4 on TPC-DS Benchmark Andrei Lepikhov
• tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Achilleas Mantzios
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Tomas Vondra
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Achilleas Mantzios
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Achilleas Mantzios
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Tomas Vondra
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Achilleas Mantzios
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Tomas Vondra
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Achilleas Mantzios
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Tom Lane
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Tomas Vondra
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Achilleas Mantzios - cloud
  • Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 Achilleas Mantzios - cloud
• Major performance degradation with joins in 15.8 or 15.7? Ed Sabol
  • Re: Major performance degradation with joins in 15.8 or 15.7? David Rowley
  • Re: Major performance degradation with joins in 15.8 or 15.7? Ed Sabol
  • Re: Major performance degradation with joins in 15.8 or 15.7? Andrei Lepikhov
  • Re: Major performance degradation with joins in 15.8 or 15.7? Ed Sabol
  • Re: Major performance degradation with joins in 15.8 or 15.7? Andrei Lepikhov

• Earlier messages
• Later messages