Postgres Performance Date Index

• Thread Index

• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Justin Pryzby
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Ranier Vilela
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Justin Pryzby
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Justin Pryzby
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Maciek Sakrejda
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Justin Pryzby
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Mladen Gogala
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Postgres using the wrong index index
  • From: Justin Pryzby
• Re: Postgres using the wrong index index
  • From: Matt Dupree
• Re: Postgres using the wrong index index
  • From: Justin Pryzby
• Re: Postgres using the wrong index index
  • From: Matt Dupree
• Re: Postgres using the wrong index index
  • From: Justin Pryzby
• Re: Postgres using the wrong index index
  • From: Mladen Gogala
• Re: Postgres using the wrong index index
  • From: Matt Dupree
• Re: PostgreSQL equivalent of UTL_HTTP
  • From: Pavel Stehule
• PostgreSQL equivalent of UTL_HTTP
  • From: aditya desai
• Re: difference between pg_triggers and information_schema.triggers
  • From: aditya desai
• Re: difference between pg_triggers and information_schema.triggers
  • From: David G. Johnston
• difference between pg_triggers and information_schema.triggers
  • From: aditya desai
• Re: Postgres using the wrong index index
  • From: Justin Pryzby
• Postgres using the wrong index index
  • From: Matt Dupree
• Re: Slow query because lexeme index not used
  • From: Alex
• Re: Slow query because lexeme index not used
  • From: Justin Pryzby
• Slow query because lexeme index not used
  • From: Alex
• Re: Logical Replication speed-up initial data
  • From: Jeff Janes
• Re: Logical Replication speed-up initial data
  • From: Vijaykumar Jain
• Re: Logical Replication speed-up initial data
  • From: Nikhil Shetty
• Re: Logical Replication speed-up initial data
  • From: Nikhil Shetty
• Re: Logical Replication speed-up initial data
  • From: Avinash Kumar
• Re: Logical Replication speed-up initial data
  • From: Vijaykumar Jain
• Re: Logical Replication speed-up initial data
  • From: Rick Otten
• Re: Logical Replication speed-up initial data
  • From: Nikhil Shetty
• Re: Logical Replication speed-up initial data
  • From: Nikhil Shetty
• Re: Logical Replication speed-up initial data
  • From: Christophe Pettus
• Re: Logical Replication speed-up initial data
  • From: Stefano Amoroso
• Re: Logical Replication speed-up initial data
  • From: Hüseyin Demir
• Logical Replication speed-up initial data
  • From: Nikhil Shetty
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Daniel Westermann (DWE)
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Pavel Stehule
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Daniel Westermann (DWE)
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Pavel Stehule
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Pavel Stehule
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Pavel Stehule
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Imre Samu
• Performance issue with thousands of calls to procedures and functions?
  • From: Daniel Westermann (DWE)
• Re: Query performance !
  • From: Justin Pryzby
• Re: Performance of lateral join
  • From: Simen Andreas Andreassen Lønsethagen
• Query performance !
  • From: kenny a
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: David G. Johnston
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Performance of lateral join
  • From: Justin Pryzby
• Re: Query performance !
  • From: Bruce Momjian
• Query performance !
  • From: kenny a
• Re: Performance of lateral join
  • From: Justin Pryzby
• Performance of lateral join
  • From: Simen Andreas Andreassen Lønsethagen
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Performance Issue on a table
  • From: Justin Pryzby
• Performance Issue on a table
  • From: Manoj Kumar
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Vijaykumar Jain
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Vijaykumar Jain
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Alvaro Herrera
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Ranier Vilela
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Justin Pryzby
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Justin Pryzby
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Justin Pryzby
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Justin Pryzby
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: David Rowley
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• Re: Big performance slowdown from 11.2 to 13.3
  • From: David Rowley
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Partitioned table statistics vs autoanalyze
  • From: Kamil Frydel
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Partitioned table statistics vs autoanalyze
  • From: Justin Pryzby
• Partitioned table statistics vs autoanalyze
  • From: Kamil Frydel
• Re: Big performance slowdown from 11.2 to 13.3
  • From: David Rowley
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Michael Lewis
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Justin Pryzby
• Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Query Performance
  • From: Tom Lane
