pgsql-performance  

Messages by Thread

• 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
• 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
  • 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
  • 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
• Performance of Query 2 in TPC-H Ba Jinsheng
  • Re: Performance of Query 2 in TPC-H Andrei Lepikhov
• Postgresql 14/15/16/17 partition pruning on dependent table during join Stepan Yankevych
  • Re: Postgresql 14/15/16/17 partition pruning on dependent table during join Vijaykumar Jain
  • Re: Postgresql 14/15/16/17 partition pruning on dependent table during join Andrei Lepikhov
  • Re: Postgresql 14/15/16/17 partition pruning on dependent table during join Stepan Yankevych
  • Re: Postgresql 14/15/16/17 partition pruning on dependent table during join Andrei Lepikhov
• Unexpected Performance for the Function simplify_function Ba Jinsheng
  • Re: Unexpected Performance for the Function simplify_function Tom Lane
  • Re: Unexpected Performance for the Function simplify_function Ba Jinsheng
  • Re: Unexpected Performance for the Function simplify_function Tom Lane
  • Re: Unexpected Performance for the Function simplify_function Ba Jinsheng
  • Re: Unexpected Performance for the Function simplify_function Andrei Lepikhov
  • Re: Unexpected Performance for the Function simplify_function Ba Jinsheng
  • Re: Unexpected Performance for the Function simplify_function Andrei Lepikhov
  • Re: Unexpected Performance for the Function simplify_function David Rowley
  • Re: Unexpected Performance for the Function simplify_function Shiv Iyer
  • Re: Unexpected Performance for the Function simplify_function Greg Sabino Mullane
  • Re: Unexpected Performance for the Function simplify_function Tom Lane
  • Re: Unexpected Performance for the Function simplify_function David G. Johnston
• Re: proposal: schema variables James Pang
  • Re: proposal: schema variables James Pang
• lwlock:LockManager wait_events James Pang
  • Re: lwlock:LockManager wait_events Laurenz Albe
  • Re: lwlock:LockManager wait_events Sean Massey
  • Re: lwlock:LockManager wait_events SAMEER KUMAR
• Adding exclusion constraint in a big table Marcelo Fernandes
• Bloom filters and the planner / parallel execution Daniel Westermann (DWE)
  • Re: Bloom filters and the planner / parallel execution Rafia Sabih
• Performance degradation in Index searches with special characters Andrey Stikheev
  • Re: Performance degradation in Index searches with special characters Tom Lane
  • Re: Performance degradation in Index searches with special characters Andrey Stikheev
  • Re: Performance degradation in Index searches with special characters Joe Conway
  • Re: Performance degradation in Index searches with special characters Tom Lane
  • Re: Performance degradation in Index searches with special characters Joe Conway
  • Re: Performance degradation in Index searches with special characters Andrey Stikheev
  • Re: Performance degradation in Index searches with special characters Shiv Iyer
  • Re: Performance degradation in Index searches with special characters Thomas Munro
• Re: Has gen_random_uuid() gotten much slower in v17? Peter Eisentraut
  • Re: Has gen_random_uuid() gotten much slower in v17? David Mullineux
  • Re: Has gen_random_uuid() gotten much slower in v17? Frédéric Yhuel
  • Re: Has gen_random_uuid() gotten much slower in v17? Tom Lane
  • Re: Has gen_random_uuid() gotten much slower in v17? David Mullineux
  • Re: Has gen_random_uuid() gotten much slower in v17? Tom Lane
  • Re: Has gen_random_uuid() gotten much slower in v17? David Mullineux
• many backends hang on MultiXactOffsetSLRU James Pang
  • Re: many backends hang on MultiXactOffsetSLRU Amine Tengilimoglu
  • Re: many backends hang on MultiXactOffsetSLRU Alvaro Herrera
  • Re: many backends hang on MultiXactOffsetSLRU James Pang
  • Re: many backends hang on MultiXactOffsetSLRU Amine Tengilimoglu
  • Re: many backends hang on MultiXactOffsetSLRU Alvaro Herrera
  • Re: many backends hang on MultiXactOffsetSLRU James Pang
  • Re: many backends hang on MultiXactOffsetSLRU Alvaro Herrera
• Estimate of the inner_rows 陈雁飞
  • Re: Estimate of the inner_rows Tom Lane
  • Re: Estimate of the inner_rows Tom Lane
• Re: checking for a NULL date in a partitioned table kills performance Tom Lane
  • Re: checking for a NULL date in a partitioned table kills performance Rui DeSousa
• checking for a NULL date in a partitioned table kills performance (accidentally sent to the admin list before) Sbob
  • Re: checking for a NULL date in a partitioned table kills performance (accidentally sent to the admin list before) Vitalii Tymchyshyn
• Trying to understand why a query is filtering when there is a composite index Stephen Samuel (Sam)
  • Re: Trying to understand why a query is filtering when there is a composite index Peter Geoghegan
  • Re: Trying to understand why a query is filtering when there is a composite index Stephen Samuel (Sam)
  • Re: Trying to understand why a query is filtering when there is a composite index Peter Geoghegan
  • Re: Trying to understand why a query is filtering when there is a composite index Stephen Samuel (Sam)
  • Re: Trying to understand why a query is filtering when there is a composite index Tom Lane
  • Re: Trying to understand why a query is filtering when there is a composite index Peter Geoghegan
  • Re: Trying to understand why a query is filtering when there is a composite index Tom Lane
  • Re: Trying to understand why a query is filtering when there is a composite index Stephen Samuel (Sam)
  • Re: Trying to understand why a query is filtering when there is a composite index Peter Geoghegan
  • Re: Trying to understand why a query is filtering when there is a composite index Stephen Samuel (Sam)
  • Re: Trying to understand why a query is filtering when there is a composite index Tom Lane
  • Re: Trying to understand why a query is filtering when there is a composite index Stephen Samuel (Sam)
  • Re: Trying to understand why a query is filtering when there is a composite index Shiv Iyer
• Partition pruning with array-contains check and current_setting function Marcelo Zabani
  • Re: Partition pruning with array-contains check and current_setting function Marcelo Zabani

• Earlier messages