Postgres Performance Date Index

• Thread Index

• Re: Reg. Postgres Unique contraint
  • From: shammat
• RE: Reg. Postgres Unique contraint
  • From: msalais
• Re: CTE Inline On TPC-DS Query 95
  • From: David Rowley
• RE: CTE Inline On TPC-DS Query 95
  • From: msalais
• Re: huge shared_blocks_hit one select but manually run very fast
  • From: David Mullineux
• Re: huge shared_blocks_hit one select but manually run very fast
  • From: James Pang
• Re: huge shared_blocks_hit one select but manually run very fast
  • From: David Mullineux
• huge shared_blocks_hit one select but manually run very fast
  • From: James Pang
• Re: Why a bitmap scan in this case?
  • From: Jon Zeppieri
• Re: Why a bitmap scan in this case?
  • From: Frédéric Yhuel
• Re: Why a bitmap scan in this case?
  • From: Frédéric Yhuel
• Re: Why a bitmap scan in this case?
  • From: Jon Zeppieri
• Re: Why a bitmap scan in this case?
  • From: Jon Zeppieri
• Re: Why a bitmap scan in this case?
  • From: Greg Sabino Mullane
• Why a bitmap scan in this case?
  • From: Jon Zeppieri
• Aggressive vacuum
  • From: Graham Hay
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Lars Aksel Opsahl
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Lars Aksel Opsahl
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Hannu Krosing
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Greg Sabino Mullane
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Lars Aksel Opsahl
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Greg Sabino Mullane
• Re: can a blocked transaction affect the performance of one that is blocking it?
  • From: David Mullineux
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Lars Aksel Opsahl
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Lars Aksel Opsahl
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Lars Aksel Opsahl
• Re: can a blocked transaction affect the performance of one that is blocking it?
  • From: Nikolay Samokhvalov
• can a blocked transaction affect the performance of one that is blocking it?
  • From: Eric Schwarzenbach
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Tom Lane
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Christophe Pettus
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Rick Otten
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Lars Aksel Opsahl
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Lars Aksel Opsahl
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Greg Sabino Mullane
• Re: PostgreSQL and a Catch-22 Issue related to dead rows
  • From: MichaelDBA@xxxxxxxxxxx
• PostgreSQL and a Catch-22 Issue related to dead rows
  • From: Lars Aksel Opsahl
• time data type question
  • From: Sbob
• Re: Performance of Query 60 on TPC-DS Benchmark
  • From: Nikita Malakhov
• Re: Performance of Query 60 on TPC-DS Benchmark
  • From: Nikita Malakhov
• Re: Reg. Postgres Unique contraint
  • From: Vitalii Tymchyshyn
• Re: Reg. Postgres Unique contraint
  • From: Burcin Yazici
• Re: Reg. Postgres Unique contraint
  • From: Sajjad Abid
• Re: Reg. Postgres Unique contraint
  • From: Diomedes Dominguez
• Reg. Postgres Unique contraint
  • From: Sajjad Abid
• Re: Has gen_random_uuid() gotten much slower in v17?
  • From: David Mullineux
• Re: CTE Inline On TPC-DS Query 95
  • From: David Rowley
• Re: Performance of TPC-DS Query 95
  • From: David Rowley
• CTE Inline On TPC-DS Query 95
  • From: Ba Jinsheng
• Performance of TPC-DS Query 95
  • From: Ba Jinsheng
• Re: Cardinality estimate of the inner relation
  • From: Frédéric Yhuel
• Re: Performance of Query 60 on TPC-DS Benchmark
  • From: Andrei Lepikhov
• Re: Cardinality estimate of the inner relation
  • From: Andrei Lepikhov
• Re: could not send data to client: Connection reset by peer
  • From: Tomas Vondra
• Cardinality estimate of the inner relation
  • From: Frédéric Yhuel
• Re: Performance of Query 60 on TPC-DS Benchmark
  • From: Andrei Lepikhov
• Performance of Query 60 on TPC-DS Benchmark
  • From: Ba Jinsheng
• could not send data to client: Connection reset by peer
  • From: James Pang
• Re: Has gen_random_uuid() gotten much slower in v17?
  • From: Tom Lane
• Re: Has gen_random_uuid() gotten much slower in v17?
  • From: David Mullineux
• Re: Has gen_random_uuid() gotten much slower in v17?
  • From: Tom Lane
• Re: Has gen_random_uuid() gotten much slower in v17?
  • From: Frédéric Yhuel
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Achilleas Mantzios - cloud
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Achilleas Mantzios - cloud
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Tomas Vondra
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Tom Lane
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Achilleas Mantzios
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Tomas Vondra
• Re: Performance of Query 4 on TPC-DS Benchmark
  • From: Andrei Lepikhov
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Achilleas Mantzios - cloud
• Re: Performance of Query 4 on TPC-DS Benchmark
  • From: Ba Jinsheng
• Re: Performance of Query 4 on TPC-DS Benchmark
  • From: Ba Jinsheng
• Re: Performance of Query 4 on TPC-DS Benchmark
  • From: Andrei Lepikhov
• Re: Performance of Query 4 on TPC-DS Benchmark
  • From: Alena Rybakina
• Re: Performance of Query 4 on TPC-DS Benchmark
  • From: Alena Rybakina
• Re: Performance of Query 4 on TPC-DS Benchmark
  • From: Thomas Munro
• Performance of Query 4 on TPC-DS Benchmark
  • From: Ba Jinsheng
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Achilleas Mantzios
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Tomas Vondra
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Achilleas Mantzios
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Achilleas Mantzios
• Re: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Tomas Vondra
• Re: Major performance degradation with joins in 15.8 or 15.7?
  • From: Andrei Lepikhov
• Re: Major performance degradation with joins in 15.8 or 15.7?
  • From: Ed Sabol
• tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4
  • From: Achilleas Mantzios
• Re: Major performance degradation with joins in 15.8 or 15.7?
  • From: Andrei Lepikhov
• Re: Major performance degradation with joins in 15.8 or 15.7?
  • From: Ed Sabol
• Re: Major performance degradation with joins in 15.8 or 15.7?
  • From: Andrei Lepikhov
• Re: Major performance degradation with joins in 15.8 or 15.7?
  • From: Ed Sabol
• Re: Major performance degradation with joins in 15.8 or 15.7?
  • From: David Rowley
• Major performance degradation with joins in 15.8 or 15.7?
  • From: Ed Sabol
• Re: Bloom filters and the planner / parallel execution
  • From: Rafia Sabih
• Re: Performance of Query 2 in TPC-H
  • From: Andrei Lepikhov
• Re: Postgresql 14/15/16/17 partition pruning on dependent table during join
  • From: Andrei Lepikhov
• Performance of Query 2 in TPC-H
  • From: Ba Jinsheng