• Query Performance
  • From: Dirschel, Steve
• Re: Performance benchmark of PG
  • From: Manish Lad
• Re: Performance benchmark of PG
  • From: Ninad Shah
• Re: Performance benchmark of PG
  • From: Manish Lad
• Re: Performance benchmark of PG
  • From: Thomas Kellerer
• Re: Performance benchmark of PG
  • From: Hüseyin Demir
• Re: Performance benchmark of PG
  • From: Manish Lad
• Re: Performance benchmark of PG
  • From: Laurenz Albe
• Performance benchmark of PG
  • From: Manish Lad
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Laurenz Albe
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Tobias Gierke
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Tobias Gierke
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Tobias Gierke
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Ninad Shah
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Tom Lane
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: David Rowley
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Benjamin Scherrey
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Justin Pryzby
• Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Tobias Gierke
• Re: temporary file log lines
  • From: Tomas Vondra
• Re: temporary file log lines
  • From: Guillaume Lelarge
• Re: temporary file log lines
  • From: MichaelDBA
• Re: temporary file log lines
  • From: Laurenz Albe
• RE: Partition column should be part of PK
  • From: Michel SALAIS
• Re: Partition column should be part of PK
  • From: Thomas Kellerer
• Re: Partition column should be part of PK
  • From: David Rowley
• Re: Partition column should be part of PK
  • From: Christophe Pettus
• Re: Partition column should be part of PK
  • From: Justin Pryzby
• Re: Partition column should be part of PK
  • From: Nagaraj Raj
• Re: Partition column should be part of PK
  • From: Christophe Pettus
• Re: Partition column should be part of PK
  • From: Nagaraj Raj
• Re: Strange execution plan
  • From: Manuel Weitzman
• RE: Partition column should be part of PK
  • From: Mike Sofen
• Re: Partition column should be part of PK
  • From: Alvaro Herrera
• Re: Partition column should be part of PK
  • From: Justin Pryzby
• temporary file log lines
  • From: MichaelDBA
• Re: Strange execution plan
  • From: Manuel Weitzman
• Re: Strange execution plan
  • From: Manuel Weitzman
• ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification
  • From: Nagaraj Raj
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Allan Barrielle
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Allan Barrielle
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Allan Barrielle
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Justin Pryzby
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Imre Samu
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Justin Pryzby
• ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Allan Barrielle
• Strange execution plan
  • From: Joel Frid
• Strange execution plan
  • From: Joel Frid
• Re: hint in determining effective_io_concurrency
  • From: Luca Ferrari
• Re: hint in determining effective_io_concurrency
  • From: Merlin Moncure
• Re: slow performance with cursor
  • From: Tomas Vondra
• Re: Planning performance problem (67626.278ms)
  • From: David Rowley
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: slow performance with cursor
  • From: Ayub Khan
• Re: slow performance with cursor
  • From: Justin Pryzby
• Re: slow performance with cursor
  • From: Ayub Khan
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: Planning performance problem (67626.278ms)
  • From: Tom Lane
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: Planning performance problem (67626.278ms)
  • From: Tom Lane
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: slow performance with cursor
  • From: Tom Lane
• Re: slow performance with cursor
  • From: Ayub Khan
• Re: slow performance with cursor
  • From: Justin Pryzby
• slow performance with cursor
  • From: Ayub Khan
• Re: Partition column should be part of PK
  • From: Justin Pryzby
• Partition column should be part of PK
  • From: Nagaraj Raj
• Re: Planning performance problem (67626.278ms)
  • From: Tom Lane
• Re: Estimating wal_keep_size
  • From: Dean Gibson (DB Administrator)
• Re: Planning performance problem (67626.278ms)
  • From: Ranier Vilela
• Re: Planning performance problem (67626.278ms)
  • From: Tom Lane
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: Estimating wal_keep_size
  • From: Vijaykumar Jain
• Re: Estimating wal_keep_size
  • From: Julien Rouhaud
• Re: Estimating wal_keep_size
  • From: Dean Gibson (DB Administrator)
• Re: PostgreSQL V13 Replication Issue
  • From: Michael Paquier
