pgsql-performance  

Messages by Thread

• Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column Mark Frost
  • Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column Frédéric Yhuel
  • RE: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column Mark Frost
  • Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column Tom Lane
  • Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column Tom Lane
  • Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column Tom Lane
  • Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column Frédéric Yhuel
• ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized Dimitrios Apostolou
  • Re: ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized Frédéric Yhuel
  • Re: ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized Dimitrios Apostolou
  • Re: ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized Frédéric Yhuel
  • Re: ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized Frédéric Yhuel
  • [PATCH] ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized Dimitrios Apostolou
  • Re: [PATCH] ALTER TABLE ADD FOREIGN KEY to partitioned table, is not parallelized Dimitrios Apostolou
• Re: Database creation performance drop going from pg 14 to pg 15+ Álvaro Herrera
  • Re: Database creation performance drop going from pg 14 to pg 15+ Mahdi Bahrami
  • Re: Database creation performance drop going from pg 14 to pg 15+ Thomas Munro
  • Re: Database creation performance drop going from pg 14 to pg 15+ Mahdi Bahrami
  • Re: Database creation performance drop going from pg 14 to pg 15+ Mahdi Bahrami
• a lot of session wait on lock relation James Pang
  • Re: a lot of session wait on lock relation Chetan
  • Re: a lot of session wait on lock relation Laurenz Albe
  • Re: a lot of session wait on lock relation Tom Lane
  • Re: a lot of session wait on lock relation James Pang
  • Re: a lot of session wait on lock relation James Pang
• inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Maxim Boguk
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Andrei Lepikhov
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Maxim Boguk
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Andrei Lepikhov
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Maxim Boguk
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Andrei Lepikhov
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Andrei Lepikhov
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Maxim Boguk
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) David Rowley
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Maxim Boguk
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Tom Lane
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Maxim Boguk
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Tom Lane
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Andrei Lepikhov
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) Maxim Boguk
  • Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) David Rowley
• Vacuum Questions Leo
  • Re: Vacuum Questions Leo
  • Re: Vacuum Questions John Naylor
  • RE: Vacuum Questions msalais
  • Re: Vacuum Questions Craig Jackson
  • Re: Vacuum Questions Craig Jackson
• PostgreSQL Choosing Full Index Over Partial Index Felipe López Montes
  • Re: PostgreSQL Choosing Full Index Over Partial Index Laurenz Albe
  • Re: PostgreSQL Choosing Full Index Over Partial Index Felipe López Montes
  • Re: PostgreSQL Choosing Full Index Over Partial Index Tom Lane
  • Re: PostgreSQL Choosing Full Index Over Partial Index Felipe López Montes
  • Re: PostgreSQL Choosing Full Index Over Partial Index Tom Lane
• Constraints elimination during runtime Weck, Luis
  • Re: Constraints elimination during runtime Laurenz Albe
• session waiting IO while background writer writing data James Pang
• many sessions wait on LWlock WALWrite suddenly James Pang
  • Re: many sessions wait on LWlock WALWrite suddenly Laurenz Albe
  • Re: many sessions wait on LWlock WALWrite suddenly MichaelDBA
  • 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
  • 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
• 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 michael...@sqlexec.com
  • 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

• Earlier messages