• Re: Postgresql 14/15/16/17 partition pruning on dependent table during join
  • From: Stepan Yankevych
• Re: Postgresql 14/15/16/17 partition pruning on dependent table during join
  • From: Andrei Lepikhov
• Re: Postgresql 14/15/16/17 partition pruning on dependent table during join
  • From: Vijaykumar Jain
• Postgresql 14/15/16/17 partition pruning on dependent table during join
  • From: Stepan Yankevych
• Re: Unexpected Performance for the Function simplify_function
  • From: Ba Jinsheng
• Re: Unexpected Performance for the Function simplify_function
  • From: Tom Lane
• Re: lwlock:LockManager wait_events
  • From: SAMEER KUMAR
• Re: Unexpected Performance for the Function simplify_function
  • From: David Rowley
• Re: Unexpected Performance for the Function simplify_function
  • From: Andrei Lepikhov
• Re: Unexpected Performance for the Function simplify_function
  • From: Ba Jinsheng
• Re: Unexpected Performance for the Function simplify_function
  • From: Ba Jinsheng
• Re: lwlock:LockManager wait_events
  • From: Sean Massey
• Re: proposal: schema variables
  • From: James Pang
• Re: proposal: schema variables
  • From: James Pang
• Re: lwlock:LockManager wait_events
  • From: Laurenz Albe
• lwlock:LockManager wait_events
  • From: James Pang
• Re: Unexpected Performance for the Function simplify_function
  • From: Andrei Lepikhov
• Re: Unexpected Performance for the Function simplify_function
  • From: Greg Sabino Mullane
• Re: Unexpected Performance for the Function simplify_function
  • From: David G. Johnston
• Re: Unexpected Performance for the Function simplify_function
  • From: Tom Lane
• Re: Unexpected Performance for the Function simplify_function
  • From: Tom Lane
• Re: Partitioned table scanning all pertitions when the where clause specifies the partition key
  • From: Sbob
• Re: Unexpected Performance for the Function simplify_function
  • From: Shiv Iyer
• Unexpected Performance for the Function simplify_function
  • From: Ba Jinsheng
• Re: Partitioned table scanning all pertitions when the where clause specifies the partition key
  • From: Keith Fiske
• Partitioned table scanning all pertitions when the where clause specifies the partition key
  • From: Sbob
• Adding exclusion constraint in a big table
  • From: Marcelo Fernandes
• Re: ERROR Inserting into partition
  • From: Sbob
• Re: ERROR Inserting into partition
  • From: David G. Johnston
• Re: ERROR Inserting into partition
  • From: David G. Johnston
• ERROR Inserting into partition
  • From: Sbob
• Re: PostgreSQL Package conflicts on Fedora 40
  • From: Laurenz Albe
• PostgreSQL Package conflicts on Fedora 40
  • From: Sbob
• Re: Performance degradation in Index searches with special characters
  • From: Andrey Stikheev
• Bloom filters and the planner / parallel execution
  • From: Daniel Westermann (DWE)
• Re: Performance degradation in Index searches with special characters
  • From: Joe Conway
• Re: Performance degradation in Index searches with special characters
  • From: Thomas Munro
• Re: Performance degradation in Index searches with special characters
  • From: Shiv Iyer
• Re: Performance degradation in Index searches with special characters
  • From: Tom Lane
• Re: Performance degradation in Index searches with special characters
  • From: Joe Conway
• Re: Performance degradation in Index searches with special characters
  • From: Andrey Stikheev
• Re: Performance degradation in Index searches with special characters
  • From: Tom Lane
• Performance degradation in Index searches with special characters
  • From: Andrey Stikheev
• Re: Partition pruning with array-contains check and current_setting function
  • From: Marcelo Zabani
• Re: Has gen_random_uuid() gotten much slower in v17?
  • From: David Mullineux
• Re: Has gen_random_uuid() gotten much slower in v17?
  • From: Peter Eisentraut
• Has gen_random_uuid() gotten much slower in v17?
  • From: David Mullineux
• Re: many backends hang on MultiXactOffsetSLRU
  • From: James Pang
• Re: many backends hang on MultiXactOffsetSLRU
  • From: Alvaro Herrera
• Re: many backends hang on MultiXactOffsetSLRU
  • From: Amine Tengilimoglu
• Re: many backends hang on MultiXactOffsetSLRU
  • From: James Pang
• Re: many backends hang on MultiXactOffsetSLRU
  • From: Alvaro Herrera
• Re: many backends hang on MultiXactOffsetSLRU
  • From: Alvaro Herrera
• Re: many backends hang on MultiXactOffsetSLRU
  • From: Amine Tengilimoglu
• many backends hang on MultiXactOffsetSLRU
  • From: James Pang
• Re: Estimate of the inner_rows
  • From: Tom Lane
• Re: Estimate of the inner_rows
  • From: Tom Lane
• Re: checking for a NULL date in a partitioned table kills performance
  • From: Rui DeSousa
• Re: checking for a NULL date in a partitioned table kills performance
  • From: Sbob
• Re: checking for a NULL date in a partitioned table kills performance
  • From: Muhammad Usman Khan
• Re: checking for a NULL date in a partitioned table kills performance
  • From: Rui DeSousa
• Re: checking for a NULL date in a partitioned table kills performance
  • From: Tom Lane
• Re: checking for a NULL date in a partitioned table kills performance
  • From: David G. Johnston
• Re: checking for a NULL date in a partitioned table kills performance (accidentally sent to the admin list before)
  • From: Vitalii Tymchyshyn
• Re: checking for a NULL date in a partitioned table kills performance
  • From: Sbob
• Re: checking for a NULL date in a partitioned table kills performance
  • From: Sbob
• Re: checking for a NULL date in a partitioned table kills performance
  • From: Rui DeSousa
• checking for a NULL date in a partitioned table kills performance (accidentally sent to the admin list before)
  • From: Sbob
• checking for a NULL date in a partitioned table kills performance
  • From: Sbob
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Stephen Samuel (Sam)
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Tom Lane
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Stephen Samuel (Sam)
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Peter Geoghegan
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Shiv Iyer
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Stephen Samuel (Sam)
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Tom Lane
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Peter Geoghegan
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Tom Lane
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Stephen Samuel (Sam)
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Peter Geoghegan
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Stephen Samuel (Sam)
• Re: Trying to understand why a query is filtering when there is a composite index
  • From: Peter Geoghegan
• Trying to understand why a query is filtering when there is a composite index
  • From: Stephen Samuel (Sam)
• Partition pruning with array-contains check and current_setting function
  • From: Marcelo Zabani
• Re: Postgres index usage
  • From: Greg Sabino Mullane
• Re: Postgres index usage
  • From: Tom Lane