• Re: Estimating wal_keep_size
  • From: Julien Rouhaud
• Estimating wal_keep_size
  • From: Dean Gibson (DB Administrator)
• Re: PostgreSQL V13 Replication Issue
  • From: Dean Gibson (DB Administrator)
• PostgreSQL V13 Replication Issue
  • From: Haseeb Khan
• Re: waiting for client write
  • From: Vijaykumar Jain
• Re: Master - Slave Replication Window Server
  • From: Atul Kumar
• Re: waiting for client write
  • From: Ayub Khan
• Re: Master - Slave Replication Window Server
  • From: Haseeb Khan
• Re: Master - Slave Replication Window Server
  • From: Rory Campbell-Lange
• Re: overcommit_ratio setting
  • From: Yi Sun
• Re: overcommit_ratio setting
  • From: Laurenz Albe
• Re: Master - Slave Replication Window Server
  • From: Haseeb Khan
• Re: Master - Slave Replication Window Server
  • From: Haseeb Khan
• Re: overcommit_ratio setting
  • From: Yi Sun
• Re: Master - Slave Replication Window Server
  • From: Rory Campbell-Lange
• Master - Slave Replication Window Server
  • From: Haseeb Khan
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: overcommit_ratio setting
  • From: Laurenz Albe
• Re: overcommit_ratio setting
  • From: Julien Rouhaud
• Re: pg_dumpall --exclude-database case folding, was Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Tom Lane
• pg_dumpall --exclude-database case folding, was Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• overcommit_ratio setting
  • From: Yi Sun
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Vijaykumar Jain
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Vijaykumar Jain
• Re: waiting for client write
  • From: Ranier Vilela
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Jeff Janes
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ranier Vilela
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ranier Vilela
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ranier Vilela
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ranier Vilela
• Re: waiting for client write
  • From: Pavan Pusuluri
• Re: waiting for client write
  • From: Ayub Khan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Tom Lane
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: waiting for client write
  • From: Vijaykumar Jain
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Ranier Vilela
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: waiting for client write
  • From: Jeff Janes
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Joshua Drake
• Re: Page File Size Reached Critical Threshold PostgreSQL V13
  • From: Justin Pryzby
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: Page File Size Reached Critical Threshold PostgreSQL V13
  • From: Justin Pryzby
• Re: waiting for client write
  • From: Ayub Khan
• Re: Page File Size Reached Critical Threshold PostgreSQL V13
  • From: Haseeb Khan
• Re: Page File Size Reached Critical Threshold PostgreSQL V13
  • From: Justin Pryzby
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Page File Size Reached Critical Threshold PostgreSQL V13
  • From: Haseeb Khan
• Re: slow query
  • From: Ayub Khan
• Re: slow query
  • From: Jeff Janes
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Magnus Hagander
• waiting for client write
  • From: Ayub Khan
• Re: slow query
  • From: Ayub Khan
• Re: slow query
  • From: Tom Lane
• Re: slow query
  • From: Ayub Khan
• Re: slow query
  • From: Christophe Pettus
• slow query
  • From: Ayub Khan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: dexter on AWS RDS auto tune queries
  • From: Ayub Khan
• Re: dexter on AWS RDS auto tune queries
  • From: Julien Rouhaud
• Re: dexter on AWS RDS auto tune queries
  • From: Ayub Khan
• Re: dexter on AWS RDS auto tune queries
  • From: Christophe Pettus
• Re: dexter on AWS RDS auto tune queries
  • From: Julien Rouhaud
• dexter on AWS RDS auto tune queries
  • From: Ayub Khan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: query planner not using index, instead using squential scan
  • From: Vijaykumar Jain
• Re: query planner not using index, instead using squential scan
  • From: Ayub Khan
• Re: query planner not using index, instead using squential scan
  • From: Vijaykumar Jain
• Re: query planner not using index, instead using squential scan
  • From: Tom Lane
• query planner not using index, instead using squential scan
  • From: Ayub Khan