• RE: Postgres index usage
  • From: Dirschel, Steve
• Postgres index usage
  • From: Dirschel, Steve
• Re: logical replication out of memory
  • From: khan Affan
• Re: logical replication out of memory
  • From: James Pang
• Re: logical replication out of memory
  • From: khan Affan
• Re: logical replication out of memory
  • From: James Pang
• logical replication out of memory
  • From: James Pang
• Re: Help with row estimate problem
  • From: Jon Zeppieri
• Re: Help with row estimate problem
  • From: Andrei Lepikhov
• Help with row estimate problem
  • From: Jon Zeppieri
• Re: Outer cost higher than the inner cost
  • From: Tom Lane
• Outer cost higher than the inner cost
  • From: Stanisław Skonieczny
• Re: inequality predicate not pushed down in JOIN?
  • From: Jerry Brenner
• Re: inequality predicate not pushed down in JOIN?
  • From: Paul George
• Re: inequality predicate not pushed down in JOIN?
  • From: Andrei Lepikhov
• inequality predicate not pushed down in JOIN?
  • From: Paul George
• Re: How to solve my slow disk i/o throughput during index scan
  • From: Andrei Lepikhov
• Re: How to solve my slow disk i/o throughput during index scan
  • From: Andrei Lepikhov
• Re: How to solve my slow disk i/o throughput during index scan
  • From: David G. Johnston
• RE: How to solve my slow disk i/o throughput during index scan
  • From: FREYBURGER Simon (SNCF VOYAGEURS / DIRECTION GENERALE TGV / DM RMP YIELD MANAGEMENT)
• RE: How to solve my slow disk i/o throughput during index scan
  • From: FREYBURGER Simon (SNCF VOYAGEURS / DIRECTION GENERALE TGV / DM RMP YIELD MANAGEMENT)
• Re: Specific objects backup in PostgreSQL
  • From: nikhil kumar
• Re: Specific objects backup in PostgreSQL
  • From: Anthony Sotolongo
• Re: Specific objects backup in PostgreSQL
  • From: Olivier Gautherot
• Re: Specific objects backup in PostgreSQL
  • From: David G. Johnston
• Specific objects backup in PostgreSQL
  • From: nikhil kumar
• Re: Query performance issue
  • From: Tom Lane
• Query performance issue
  • From: Dheeraj Sonawane
• Re: Low performance between datacenters
  • From: Andrei Lepikhov
• Re: Hash Right join and seq scan
  • From: Justin Pryzby
• Re: Hash Right join and seq scan
  • From: James Pang
• Re: Low performance between datacenters
  • From: Vitalii Tymchyshyn
• Re: Low performance between datacenters
  • From: Fernando Hevia
• Low performance between datacenters
  • From: Tamás PAPP
• Re: Hash Right join and seq scan
  • From: David Rowley
• Re: Hash Right join and seq scan
  • From: James Pang
• Re: Hash Right join and seq scan
  • From: David Rowley
• Re: How to solve my slow disk i/o throughput during index scan
  • From: Andrei Lepikhov
• Re: Hash Right join and seq scan
  • From: James Pang
• RE: How to solve my slow disk i/o throughput during index scan
  • From: FREYBURGER Simon (SNCF VOYAGEURS / DIRECTION GENERALE TGV / DM RMP YIELD MANAGEMENT)
• Re: How to solve my slow disk i/o throughput during index scan
  • From: Andrei Lepikhov
• How to solve my slow disk i/o throughput during index scan
  • From: FREYBURGER Simon (SNCF VOYAGEURS / DIRECTION GENERALE TGV / DM RMP YIELD MANAGEMENT)
• Re: Hash Right join and seq scan
  • From: Tomas Vondra
• Re: Hash Right join and seq scan
  • From: James Pang
• Re: Hash Right join and seq scan
  • From: James Pang
• Hash Right join and seq scan
  • From: James Pang
• Re: a lot of shared buffers hit when planning for a simple query with primary access path
  • From: Andrei Lepikhov
• Re: a lot of shared buffers hit when planning for a simple query with primary access path
  • From: James Pang
• Re: a lot of shared buffers hit when planning for a simple query with primary access path
  • From: David Rowley
• Re: a lot of shared buffers hit when planning for a simple query with primary access path
  • From: Pavel Stehule
• Re: a lot of shared buffers hit when planning for a simple query with primary access path
  • From: David Rowley
• a lot of shared buffers hit when planning for a simple query with primary access path
  • From: James Pang
• Re: Inconsistent query performance based on relation hit frequency
  • From: Achilleas Mantzios
• Re: Inconsistent query performance based on relation hit frequency
  • From: Laura Hausmann
• Re: Inconsistent query performance based on relation hit frequency
  • From: Achilleas Mantzios - cloud
• Re: Row level security
  • From: Andrew Okhmat
• Re: Inconsistent query performance based on relation hit frequency
  • From: Andrei Lepikhov
• Inconsistent query performance based on relation hit frequency
  • From: Laura Hausmann
• Row level security
  • From: Thomas Simpson
• Re: performance of sql and plpgsql functions
  • From: Julius Tuskenis
• Re: performance of sql and plpgsql functions
  • From: Tom Lane
• Re: performance of sql and plpgsql functions
  • From: Pavel Stehule
• Re: performance of sql and plpgsql functions
  • From: Julius Tuskenis
• Re: performance of sql and plpgsql functions
  • From: Philip Semanchuk
• Re: performance of sql and plpgsql functions
  • From: Julius Tuskenis
• Re: performance of sql and plpgsql functions
  • From: Pavel Stehule
• performance of sql and plpgsql functions
  • From: Julius Tuskenis
• Re: BDR that performs
  • From: Bruce Momjian
• Re: BDR that performs
  • From: P C
• Re: BDR that performs
  • From: Hari Kiran
• Re: BDR that performs
  • From: Bruce Momjian
• BDR that performs
  • From: Smith, Travis
• Re: Need help on configuration SMTP
  • From: nikhil kumar
• Re: Need help on configuration SMTP
  • From: David G. Johnston
• Re: Distinct performance dropped by multiple times in v16
  • From: Andrei Lepikhov
• Re: Need help on configuration SMTP
  • From: Muhammad Ikram
• Need help on configuration SMTP
  • From: nikhil kumar
• RE: Postgresql initialize error
  • From: Smith, Travis
• Re: Postgresql initialize error
  • From: nikhil kumar
• Re: Postgresql initialize error
  • From: nikhil kumar
• Re: Postgresql initialize error
  • From: Muhammad Salahuddin Manzoor
• Re: Postgresql initialize error
  • From: nikhil kumar
• Postgresql initialize error
  • From: nikhil kumar
• Re: Distinct performance dropped by multiple times in v16
  • From: Andrei Lepikhov
• Re: Distinct performance dropped by multiple times in v16
  • From: Greg Sabino Mullane
• Distinct performance dropped by multiple times in v16
  • From: Vitaliy Litovskiy
• query column in pg_stat_statements and pg_stat_activity
  • From: Satalabaha Postgres
• Re: Plan selection based on worst case scenario
  • From: Chema
• Re: Plan selection based on worst case scenario
  • From: David Rowley
• Plan selection based on worst case scenario
  • From: Darwin O'Connor
• Re: Extremely slow to establish connection when user has a high number of roles
  • From: Tom Lane
• Re: Extremely slow to establish connection when user has a high number of roles
  • From: Michal Charemza
• Re: Extremely slow to establish connection when user has a high number of roles
  • From: Tom Lane
• Re: Extremely slow to establish connection when user has a high number of roles
  • From: Michal Charemza
• Re: Extremely slow to establish connection when user has a high number of roles
  • From: Frits Hoogland
• Re: Extremely slow to establish connection when user has a high number of roles
  • From: Michal Charemza
• Re: Extremely slow to establish connection when user has a high number of roles
  • From: Michal Charemza
• Re: Extremely slow to establish connection when user has a high number of roles
  • From: Vijaykumar Jain
• Re: Extremely slow to establish connection when user has a high number of roles
  • From: Tom Lane
• Re: Extremely slow to establish connection when user has a high number of roles
  • From: Tomas Vondra
• Extremely slow to establish connection when user has a high number of roles
  • From: Michal Charemza
• Re: Performance implications of 8K pread()s
  • From: Dimitrios Apostolou
• Re: Performance implications of 8K pread()s
  • From: Thomas Munro
• Re: LWlock:LockManager waits
  • From: Luiz Fernando G. Verona
• Re: LWlock:LockManager waits
  • From: Frits Hoogland
• Re: LWlock:LockManager waits
  • From: Frits Hoogland
• Re: LWlock:LockManager waits
  • From: James Pang
• Re: LWlock:LockManager waits
  • From: Laurenz Albe
• LWlock:LockManager waits
  • From: James Pang
• IN subquery, many joins, very different plans
  • From: Dave Thorn
• Re: maintenance_work_mem impact?
  • From: Laurenz Albe
• maintenance_work_mem impact?
  • From: Adithya Kumaranchath
• Re: FW: huge SubtransSLRU and SubtransBuffer wait_event
  • From: James Pang
• Re: Separate 100 M spatial data in 100 tables VS one big table
  • From: kimaidou
• Re: Optimizing count(), but Explain estimates wildly off
  • From: Chema
• Re: Separate 100 M spatial data in 100 tables VS one big table
  • From: Tomas Vondra
• Re: Optimizing count(), but Explain estimates wildly off
  • From: Greg Sabino Mullane
• Re: Optimizing count(), but Explain estimates wildly off
  • From: Chema
• Re: Separate 100 M spatial data in 100 tables VS one big table
  • From: Marc Millas
• Separate 100 M spatial data in 100 tables VS one big table
  • From: kimaidou
• Re: Is partition pruning impacted by data type
  • From: sud
• Re: Optimizing count(), but Explain estimates wildly off
  • From: Greg Sabino Mullane
• Re: Optimizing count(), but Explain estimates wildly off
  • From: Chema
• Re: Optimizing count(), but Explain estimates wildly off
  • From: Laurenz Albe
• Re: FW: huge SubtransSLRU and SubtransBuffer wait_event
  • From: Alvaro Herrera
• Re: FW: huge SubtransSLRU and SubtransBuffer wait_event
  • From: James Pang
• Re: Optimizing count(), but Explain estimates wildly off
  • From: Chema
• Re: Table Partitioning and Indexes Performance Questions
  • From: Anupam b
• Re: Table Partitioning and Indexes Performance Questions
  • From: Laurenz Albe
• Table Partitioning and Indexes Performance Questions
  • From: David Kelly
• Re: generic plan generate poor performance
  • From: Pavel Stehule
• generic plan generate poor performance
  • From: James Pang
• Re: Fwd: extend statistics help reduce index scan a lot of shared buffer hits.
  • From: Tomas Vondra
• Fwd: extend statistics help reduce index scan a lot of shared buffer hits.
  • From: James Pang
• extend statistics help reduce index scan a lot of shared buffer hits.
  • From: James Pang
• Re: Optimizing count(), but Explain estimates wildly off
  • From: Alvaro Herrera
• Re: Optimizing count(), but Explain estimates wildly off
  • From: Laurenz Albe
• Re: Optimizing count(), but Explain estimates wildly off
  • From: Vitalii Tymchyshyn
• Optimizing count(), but Explain estimates wildly off
  • From: Chema
• Re: FW: huge SubtransSLRU and SubtransBuffer wait_event
  • From: James Pang
• Re: sql statement not using all primary key values and poor performance
  • From: Laurenz Albe
• Re: sql statement not using all primary key values and poor performance
  • From: James Pang
• Re: sql statement not using all primary key values and poor performance
  • From: Laurenz Albe
• Re: sql statement not using all primary key values and poor performance
  • From: James Pang
• sql statement not using all primary key values and poor performance
  • From: James Pang
• Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance
  • From: Lars Aksel Opsahl
• Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance
  • From: Laurenz Albe
• Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance
  • From: Lars Aksel Opsahl
• Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance
  • From: Lars Aksel Opsahl
• Re: "not related" code blocks for removal of dead rows when using vacuum and this kills the performance
  • From: Laurenz Albe
• "not related" code blocks for removal of dead rows when using vacuum and this kills the performance
  • From: Lars Aksel Opsahl
• Re: PostgreSQL doesn't use index-only scan if there is an expression in index
  • From: Laurenz Albe
• PostgreSQL doesn't use index-only scan if there is an expression in index
  • From: Pavel Kulakov
• Re: Simple JOIN on heavy table not using expected index
  • From: kimaidou
• Re: Simple JOIN on heavy table not using expected index
  • From: Tom Lane
• Re: Simple JOIN on heavy table not using expected index
  • From: kimaidou
• Re: Simple JOIN on heavy table not using expected index
  • From: Burçin Yazıcı
• Simple JOIN on heavy table not using expected index
  • From: kimaidou
• RE: huge SubtransSLRU and SubtransBuffer wait_event
  • From: James Pang (chaolpan)
• Re: huge SubtransSLRU and SubtransBuffer wait_event
  • From: Laurenz Albe
• Re: huge SubtransSLRU and SubtransBuffer wait_event
  • From: Nikolay Samokhvalov
• Re: huge SubtransSLRU and SubtransBuffer wait_event
  • From: Lars Aksel Opsahl
• Re: huge SubtransSLRU and SubtransBuffer wait_event
  • From: Alvaro Herrera