• RE: PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: Taras Savchuk
• Re: PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: Tom Lane
• Re: PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: Vijaykumar Jain
• Re: PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: David Rowley
• PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: Taras Savchuk
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Ayub Khan
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Pavel Stehule
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Ayub Khan
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Pavel Stehule
• slow query with inline function on AWS RDS with RDS 24x large
  • From: Ayub Khan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Justin Pryzby
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Tom Lane
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Christophe Pettus
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Jan Wieck
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Alexey M Boltenkov
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Christophe Pettus
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Jan Wieck
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Bob Lunney
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Bruce Momjian
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Pavel Stehule
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Jan Wieck
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Michael Lewis
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Ryan Bair
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: MichaelDBA
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Campbell, Lance
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: transaction blocking on COMMIT
  • From: Bob Jolliffe
• Count (select 1) subquery as constant
  • From: Eugen Konkov
• Re: issue partition scan
  • From: Christophe Pettus
• Re: issue partition scan
  • From: David Rowley
• Re: issue partition scan
  • From: Nagaraj Raj
• Re: issue partition scan
  • From: Christophe Pettus
• issue partition scan
  • From: Nagaraj Raj
• Re: transaction blocking on COMMIT
  • From: Alexey M Boltenkov
• Re: transaction blocking on COMMIT
  • From: Christophe Pettus
• Re: transaction blocking on COMMIT
  • From: Bob Jolliffe
• Re: Optimising outer joins in the presence of non-nullable references
  • From: Tom Lane
• Re: transaction blocking on COMMIT
  • From: Vijaykumar Jain
• Re: transaction blocking on COMMIT
  • From: Bob Jolliffe
• Optimising outer joins in the presence of non-nullable references
  • From: Philip Lykke Carlsen
• Re: transaction blocking on COMMIT
  • From: Vijaykumar Jain
• transaction blocking on COMMIT
  • From: Bob Jolliffe
• RE: Partition with check constraint with "like"
  • From: Michel SALAIS
• Re: Partition with check constraint with "like"
  • From: David Rowley
• Re: Partition with check constraint with "like"
  • From: David Rowley
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• RE: Partition with check constraint with "like"
  • From: Michel SALAIS
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: Partition with check constraint with "like"
  • From: Vijaykumar Jain
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: logical replication
  • From: Marc Millas
• Re: logical replication
  • From: Andrew Dunstan
• logical replication
  • From: Marc Millas
• Re: Partition with check constraint with "like"
  • From: David Rowley
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: Partition with check constraint with "like"
  • From: Michael Lewis
• Re: Partition with check constraint with "like"
  • From: Justin Pryzby
• Re: Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: Partition with check constraint with "like"
  • From: David Rowley
• Partition with check constraint with "like"
  • From: Nagaraj Raj
• Re: Index and statistics not used
  • From: David Rowley
• Index and statistics not used
  • From: rstander
• Re: BUG #16968: Planner does not recognize optimization
  • From: Eugen Konkov
• Re: BUG #16968: Planner does not recognize optimization
  • From: Eugen Konkov
• Re: BUG #16968: Planner does not recognize optimization
  • From: David Rowley
• Re: BUG #16968: Planner does not recognize optimization
  • From: David Rowley
• Re: BUG #16968: Planner does not recognize optimization
  • From: Eugen Konkov
• Re: Very slow "bloat query"
  • From: Marcin Gozdalik
• Re: Very slow "bloat query"
  • From: Marcin Gozdalik
• Re: Very slow "bloat query"
  • From: Imre Samu
• Re: BUG #16968: Planner does not recognize optimization
  • From: KES
• Re: Very slow "bloat query"
  • From: Marcin Gozdalik
• Re: Very slow "bloat query"
  • From: Tom Lane
• Re: Very slow "bloat query"
  • From: Imre Samu
• Re: Very slow "bloat query"
  • From: Gilles Darold
• Very slow "bloat query"
  • From: Marcin Gozdalik
• RE: Re: PostgreSQL blocked locks query
  • From: Manoj Kumar
• Re: BUG #16968: Planner does not recognize optimization
  • From: David Rowley
• Re: PostgreSQL blocked locks query
  • From: Justin Pryzby