• Re: Memory growth using many named prepared statements, in spite of using DISCARD ALL afterwards.
  • From: Daniel Blanch Bataller
• RE: huge SubtransSLRU and SubtransBuffer wait_event
  • From: James Pang (chaolpan)
• RE: huge SubtransSLRU and SubtransBuffer wait_event
  • From: James Pang (chaolpan)
• Re: Memory growth using many named prepared statements, in spite of using DISCARD ALL afterwards.
  • From: Heikki Linnakangas
• Memory growth using many named prepared statements, in spite of using DISCARD ALL afterwards.
  • From: Daniel Blanch Bataller
• Re: huge SubtransSLRU and SubtransBuffer wait_event
  • From: Laurenz Albe
• huge SubtransSLRU and SubtransBuffer wait_event
  • From: James Pang (chaolpan)
• Re: Weird performance differences between cloud vendors
  • From: Laurenz Albe
• Weird performance differences between cloud vendors
  • From: Dirk Krautschick
• Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it
  • From: Divya Sharma
• Re: Performance
  • From: Samed YILDIRIM
• Performance
  • From: Mehmet COKCEVIK
• Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it
  • From: David Rowley
• Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it
  • From: Philip Semanchuk
• Re: Slow query in table where many rows were deleted. VACUUM FULL fixes it
  • From: Laurenz Albe
• Slow query in table where many rows were deleted. VACUUM FULL fixes it
  • From: Pavlos Kallis
• Re: I don't understand that EXPLAIN PLAN timings
  • From: David Rowley
• Re: I don't understand that EXPLAIN PLAN timings
  • From: Jean-Christophe Boggio
• Re: I don't understand that EXPLAIN PLAN timings
  • From: Jean-Christophe Boggio
• Re: I don't understand that EXPLAIN PLAN timings
  • From: Tom Lane
• Re: I don't understand that EXPLAIN PLAN timings
  • From: David Rowley
• Re: I don't understand that EXPLAIN PLAN timings
  • From: Jean-Christophe Boggio
• Re: I don't understand that EXPLAIN PLAN timings
  • From: David Rowley
• Re: I don't understand that EXPLAIN PLAN timings
  • From: Jean-Christophe Boggio
• I don't understand that EXPLAIN PLAN timings
  • From: Jean-Christophe Boggio
• Re: Why is a sort required for this query? (IS NULL predicate on leading key column)
  • From: Tom Lane
• Re: Why is a sort required for this query? (IS NULL predicate on leading key column)
  • From: Jerry Brenner
• Why is a sort required for this query? (IS NULL predicate on leading key column)
  • From: Jerry Brenner
• Re: Selection not "pushed down into" CTE
  • From: Clemens Eisserer
• Re: Slow GroupAggregate and Sort
  • From: Darwin Correa
• Re: Selection not "pushed down into" CTE
  • From: Tom Lane
• Selection not "pushed down into" CTE
  • From: Clemens Eisserer
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: mohini mane
• Re: Slow GroupAggregate and Sort
  • From: Jeff Janes
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: Jeff Janes
• Re: Questions about "Output" in EXPLAIN ANALYZE VERBOSE
  • From: Jerry Brenner
• Re: Questions about "Output" in EXPLAIN ANALYZE VERBOSE
  • From: Tom Lane
• Re: Questions about "Output" in EXPLAIN ANALYZE VERBOSE
  • From: Jeff Janes
• Questions about "Output" in EXPLAIN ANALYZE VERBOSE
  • From: Jerry Brenner
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: mohini mane
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: David G. Johnston
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: mohini mane
• Re: Slow GroupAggregate and Sort
  • From: Darwin Correa
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: Jeff Janes
• Re: Slow GroupAggregate and Sort
  • From: Jeff Janes
• Slow GroupAggregate and Sort
  • From: Darwin Correa
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: David G. Johnston
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: Matheus de Oliveira
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: mohini mane
• Re: [EXTERNAL] Need help with performance tuning pg12 on linux
  • From: Matheus de Oliveira
• Re: [EXTERNAL] Need help with performance tuning pg12 on linux
  • From: Matheus de Oliveira
• Re: [EXTERNAL] Need help with performance tuning pg12 on linux
  • From: Wilson, Maria Louise (LARC-E301)[RSES]
• Re: [EXTERNAL] Need help with performance tuning pg12 on linux
  • From: Ranier Vilela
• Re: [EXTERNAL] Need help with performance tuning pg12 on linux
  • From: Wilson, Maria Louise (LARC-E301)[RSES]
• Re: [EXTERNAL] Need help with performance tuning pg12 on linux
  • From: Matheus de Oliveira
• Re: [EXTERNAL] Need help with performance tuning pg12 on linux
  • From: Wilson, Maria Louise (LARC-E301)[RSES]
• Re: [EXTERNAL] Need help with performance tuning pg12 on linux
  • From: Frits Hoogland
• Re: [EXTERNAL] Re: Need help with performance tuning pg12 on linux
  • From: Wilson, Maria Louise (LARC-E301)[RSES]
• Re: Need help with performance tuning pg12 on linux
  • From: Frits Hoogland
• Need help with performance tuning pg12 on linux
  • From: Wilson, Maria Louise (LARC-E301)[RSES]
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: Jeff Janes
• Re: Parallel hints in PostgreSQL with consistent perfromance
  • From: Tomas Vondra
• Parallel hints in PostgreSQL with consistent perfromance
  • From: mohini mane
• Re: Which side of a Merge Join gets executed first? Do both sides always get executed?
  • From: Frédéric Yhuel
• Re: Which side of a Merge Join gets executed first? Do both sides always get executed?
  • From: Jerry Brenner
• Re: Which side of a Merge Join gets executed first? Do both sides always get executed?
  • From: Frédéric Yhuel
• Re: Which side of a Merge Join gets executed first? Do both sides always get executed?
  • From: Frédéric Yhuel
• Which side of a Merge Join gets executed first? Do both sides always get executed?
  • From: Jerry Brenner
• Re: Planning time is time-consuming
  • From: Michał Kłeczek
• Re: Planning time is time-consuming
  • From: Merlin Moncure
• Re: 2 json explain plans for the same query/plan - why does one have constants while the other has parameter markers?
  • From: Jerry Brenner
• Re: 2 json explain plans for the same query/plan - why does one have constants while the other has parameter markers?
  • From: Jerry Brenner
• Re: Question about semantics of $ variables in json explain plans in 13
  • From: Tom Lane
• Re: 2 json explain plans for the same query/plan - why does one have constants while the other has parameter markers?
  • From: Tom Lane
• 2 json explain plans for the same query/plan - why does one have constants while the other has parameter markers?
  • From: Jerry Brenner
• Question about semantics of $ variables in json explain plans in 13
  • From: Jerry Brenner
• Re: Include a timestamp in future versions of pg_stat_statements when when a query entered the cache?
  • From: Julien Rouhaud
• Include a timestamp in future versions of pg_stat_statements when when a query entered the cache?
  • From: Jerry Brenner
• Re: Does Postgres have consistent identifiers (plan hash value) for explain plans?
  • From: Jerry Brenner
• Re: Does Postgres have consistent identifiers (plan hash value) for explain plans?
  • From: Tom Lane
• Re: Does Postgres have consistent identifiers (plan hash value) for explain plans?
  • From: Michael Paquier
• Re: Does Postgres have consistent identifiers (plan hash value) for explain plans?
  • From: Julien Rouhaud
• Re: Does Postgres have consistent identifiers (plan hash value) for explain plans?
  • From: Tom Lane
• Does Postgres have consistent identifiers (plan hash value) for explain plans?
  • From: Jerry Brenner
• Re: Strange "actual time" in simple CTE
  • From: Jeff Janes
• Strange "actual time" in simple CTE
  • From: Jean-Christophe Boggio
• Re: Performance degradation with CTEs, switching from PG 11 to PG 15
  • From: Tom Lane
• Re: Performance degradation with CTEs, switching from PG 11 to PG 15
  • From: Jean-Christophe Boggio
• Re: Performance degradation with CTEs, switching from PG 11 to PG 15
  • From: Andreas Kretschmer
• Re: Performance degradation with CTEs, switching from PG 11 to PG 15
  • From: Jean-Christophe Boggio
• Re: Performance degradation with CTEs, switching from PG 11 to PG 15
  • From: John Naylor
• Performance degradation with CTEs, switching from PG 11 to PG 15
  • From: Jean-Christophe Boggio
• Re: simple query running long time within a long transaction.
  • From: Frits Hoogland
• [no subject]
  • From: Gulp
• RE: simple query running long time within a long transaction.
  • From: James Pang (chaolpan)
• Re: simple query running long time within a long transaction.
  • From: Andreas Kretschmer
• simple query running long time within a long transaction.
  • From: James Pang (chaolpan)
• Re: Awkward Join between generate_series and long table
  • From: Lincoln Swaine-Moore
• RE: [EXTERNAL] Performance down with JDBC 42
  • From: Abraham, Danny
• Re: Awkward Join between generate_series and long table
  • From: Philip Semanchuk
• Re: Awkward Join between generate_series and long table
  • From: Lincoln Swaine-Moore
• Re: Awkward Join between generate_series and long table
  • From: David G. Johnston
• Awkward Join between generate_series and long table
  • From: Lincoln Swaine-Moore
• Re: Performance problems with Postgres JDBC 42.4.2
  • From: Dave Cramer
• Performance problems with Postgres JDBC 42.4.2
  • From: Jose Osinde
• Re: [EXTERNAL] Performance down with JDBC 42
  • From: Frits Hoogland
• Re: [EXTERNAL] Re: Performance down with JDBC 42
  • From: David Rowley
• RE: [EXTERNAL] Re: Performance down with JDBC 42
  • From: Abraham, Danny
• Re: [EXTERNAL] Re: Performance down with JDBC 42
  • From: Jeff Janes
• Re: [EXTERNAL] Re: Performance down with JDBC 42
  • From: Frits Hoogland
• Re: [EXTERNAL] Re: Performance down with JDBC 42
  • From: Andreas Kretschmer
• RE: [EXTERNAL] Re: Performance down with JDBC 42
  • From: Abraham, Danny
• Re: Performance down with JDBC 42
  • From: Laurenz Albe
• Performance down with JDBC 42
  • From: Abraham, Danny
• RE: Postgres Locking
  • From: Smith, Travis
• Re: Postgres Locking
  • From: Tom Lane
• Postgres Locking
  • From: Dirschel, Steve
• Re: Postgres 15 SELECT query doesn't use index under RLS
  • From: Alexander Okulovich
• Re: Postgres 15 SELECT query doesn't use index under RLS
  • From: Tom Lane
• Re: Postgres 15 SELECT query doesn't use index under RLS
  • From: Alexander Okulovich
• Re: GIN JSONB path index is not always used
  • From: Jeff Janes
• Re: GIN JSONB path index is not always used
  • From: Tomasz Szymański
• Re: Postgres 15 SELECT query doesn't use index under RLS
  • From: Alexander Okulovich
• Re: Postgres 15 SELECT query doesn't use index under RLS
  • From: Tomek
• Re: Postgres 15 SELECT query doesn't use index under RLS
  • From: Tom Lane
• Re: Postgres 15 SELECT query doesn't use index under RLS
  • From: Alexander Okulovich
• Re: Postgres 15 SELECT query doesn't use index under RLS
  • From: Alexander Okulovich
• Re: GIN JSONB path index is not always used
  • From: Jeff Janes
• GIN JSONB path index is not always used
  • From: Tomasz Szymański
• Re: GIN JSONB path index is not always used
  • From: Laurenz Albe
• Re: Underestimated number of output rows with an aggregate function
  • From: Philippe BEAUDOIN
• Re: Underestimated number of output rows with an aggregate function
  • From: Tom Lane
• Underestimated number of output rows with an aggregate function
  • From: Philippe BEAUDOIN
• Re: Postgres 15 SELECT query doesn't use index under RLS
  • From: Tom Lane
• Postgres 15 SELECT query doesn't use index under RLS
  • From: Alexander Okulovich
• Re: Unexpected termination looping over table.
  • From: Matt Gibbins
• Unexpected termination looping over table.
  • From: Matt Gibbins
• Re: Unexpected termination looping over table.
  • From: Tom Lane
• Re: Dirty reads on index scan,
  • From: Jeff Janes
• Re: Dirty reads on index scan,
  • From: Frits Hoogland
• Re: Dirty reads on index scan,
  • From: Koen De Groote
• Re: Dirty reads on index scan,
  • From: Koen De Groote
• Re: Dirty reads on index scan,
  • From: Laurenz Albe
• Re: Dirty reads on index scan,
  • From: Laurenz Albe
• Dirty reads on index scan,
  • From: Koen De Groote
• Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit
  • From: Achilleas Mantzios
• Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit
  • From: Thomas Munro
• Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit
  • From: Achilleas Mantzios
• Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit
  • From: Tom Lane
• Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit
  • From: Achilleas Mantzios
• Re: pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit
  • From: Tom Lane
• Re: Multixact wraparound monitoring
  • From: Alvaro Herrera
• pgsql 10.23 , different systems, same table , same plan, different Buffers: shared hit
  • From: Achilleas Mantzios - cloud
• Re: Multixact wraparound monitoring
  • From: bruno da silva
• Re: Multixact wraparound monitoring
  • From: Alvaro Herrera