• PostgreSQL blocked locks query
  • From: Manoj Kumar
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: didier
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Peter Geoghegan
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Peter Geoghegan
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Tom Lane
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Justin Pryzby
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Rick Otten
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Vijaykumar Jain
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Vijaykumar Jain
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Imre Samu
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Alexey M Boltenkov
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Alexey M Boltenkov
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Justin Pryzby
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Alexey M Boltenkov
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Vijaykumar Jain
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Andreas Joseph Krogh
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Alexey M Boltenkov
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: Alexey M Boltenkov
• Re: Very slow Query compared to Oracle / SQL - Server
  • From: luis . roberto
• Very slow Query compared to Oracle / SQL - Server
  • From: Semen Yefimenko
• Re: 15x slower PreparedStatement vs raw query
  • From: Alex
• Re: 15x slower PreparedStatement vs raw query
  • From: Justin Pryzby
• Re: 15x slower PreparedStatement vs raw query
  • From: David Rowley
• Re: 15x slower PreparedStatement vs raw query
  • From: Vijaykumar Jain
• Re: 15x slower PreparedStatement vs raw query
  • From: Laurenz Albe
• Re: 15x slower PreparedStatement vs raw query
  • From: Alex
• Re: 15x slower PreparedStatement vs raw query
  • From: Rick Otten
• Re: 15x slower PreparedStatement vs raw query
  • From: Alex
• Re: 15x slower PreparedStatement vs raw query
  • From: Justin Pryzby
• 15x slower PreparedStatement vs raw query
  • From: Alex
• Re: Error while calling proc with table type from Application (npgsql)
  • From: Vijaykumar Jain
• Re: Error while calling proc with table type from Application (npgsql)
  • From: aditya desai
• Re: Error while calling proc with table type from Application (npgsql)
  • From: aditya desai
• RES: Log number of tuples returned
  • From: Edson Richter
• Re: Log number of tuples returned
  • From: Justin Pryzby
• Log number of tuples returned
  • From: Edson Richter
• Re: Error while calling proc with table type from Application (npgsql)
  • From: Justin Pryzby
• Error while calling proc with table type from Application
  • From: aditya desai
• Re: Order of execution
  • From: Jean-Christophe Boggio
• Order of execution
  • From: luis . roberto
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Marc Millas
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Rory Campbell-Lange
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Marc Millas
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Simon Connah
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Rory Campbell-Lange
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Tomas Vondra
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Christophe Pettus
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Bruce Momjian
• Re: Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Justin Pryzby
• Does btrfs on Linux have a negative performance impact for PostgreSQL 13?
  • From: Simon Connah
• Re: hint in determining effective_io_concurrency
  • From: Bruce Momjian
• Re: hint in determining effective_io_concurrency
  • From: Justin Pryzby
• Re: hint in determining effective_io_concurrency
  • From: Luca Ferrari
• Re: hint in determining effective_io_concurrency
  • From: Justin Pryzby
• Re: hint in determining effective_io_concurrency
  • From: Bruce Momjian
• Re: hint in determining effective_io_concurrency
  • From: Luca Ferrari
• Re: hint in determining effective_io_concurrency
  • From: Bruce Momjian
• hint in determining effective_io_concurrency
  • From: Luca Ferrari
• Re: Planning performance problem (67626.278ms)
  • From: Tom Lane
• Re: Planning performance problem (67626.278ms)
  • From: David Rowley
• Re: Planning performance problem (67626.278ms)
  • From: Jeremy Schneider
• Re: OLEDB for PostgreSQL
  • From: Pavan Pusuluri
• Re: OLEDB for PostgreSQL
  • From: aditya desai
• Re: Most proper partitioning form on an integer column
  • From: Justin Pryzby
• Most proper partitioning form on an integer column
  • From: Il Mimo di Creta
• Re: Disabling options lowers the estimated cost of a query
  • From: Tomas Vondra
• Re: Why is there a tenfold difference between Postgres's alleged query execution time and packet transmission time?
  • From: Tom Lane
• Re: Disabling options lowers the estimated cost of a query
  • From: Tom Lane
• Re: Disabling options lowers the estimated cost of a query
  • From: Tom Lane
• Re: Strange behavior once statistics are there
  • From: Daniel Westermann (DWE)