• Re: Multixact wraparound monitoring
  • From: Wyatt Alt
• Multixact wraparound monitoring
  • From: bruno da silva
• Re: Planning time is time-consuming
  • From: David Rowley
• Re: Planning time is time-consuming
  • From: Imre Samu
• Re: Planning time is time-consuming
  • From: Frits Hoogland
• Re: Planning time is time-consuming
  • From: Tom Lane
• Fwd: Planning time is time-consuming
  • From: Mikhail Balayan
• Re: Fwd: Planning time is time-consuming
  • From: Laurenz Albe
• Re: Range partitioning query performance with date_trunc (vs timescaledb)
  • From: Philippe Pepiot
• Re: Planning time is time-consuming
  • From: David Rowley
• Re: Planning time is time-consuming
  • From: David Rowley
• Fwd: Planning time is time-consuming
  • From: Mikhail Balayan
• Re: Planning time is time-consuming
  • From: Anupam b
• Re: Planning time is time-consuming
  • From: Laurenz Albe
• Re: Planning time is time-consuming
  • From: Andreas Kretschmer
• Planning time is time-consuming
  • From: Mikhail Balayan
• Re: Index bloat and REINDEX/VACUUM optimization for partial index
  • From: jayaprabhakar k
• query pg_stat_ssl hang 100%cpu
  • From: James Pang (chaolpan)
• query pg_stat_ssl hang 100%cpu
  • From: James Pang (chaolpan)
• Re: Index bloat and REINDEX/VACUUM optimization for partial index
  • From: Maxim Boguk
• Re: Queries containing ORDER BY and LIMIT started to work slowly
  • From: Rondat Flyag
• Re: Queries containing ORDER BY and LIMIT started to work slowly
  • From: Rondat Flyag
• Re: Index bloat and REINDEX/VACUUM optimization for partial index
  • From: Jeff Janes
• Re: Index bloat and REINDEX/VACUUM optimization for partial index
  • From: Jeff Janes
• Re: Index bloat and REINDEX/VACUUM optimization for partial index
  • From: jayaprabhakar k
• Re: Queries containing ORDER BY and LIMIT started to work slowly
  • From: Jeff Janes
• Re: Index bloat and REINDEX/VACUUM optimization for partial index
  • From: Maxim Boguk
• Join order optimization
  • From: Christian Beikov
• Re: Index bloat and REINDEX/VACUUM optimization for partial index
  • From: jayaprabhakar k
• Re: Queries containing ORDER BY and LIMIT started to work slowly
  • From: David Rowley
• Re: Queries containing ORDER BY and LIMIT started to work slowly
  • From: Rondat Flyag
• Re: Queries containing ORDER BY and LIMIT started to work slowly
  • From: Rondat Flyag
• Re: Queries containing ORDER BY and LIMIT started to work slowly
  • From: Rick Otten
• Re: Queries containing ORDER BY and LIMIT started to work slowly
  • From: Jeff Janes
• Re: Index bloat and REINDEX/VACUUM optimization for partial index
  • From: Jeff Janes
• Re: Queries containing ORDER BY and LIMIT started to work slowly
  • From: Rondat Flyag
• Re: Queries containing ORDER BY and LIMIT started to work slowly
  • From: Jeff Janes
• Queries containing ORDER BY and LIMIT started to work slowly
  • From: Rondat Flyag
• Re: Index bloat and REINDEX/VACUUM optimization for partial index
  • From: jayaprabhakar k
• Re: Range partitioning query performance with date_trunc (vs timescaledb)
  • From: David Rowley
• Range partitioning query performance with date_trunc (vs timescaledb)
  • From: Philippe Pepiot
• Re: Index bloat and REINDEX/VACUUM optimization for partial index
  • From: Peter Geoghegan
• Index bloat and REINDEX/VACUUM optimization for partial index
  • From: jayaprabhakar k
• Re: Slow query, possibly not using index
  • From: Les
• Re: Slow query, possibly not using index
  • From: David Rowley
• Re: Slow query, possibly not using index
  • From: Pavel Stehule
• Re: Slow query, possibly not using index
  • From: Les
• Re: Slow query, possibly not using index
  • From: Les
• Re: Slow query, possibly not using index
  • From: Les
• Re: Slow query, possibly not using index
  • From: Tom Lane
• Re: Slow query, possibly not using index
  • From: Wael Khobalatte
• Re: Slow query, possibly not using index
  • From: Les
• Re: Slow query, possibly not using index
  • From: Tom Lane
• Slow query, possibly not using index
  • From: Les
• Question regarding writes when locking rows
  • From: Martin Querleu
• Re: slow delete
  • From: Jeff Janes
• Re: slow delete
  • From: Les
• Re: slow delete
  • From: Tom Lane
• slow delete
  • From: Les
• Re: Partitioning update-heavy queue with hash partitions vs partial indexes
  • From: Dorian Hoxha
• Re: Partitioning update-heavy queue with hash partitions vs partial indexes
  • From: burcinyazici
• Re: Partitioning update-heavy queue with hash partitions vs partial indexes
  • From: David Rowley
• Partitioning update-heavy queue with hash partitions vs partial indexes
  • From: Dorian Hoxha
• Re: Function call very slow from JDBC/java but super fast from DBear
  • From: David G. Johnston
• Re: Function call very slow from JDBC/java but super fast from DBear
  • From: An, Hongguo (CORP)
• Re: Function call very slow from JDBC/java but super fast from DBear
  • From: Dave Cramer
• Function call very slow from JDBC/java but super fast from DBear
  • From: An, Hongguo (CORP)
• Re: Plan weirdness. A sort produces more rows than the node beneath it
  • From: Dane Foster
• Re: Plan weirdness. A sort produces more rows than the node beneath it
  • From: Tom Lane
• Re: Plan weirdness. A sort produces more rows than the node beneath it
  • From: Dane Foster
• Re: Plan weirdness. A sort produces more rows than the node beneath it
  • From: Tom Lane
• Re: Plan weirdness. A sort produces more rows than the node beneath it
  • From: Dane Foster
• Re: Plan weirdness. A sort produces more rows than the node beneath it
  • From: Jeff Janes
• Plan weirdness. A sort produces more rows than the node beneath it
  • From: Dane Foster
• Re: Table copy with SERIALIZABLE is incredibly slow
  • From: Laurenz Albe
• Table copy with SERIALIZABLE is incredibly slow
  • From: peter plachta
• Results of experiments with UUIDv7, UUIDv8
  • From: peter plachta
• Re: TOAST Fields serialisation/deserialization performance
  • From: Piyush Katariya
• Re: TOAST Fields serialisation/deserialization performance
  • From: Laurenz Albe
• TOAST Fields serialisation/deserialization performance
  • From: Piyush Katariya