• Re: Disabling options lowers the estimated cost of a query
  • From: Tomas Vondra
• Re: Disabling options lowers the estimated cost of a query
  • From: Arne Roland
• Re: Strange behavior once statistics are there
  • From: Tom Lane
• Re: Is there a way to change current time?
  • From: Eugene Pazhitnov
• Re: Is there a way to change current time?
  • From: Pavel Stehule
• Re: Is there a way to change current time?
  • From: Tom Lane
• Re: Is there a way to change current time?
  • From: Justin Pryzby
• Re: Is there a way to change current time?
  • From: Bruce Momjian
• Is there a way to change current time?
  • From: Warstone@list.ru
• Strange behavior once statistics are there
  • From: Daniel Westermann (DWE)
• Why is there a tenfold difference between Postgres's alleged query execution time and packet transmission time?
  • From: Rollo Konig-Brock
• Re: LWLocks by LockManager slowing large DB
  • From: Alvaro Herrera
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• Re: LWLocks by LockManager slowing large DB
  • From: Tom Lane
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• Re: LWLocks by LockManager slowing large DB
  • From: Tom Lane
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: LWLocks by LockManager slowing large DB
  • From: Tom Lane
• Re: LWLocks by LockManager slowing large DB
  • From: Alvaro Herrera
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: LWLocks by LockManager slowing large DB
  • From: Nikolay Samokhvalov
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• RE: LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: LWLocks by LockManager slowing large DB
  • From: Andres Freund
• LWLocks by LockManager slowing large DB
  • From: Paul Friedman
• Re: INSERTS waiting with wait_event is "transactionid"
  • From: Nagaraj Raj
• Re: INSERTS waiting with wait_event is "transactionid"
  • From: Laurenz Albe
• INSERTS waiting with wait_event is "transactionid"
  • From: Nagaraj Raj
• RE: procedure using CURSOR to insert is extremely slow
  • From: Szalontai Zoltán
• Re: procedure using CURSOR to insert is extremely slow
  • From: Milos Babic
• RE: procedure using CURSOR to insert is extremely slow
  • From: Mike Sofen
• RE: procedure using CURSOR to insert is extremely slow
  • From: Szalontai Zoltán
• Re: str_aggr function not wokring
  • From: aditya desai
• Re: str_aggr function not wokring
  • From: aditya desai
• Re: procedure using CURSOR to insert is extremely slow
  • From: Milos Babic
• RE: procedure using CURSOR to insert is extremely slow
  • From: Szalontai Zoltán
• RE: str_aggr function not wokring
  • From: Patrick FICHE
• Re: procedure using CURSOR to insert is extremely slow
  • From: Hervé Schweitzer (HER)
• str_aggr function not wokring
  • From: aditya desai
• procedure using CURSOR to insert is extremely slow
  • From: Szalontai Zoltán
• Re: select count(*) is slow
  • From: aditya desai
• Re: SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
  • From: Andrew Dunstan
• Re: select count(*) is slow
  • From: Andrew Dunstan
• Re: select count(*) is slow
  • From: aditya desai
• Re: select count(*) is slow
  • From: Tom Lane
• Re: Substitute for synonym in Oracle after migration to postgres
  • From: aditya desai
• select count(*) is slow
  • From: aditya desai
• Re: Substitute for synonym in Oracle after migration to postgres
  • From: hubert depesz lubaczewski
• Re: Substitute for synonym in Oracle after migration to postgres
  • From: Laurenz Albe
• Substitute for synonym in Oracle after migration to postgres
  • From: aditya desai
• Re: SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
  • From: aditya desai
• PosgtgreSQL hot standby reading WAL from muli-attached volume?
  • From: Gunther Schadow
• Re: SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
  • From: Justin Pryzby
• Re: SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
  • From: Amine Tengilimoglu
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• SHARED LOCKS , EXCLUSIVE LOCKS, ACCESS EXCLUSIVE LOCKS
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Pavel Stehule
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Pavel Stehule
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Justin Pryzby
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Tom Lane
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Pavel Stehule
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bruce Momjian
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Justin Pryzby
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Michael Lewis
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Pavel Stehule
• Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: Bharath Rupireddy
• SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
  • From: aditya desai