• Re: Performance implications of 8K pread()s
  • From: Andres Freund
• Re: Performance implications of 8K pread()s
  • From: Dimitrios Apostolou
• Re: Performance implications of 8K pread()s
  • From: Thomas Munro
• Re: Performance implications of 8K pread()s
  • From: Dimitrios Apostolou
• Re: Performance implications of 8K pread()s
  • From: Thomas Munro
• Re: Performance implications of 8K pread()s
  • From: Thomas Munro
• Entire index scanned, but only when in SQL function?
  • From: Philip Semanchuk
• Performance implications of 8K pread()s
  • From: Dimitrios Apostolou
• Re: Why is query performance on RLS enabled Postgres worse?
  • From: Akash Anand
• Why is query performance on RLS enabled Postgres worse?
  • From: Akash Anand
• Fwd: Helping planner to chose sequential scan when it improves performance
  • From: Patrick O'Toole
• Re: Merge David and Goliath tables efficiently
  • From: Tomas Vondra
• Re: Merge David and Goliath tables efficiently
  • From: nicolas paris
• Re: Index on (fixed size) bytea value
  • From: Les
• Re: Index on (fixed size) bytea value
  • From: Laurenz Albe
• Re: Index on (fixed size) bytea value
  • From: Les
• Re: Merge David and Goliath tables efficiently
  • From: Tomas Vondra
• Re: Index on (fixed size) bytea value
  • From: David G. Johnston
• Index on (fixed size) bytea value
  • From: Les
• Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT
  • From: Benoit Tigeot
• Re: Merge David and Goliath tables efficiently
  • From: nicolas paris
• Re: Merge David and Goliath tables efficiently
  • From: Tomas Vondra
• Re: Merge David and Goliath tables efficiently
  • From: nicolas paris
• Re: Merge David and Goliath tables efficiently
  • From: nicolas paris
• Re: Merge David and Goliath tables efficiently
  • From: Tomas Vondra
• Re: Merge David and Goliath tables efficiently
  • From: Tomas Vondra
• Re: Merge David and Goliath tables efficiently
  • From: Alvaro Herrera
• RE: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT
  • From: msalais
• Re: Merge David and Goliath tables efficiently
  • From: nicolas paris
• Re: Merge David and Goliath tables efficiently
  • From: Tomas Vondra
• Re: Merge David and Goliath tables efficiently
  • From: nicolas paris
• Re: Merge David and Goliath tables efficiently
  • From: Tomas Vondra
• Merge David and Goliath tables efficiently
  • From: Nicolas Paris
• Re: Postgresql equal join on function with columns not use index
  • From: Pavel Stehule
• RE: Postgresql equal join on function with columns not use index
  • From: James Pang (chaolpan)
• Re: Postgresql equal join on function with columns not use index
  • From: Pavel Stehule
• Re: Postgresql equal join on function with columns not use index
  • From: Pavel Stehule
• Re: Postgresql equal join on function with columns not use index
  • From: Tom Lane
• Re: extended statistics n-distinct on multiple columns not used when join two tables
  • From: Pavel Stehule
• extended statistics n-distinct on multiple columns not used when join two tables
  • From: James Pang (chaolpan)
• Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT
  • From: Chris Hoover
• RE: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT
  • From: benoit
• Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT
  • From: Chris Hoover
• RE: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT
  • From: benoit
• Re: Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT
  • From: Peter Geoghegan
• Forced to use UNION ALL when having multiple ANY operators and ORDER BY LIMIT
  • From: benoit
• RE: Postgresql equal join on function with columns not use index
  • From: James Pang (chaolpan)
• Re: Postgresql equal join on function with columns not use index
  • From: Tom Lane
• Postgresql equal join on function with columns not use index
  • From: James Pang (chaolpan)
• Re: wrong rows estimation by hash join
  • From: Tomas Vondra
• wrong rows estimation by hash join
  • From: James Pang (chaolpan)
• Re: Weird behavior of INSERT QUERY
  • From: Satalabaha Postgres
• Re: Weird behavior of INSERT QUERY
  • From: Ranier Vilela
• Re: Weird behavior of INSERT QUERY
  • From: Satalabaha Postgres
• Re: Weird behavior of INSERT QUERY
  • From: Satalabaha Postgres
• Re: Weird behavior of INSERT QUERY
  • From: Ranier Vilela
• Re: Weird behavior of INSERT QUERY
  • From: Tom Lane
• Re: Weird behavior of INSERT QUERY
  • From: Julien Rouhaud
• Re: Weird behavior of INSERT QUERY
  • From: Satalabaha Postgres
• Re: Weird behavior of INSERT QUERY
  • From: Julien Rouhaud
• Re: Weird behavior of INSERT QUERY
  • From: Satalabaha Postgres
• Weird behavior of INSERT QUERY
  • From: Satalabaha Postgres
• Re: Understand time taken by individual SQL statements in a procedure
  • From: Satalabaha Postgres
• Re: Understand time taken by individual SQL statements in a procedure
  • From: Julien Rouhaud
• Understand time taken by individual SQL statements in a procedure
  • From: Satalabaha Postgres
• Re: thousands of CachedPlan entry per backend
  • From: Jeff Janes
• RE: thousands of CachedPlan entry per backend
  • From: James Pang (chaolpan)
• Re: thousands of CachedPlan entry per backend
  • From: Pavel Stehule
• RE: thousands of CachedPlan entry per backend
  • From: James Pang (chaolpan)
• Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server
  • From: Sergio Rus
• Re: thousands of CachedPlan entry per backend
  • From: Laurenz Albe
• RE: thousands of CachedPlan entry per backend
  • From: James Pang (chaolpan)
• Re: thousands of CachedPlan entry per backend
  • From: Pavel Stehule
• Re: thousands of CachedPlan entry per backend
  • From: Laurenz Albe
• thousands of CachedPlan entry per backend
  • From: James Pang (chaolpan)
• Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server
  • From: Ranier Vilela
• Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server
  • From: Andres Freund
• Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server
  • From: Imre Samu
• Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server
  • From: Sergio Rus
• Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server
  • From: Kenneth Marshall
• How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server
  • From: Sergio Rus
• Re: Unaccounted regression from postgresql 11 in later versions
  • From: Bob Jolliffe
• Re: Unaccounted regression from postgresql 11 in later versions
  • From: Michael Christofides
• Unaccounted regression from postgresql 11 in later versions
  • From: Bob Jolliffe
• Re: Fsync IO issue
  • From: Merlin Moncure
• Re: PostgreSQL performance on ARM i.MX6
  • From: Ranier Vilela
• Re: PostgreSQL performance on ARM i.MX6
  • From: Richard Huxton
• Re: PostgreSQL performance on ARM i.MX6
  • From: Tom Lane