• Re: High availability management tool.
  • From: Adalberto Caccia
• Re: High availability management tool.
  • From: Hüseyin Demir
• Re: High availability management tool.
  • From: Dorian Hoxha
• Re: High-volume writes - what is the max throughput possible
  • From: Hannu Krosing
• Re: High-volume writes - what is the max throughput possible
  • From: Frits Jalvingh
• High-volume writes - what is the max throughput possible
  • From: Geervan Hayatnagarkar
• Re: How do we hint a query to use index in postgre
  • From: Nikhil Shetty
• Re: Odd (slow) plan choice with min/max
  • From: Yoan SULTAN
• Re: SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Hannu Krosing
• Re: Odd (slow) plan choice with min/max
  • From: Paul McGarry
• Re: SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Chris Stephens
• Re: Odd (slow) plan choice with min/max
  • From: Rick Otten
• Re: Odd (slow) plan choice with min/max
  • From: Paul McGarry
• Re: Odd (slow) plan choice with min/max
  • From: Justin Pryzby
• Odd (slow) plan choice with min/max
  • From: Paul McGarry
• Re: SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Hannu Krosing
• Re: SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Chris Stephens
• Re: SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Laurenz Albe
• SQL performance issue (postgresql chooses a bad plan when a better one is available)
  • From: Chris Stephens
• Re: How do we hint a query to use index in postgre
  • From: Manish Lad
• Re: How do we hint a query to use index in postgre
  • From: Gaetano Mendola
• How do we hint a query to use index in postgre
  • From: Manish Lad
• Re: Extremely inefficient merge-join
  • From: Marcin Gozdalik
• Re: Extremely inefficient merge-join
  • From: Tom Lane
• Extremely inefficient merge-join
  • From: Marcin Gozdalik
• Re: wide table, many many partitions, poor query performance
  • From: Laurenz Albe
• Re: wide table, many many partitions, poor query performance
  • From: Justin Pryzby
• wide table, many many partitions, poor query performance
  • From: S Bob
• Re: FreeBSD UFS & fsync
  • From: Luca Ferrari
• Re: FreeBSD UFS & fsync
  • From: Bruce Momjian
• Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?
  • From: Kamil Dziedzic
• Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?
  • From: Michael Lewis
• Re: Fwd: different execution time for the same query (and same DB status)
  • From: Francesco De Angelis
• Re: FreeBSD UFS & fsync
  • From: Thomas Munro
• Re: FreeBSD UFS & fsync
  • From: Luca Ferrari
• Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?
  • From: Kamil Dziedzic
• Re: FreeBSD UFS & fsync
  • From: Bruce Momjian
• Re: Fwd: different execution time for the same query (and same DB status)
  • From: Francesco De Angelis
• Re: Fwd: different execution time for the same query (and same DB status)
  • From: Michael Lewis
• Re: Fwd: different execution time for the same query (and same DB status)
  • From: Justin Pryzby
• Re: different execution time for the same query (and same DB status)
  • From: Francesco De Angelis
• Re: Users grants with setting options
  • From: Nagaraj Raj
• Re: Users grants with setting options
  • From: David G. Johnston
• Users grants with setting options
  • From: Nagaraj Raj
• Re: different execution time for the same query (and same DB status)
  • From: Michael Lewis
• Re: Slow query performance inside a transaction on a clean database
  • From: Laurenz Albe
• Re: different execution time for the same query (and same DB status)
  • From: Tom Lane
• Re: different execution time for the same query (and same DB status)
  • From: Julien Rouhaud
• RE: different execution time for the same query (and same DB status)
  • From: Michel SALAIS
• Fwd: different execution time for the same query (and same DB status)
  • From: Francesco De Angelis
• Slow query performance inside a transaction on a clean database
  • From: val.janeiko
• Re: Potential performance issues related to group by and covering index
  • From: Hannu Krosing
• Re: tables meta data collection
  • From: Justin Pryzby
• tables meta data collection
  • From: Nagaraj Raj
• Re: Potential performance issues related to group by and covering index
  • From: David Rowley
• Re: Potential performance issues related to group by and covering index
  • From: Michael Lewis
• High availability management tool.
  • From: Rodriguez Pablo A
• Re: Performance issues related to left join and order by
  • From: David Rowley
• Re: Potential performance issues related to group by and covering index
  • From: David Rowley
• Re: Potential performance issues related to group by and covering index
  • From: Pavel Stehule
• Performance issues related to left join and order by
  • From: Liu, Xinyu
• Potential performance issues related to group by and covering index
  • From: Liu, Xinyu
• Re: Potential performance issues
  • From: Hannu Krosing
• Re: Postgres performance comparing GCP and AWS
  • From: Hannu Krosing
• Re: Potential performance issues
  • From: Pavel Stehule
• Re: Potential performance issues
  • From: Jung, Jinho
• Re: Potential performance issues
  • From: Rick Otten
• Re: Potential performance issues
  • From: Thomas Kellerer
• Re: Potential performance issues
  • From: Bob Jolliffe
• Re: Potential performance issues
  • From: MichaelDBA
• Re: Potential performance issues
  • From: MichaelDBA
• Re: Potential performance issues
  • From: Andrew Dunstan
• Potential performance issues
  • From: Jung, Jinho
• Re: Postgres performance comparing GCP and AWS
  • From: Justin Pitts
• Re: Postgres performance comparing GCP and AWS
  • From: Igor Gois
• Re: Postgres performance comparing GCP and AWS
  • From: Igor Gois
• Re: Disabling options lowers the estimated cost of a query
  • From: Tom Lane
• Disabling options lowers the estimated cost of a query
  • From: Arne Roland
• Re: Postgres performance comparing GCP and AWS
  • From: Philip Semanchuk
• Re: Postgres performance comparing GCP and AWS
  • From: Philip Semanchuk
• Re: Postgres performance comparing GCP and AWS
  • From: Philip Semanchuk
• Re: Postgres performance comparing GCP and AWS
  • From: Igor Gois
• Re: Postgres performance comparing GCP and AWS
  • From: Imre Samu
• Re: Postgres performance comparing GCP and AWS
  • From: Julien Rouhaud
• Re: Postgres performance comparing GCP and AWS
  • From: Milos Babic
• Re: Postgres performance comparing GCP and AWS
  • From: Gunther Schadow
• Postgres performance comparing GCP and AWS
  • From: Maurici Meneghetti
• Re: FreeBSD UFS & fsync
  • From: Luca Ferrari
• Re: FreeBSD UFS & fsync
  • From: Luca Ferrari
• Re: FreeBSD UFS & fsync
  • From: Thomas Munro
• FreeBSD UFS & fsync
  • From: Luca Ferrari
• Re: Autovacuum not functioning for large tables but it is working for few other small tables.
  • From: Laurenz Albe
• RE: Autovacuum not functioning for large tables but it is working for few other small tables.
  • From: M Tarkeshwar Rao
• Re: Slow query and wrong row estimates for CTE
  • From: Yoan SULTAN
• Re: Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Slow query and wrong row estimates for CTE
  • From: Yoan SULTAN
• Re: Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Query performance issue
  • From: Michael Lewis
• Re: Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Slow query and wrong row estimates for CTE
  • From: Michael Lewis
• Re: Slow query and wrong row estimates for CTE
  • From: Justin Pryzby
• Slow query and wrong row estimates for CTE
  • From: Dane Foster
• Re: Query performance issue
  • From: Tomas Vondra
• Re: Query performance issue
  • From: Justin Pryzby
• Query performance issue
  • From: Nagaraj Raj
• Understanding logical replication lag
  • From: Patrick Molgaard
• Re: High COMMIT times
  • From: Don Seiler
• RE: Need information on how MM frees up disk space (vaccum) after scheduled DB cleanup by BGwCronScript/BGwLogCleaner
  • From: M Tarkeshwar Rao
• Re: How to deal with analyze gathering irrelevant stats
  • From: Michael Lewis
• Re: How to deal with analyze gathering irrelevant stats
  • From: Rémi Chatenay
• Re: How to deal with analyze gathering irrelevant stats
  • From: Michael Lewis