Postgres Performance Date Index

• Thread Index

• Re: Strange behavior of limit clause in complex query
  • From: Ranier Vilela
• Adding non-selective key to jsonb query @> reduces performance?
  • From: Marcin Krupowicz
• Strange behavior of limit clause in complex query
  • From: Paulo Silva
• Re: Query is taking too long i intermittent
  • From: Mayank Kandari
• Re: Query is taking too long i intermittent
  • From: Tom Lane
• Re: Query is taking too long i intermittent
  • From: Justin Pryzby
• Query is taking too long i intermittent
  • From: Mayank Kandari
• Re: rows selectivity overestimate for @> operator for arrays
  • From: Jeff Janes
• Re: REINDEXdb performance degrading gradually PG13.4
  • From: Jeff Janes
• Re: REINDEXdb performance degrading gradually PG13.4
  • From: Praneel Devisetty
• Re: REINDEXdb performance degrading gradually PG13.4
  • From: Michael Paquier
• Logical reads
  • From: Goti
• REINDEXdb performance degrading gradually PG13.4
  • From: David G. Johnston
• REINDEXdb performance degrading gradually PG13.4
  • From: Praneel Devisetty
• RE: postgres backend process hang on " D " state
  • From: James Pang (chaolpan)
• RE: postgres backend process hang on " D " state
  • From: James Pang (chaolpan)
• RE: postgres backend process hang on " D " state
  • From: James Pang (chaolpan)
• Re: postgres backend process hang on " D " state
  • From: Tom Lane
• Re: postgres backend process hang on " D " state
  • From: Justin Pryzby
• RE: postgres backend process hang on " D " state
  • From: James Pang (chaolpan)
• Re: postgres backend process hang on " D " state
  • From: Justin Pryzby
• Re: postgres backend process hang on " D " state
  • From: Ranier Vilela
• postgres backend process hang on " D " state
  • From: James Pang (chaolpan)
• Re: How to monitor Postgres real memory usage
  • From: 徐志宇徐
• Re: rows selectivity overestimate for @> operator for arrays
  • From: Tom Lane
• Re: How to monitor Postgres real memory usage
  • From: Justin Pryzby
• rows selectivity overestimate for @> operator for arrays
  • From: Alexey Ermakov
• Re: How to monitor Postgres real memory usage
  • From: Justin Pryzby
• Re: How to monitor Postgres real memory usage
  • From: 徐志宇徐
• Re: How to monitor Postgres real memory usage
  • From: Justin Pryzby
• Re: How to monitor Postgres real memory usage
  • From: 徐志宇徐
• Re: How to monitor Postgres real memory usage
  • From: 徐志宇徐
• Re: How to monitor Postgres real memory usage
  • From: Justin Pryzby
• How to monitor Postgres real memory usage
  • From: 徐志宇徐
• Re: Array of integer indexed nested-loop semi join
  • From: Mickael van der Beek
• Re: Array of integer indexed nested-loop semi join
  • From: Jeff Janes
• Re: Array of integer indexed nested-loop semi join
  • From: Mickael van der Beek
• Re: Array of integer indexed nested-loop semi join
  • From: Jeff Janes
• Re: Selecting RAM and CPU based on max_connections
  • From: Ganesh Korde
• Re: Selecting RAM and CPU based on max_connections
  • From: aditya desai
• Re: Array of integer indexed nested-loop semi join
  • From: Mickael van der Beek
• Re: Need help on Query Tunning and Not using the Index Scan
  • From: Laurenz Albe
• Re: Selecting RAM and CPU based on max_connections
  • From: Laurenz Albe
• Re: Selecting RAM and CPU based on max_connections
  • From: Andreas Kretschmer
• Selecting RAM and CPU based on max_connections
  • From: aditya desai
• Need help on Query Tunning and Not using the Index Scan
  • From: Kumar, Mukesh
• Re: DB connection issue suggestions
  • From: Justin Pryzby
• Re: DB connection issue suggestions
  • From: Sudhir Guna
• Re: DB connection issue suggestions
  • From: Justin Pryzby
• Re: DB connection issue suggestions
  • From: Ranier Vilela
• Re: DB connection issue suggestions
  • From: Sudhir Guna
• Re: DB connection issue suggestions
  • From: Sudhir Guna
• Re: DB connection issue suggestions
  • From: Sudhir Guna
• Re: DB connection issue suggestions
  • From: Sudhir Guna
• Re: DB connection issue suggestions
  • From: Anbazhagan M
• Re: DB connection issue suggestions
  • From: Laurenz Albe
• Re: DB connection issue suggestions
  • From: Ranier Vilela
• Re: DB connection issue suggestions
  • From: Justin Pryzby
• Re: DB connection issue suggestions
  • From: MichaelDBA Vitale
• DB connection issue suggestions
  • From: Sudhir Guna
• Re: Why is there a Sort after an Index Only Scan?
  • From: Tom Lane
• RE: Why is there a Sort after an Index Only Scan?
  • From: André Hänsel
• Re: Why is there a Sort after an Index Only Scan?
  • From: David Rowley
• Re: Why is there a Sort after an Index Only Scan?
  • From: Jeff Janes
• Why is there a Sort after an Index Only Scan?
  • From: André Hänsel
• Re: Window partial fetch optimization
  • From: Jeff Janes
• Re: Window partial fetch optimization
  • From: David Rowley
• Window partial fetch optimization
  • From: Levi Aul
• Re: Useless memoize path generated for unique join on primary keys
  • From: David Rowley
• Re: Useless memoize path generated for unique join on primary keys
  • From: Benjamin Coutu
• Re: Useless memoize path generated for unique join on primary keys
  • From: David Rowley
• Useless memoize path generated for unique join on primary keys
  • From: Benjamin Coutu
• FATAL: canceling authentication due to timeout
  • From: aditya desai
• Re: LISTEN NOTIFY sometimes huge delay
  • From: Tom Lane
• LISTEN NOTIFY sometimes huge delay
  • From: Peter Eser HEUFT [Germany]
• Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected.
  • From: Emil Iggland
• Re: Unworkable plan above certain row count
  • From: Tom Lane
• Unworkable plan above certain row count
  • From: André Hänsel
• Re: Array of integer indexed nested-loop semi join
  • From: Mickael van der Beek
• Re: Array of integer indexed nested-loop semi join
  • From: Jeff Janes
• Fwd: Array of integer indexed nested-loop semi join
  • From: Mickael van der Beek
• Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected.
  • From: David Rowley
• Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected.
  • From: Emil Iggland
• Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected.
  • From: Tom Lane
• Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected.
  • From: Emil Iggland
• Re: Query Planner not taking advantage of HASH PARTITION
  • From: Justin Pryzby
• Re: Query Planner not taking advantage of HASH PARTITION
  • From: Benjamin Tingle
• Re: Postgresql TPS Bottleneck
  • From: Benedict Holland
• Re: Postgresql TPS Bottleneck
  • From: wakandavision
• Re: significant jump in sql statement timing for on server vs a remote connection
  • From: Ranier Vilela
• Re: Postgresql TPS Bottleneck
  • From: Jeff Janes
• Re: significant jump in sql statement timing for on server vs a remote connection
  • From: Sbob
• Re: Postgresql TPS Bottleneck
  • From: wakandavision
• Re: significant jump in sql statement timing for on server vs a remote connection
  • From: Jeff Janes
• Re: significant jump in sql statement timing for on server vs a remote connection
  • From: Justin Pryzby
• significant jump in sql statement timing for on server vs a remote connection
  • From: Sbob
• How to find all SQLs executed by a transaction id?
  • From: Patil, Ravi
• Re: How to find the final transformed query in postgresql
  • From: Goti
• Re: How to find the final transformed query in postgresql
  • From: Tom Lane
• How to find the final transformed query in postgresql
  • From: Goti
• Re: Query Planner not taking advantage of HASH PARTITION
  • From: Alvaro Herrera
• Re: Query Planner not taking advantage of HASH PARTITION
  • From: Tom Lane
• Re: Query Planner not taking advantage of HASH PARTITION
  • From: Benjamin Tingle
• Re: Query Tunning related to function
  • From: David G. Johnston
• Re: Query Planner not taking advantage of HASH PARTITION
  • From: Tom Lane
• RE: Query Tunning related to function
  • From: Kumar, Mukesh
• RE: Query Tunning related to function
  • From: Kumar, Mukesh
• Query Planner not taking advantage of HASH PARTITION
  • From: Benjamin Tingle
• Re: Query Tunning related to function
  • From: Justin Pryzby
• Re: Query Tunning related to function
  • From: Bhupendra Babu
• Re: Performance for SQL queries on Azure PostgreSQL PaaS instance
  • From: overland
• RE: Query Tunning related to function
  • From: Kumar, Mukesh
• RE: Query Tunning related to function
  • From: Michel SALAIS
• RE: Query Tunning related to function
  • From: Kumar, Mukesh
• Re: SQL performance issue after migration from Oracle to Aurora postgres
  • From: Andrew Dunstan
• Re: Query Tunning related to function
  • From: Ranier Vilela
• Query Tunning related to function
  • From: Kumar, Mukesh
• SQL performance issue after migration from Oracle to Aurora postgres
  • From: Goti
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Justin Pryzby
• RE: An I/O error occurred while sending to the backend (PG 13.4)
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Performance for SQL queries on Azure PostgreSQL PaaS instance
  • From: andrew cooke
• RE: Performance for SQL queries on Azure PostgreSQL PaaS instance
  • From: Kumar, Mukesh
• Re: Performance for SQL queries on Azure PostgreSQL PaaS instance
  • From: Laurenz Albe
• Re: Performance for SQL queries on Azure PostgreSQL PaaS instance
  • From: Tomas Vondra
• Re: Performance for SQL queries on Azure PostgreSQL PaaS instance
  • From: Frits Jalvingh
• Performance for SQL queries on Azure PostgreSQL PaaS instance
  • From: Kumar, Mukesh
• Re: Slow Planning Times
  • From: Saurabh Sehgal
• Re: Slow Planning Times
  • From: Tom Lane
• Re: Slow Planning Times
  • From: Saurabh Sehgal
• Re: Slow Planning Times
  • From: David G. Johnston
• Re: Slow Planning Times
  • From: Saurabh Sehgal
• Slow Planning Times
  • From: Saurabh Sehgal
• Re: HIGH IO and Less CPU utilization
  • From: Rambabu g
• Re: Postgresql TPS Bottleneck
  • From: Mladen Gogala
• Re: Postgresql TPS Bottleneck
  • From: Tomas Vondra
• Re: Postgresql TPS Bottleneck
  • From: MichaelDBA
• Re: HIGH IO and Less CPU utilization
  • From: Mladen Gogala
• Re: Postgresql TPS Bottleneck
  • From: Guillaume Cottenceau
• Postgresql TPS Bottleneck
  • From: wakandavision
• Re: HIGH IO and Less CPU utilization
  • From: Justin Pryzby
• RE: High process memory consumption when running sort
  • From: Shai Shapira
• Re: HIGH IO and Less CPU utilization
  • From: Rambabu g
• Re: HIGH IO and Less CPU utilization
  • From: Justin Pryzby
• Re: HIGH IO and Less CPU utilization
  • From: Rambabu g
• Re: HIGH IO and Less CPU utilization
  • From: Justin Pryzby
• HIGH IO and Less CPU utilization
  • From: Rambabu g
• RE: View taking time to show records
  • From: Kumar, Mukesh
• Re: Performance issue post upgrade on Version 13 - Incorrect Estimation Cost choosing Hash Aggregate-Nested Left Loop Join
  • From: Tomas Vondra
• Re: View taking time to show records
  • From: Laurenz Albe
• Re: View taking time to show records
  • From: Laurenz Albe
• Re: View taking time to show records
  • From: hubert depesz lubaczewski
• Re: View taking time to show records
  • From: aditya desai
• View taking time to show records
  • From: Kumar, Mukesh
• Re: Performance issue post upgrade on Version 13 - Incorrect Estimation Cost choosing Hash Aggregate-Nested Left Loop Join
  • From: Justin Pryzby
• Performance issue post upgrade on Version 13 - Incorrect Estimation Cost choosing Hash Aggregate-Nested Left Loop Join
  • From: Prajna Shetty
• Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view.
  • From: Lars Aksel Opsahl
• Re: High process memory consumption when running sort
  • From: Justin Pryzby
• Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view.
  • From: Lars Aksel Opsahl
• High process memory consumption when running sort
  • From: Shai Shapira
• Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view.
  • From: Justin Pryzby
• Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view.
  • From: Lars Aksel Opsahl
• Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view.
  • From: Lars Aksel Opsahl
• RE: Optimal configuration for server
  • From: Michel SALAIS
• Re: Optimal configuration for server
  • From: Moises Lopez
• Re: Explain analyse with track_io_timing
  • From: Jayadevan M
• Re: Explain analyse with track_io_timing
  • From: Julien Rouhaud
• Explain analyse with track_io_timing
  • From: Jayadevan M
• Re: Any way to speed up INSERT INTO
  • From: aditya desai
• Re: Any way to speed up INSERT INTO
  • From: Bruce Momjian
• Re: Any way to speed up INSERT INTO
  • From: aditya desai
• Re: Optimal configuration for server
  • From: Justin Pryzby
• Re: Optimal configuration for server
  • From: Ranier Vilela
• Re: Optimal configuration for server
  • From: Luiz Felipph
• Re: Optimal configuration for server
  • From: Tomas Vondra
• Re: Optimal configuration for server
  • From: Ranier Vilela
• Re: Optimal configuration for server
  • From: Luiz Felipph
• Re: Optimal configuration for server
  • From: Ranier Vilela
• Optimal configuration for server
  • From: Luiz Felipph
• Re: OOM killer while pg_restore
  • From: Ranier Vilela
• Re: OOM killer while pg_restore
  • From: Marc Rechté
• Re: Any way to speed up INSERT INTO
  • From: aditya desai
• Re: XA transactions much slower on 14.2 than on 13.5
  • From: Tom Lane
• XA transactions much slower on 14.2 than on 13.5
  • From: Mladen Gogala
• Re: Any way to speed up INSERT INTO
  • From: Imre Samu
• RES: Any way to speed up INSERT INTO
  • From: Edson Richter
• Re: Any way to speed up INSERT INTO
  • From: Andres Freund
• Re: Any way to speed up INSERT INTO
  • From: Bruce Momjian
• Re: Any way to speed up INSERT INTO
  • From: aditya desai
• Re: Any way to speed up INSERT INTO
  • From: Tom Lane
• Re: Any way to speed up INSERT INTO
  • From: Bruce Momjian
• Any way to speed up INSERT INTO
  • From: aditya desai
• Re: OOM killer while pg_restore
  • From: Tom Lane
• Re: OOM killer while pg_restore
  • From: Marc Rechté
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Ranier Vilela
• RE: An I/O error occurred while sending to the backend (PG 13.4)
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Ranier Vilela
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Justin Pryzby
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Ranier Vilela
• Re: OOM killer while pg_restore
  • From: Tom Lane
• RE: An I/O error occurred while sending to the backend (PG 13.4)
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: OOM killer while pg_restore
  • From: Justin Pryzby
• Re: OOM killer while pg_restore
  • From: Ranier Vilela
• Re: OOM killer while pg_restore
  • From: Marc Rechté
• Re: OOM killer while pg_restore
  • From: Ranier Vilela
• OOM killer while pg_restore
  • From: Marc Rechté
• Re: Simple task with partitioning which I can't realize
  • From: Mladen Gogala
• Re: Simple task with partitioning which I can't realize
  • From: Geri Wright
• RE: Simple task with partitioning which I can't realize
  • From: Michel SALAIS
• Re: Advice needed: query performance deteriorates by 2000% within 1 minute
  • From: Michael Lewis
• Re: Advice needed: query performance deteriorates by 2000% within 1 minute
  • From: Michael Lewis
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Ranier Vilela
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Justin Pryzby
• RE: Simple task with partitioning which I can't realize
  • From: Andrew Zakharov
• Re: Simple task with partitioning which I can't realize
  • From: Marc Millas
• RE: Simple task with partitioning which I can't realize
  • From: Andrew Zakharov
• Re: Simple task with partitioning which I can't realize
  • From: David G. Johnston
• RE: Simple task with partitioning which I can't realize
  • From: Andrew Zakharov
• Re: Simple task with partitioning which I can't realize
  • From: Marc Millas
• RE: An I/O error occurred while sending to the backend (PG 13.4)
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Simple task with partitioning which I can't realize
  • From: David G. Johnston
• Re: Never Ending query in PostgreSQL
  • From: Tomas Vondra
• Simple task with partitioning which I can't realize
  • From: Andrew Zakharov
• RE: Never Ending query in PostgreSQL
  • From: Kumar, Mukesh
• Re: Never Ending query in PostgreSQL
  • From: Tomas Vondra
• RLS not using index scan but seq scan when condition gets a bit complicated
  • From: Charles Huang
• Re: Advice needed: query performance deteriorates by 2000% within 1 minute
  • From: Peter Adlersburg
• Re: Never Ending query in PostgreSQL
  • From: Mladen Gogala
• Re: Never Ending query in PostgreSQL
  • From: Mladen Gogala
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Justin Pryzby
• RE: An I/O error occurred while sending to the backend (PG 13.4)
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: An I/O error occurred while sending to the backend (PG 13.4)
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: slow query to improve performace
  • From: Jeff Janes
• Re: Never Ending query in PostgreSQL
  • From: Jeff Janes
• Re: Never Ending query in PostgreSQL
  • From: Julien Rouhaud
• Never Ending query in PostgreSQL
  • From: Kumar, Mukesh
• Re: slow query to improve performace
  • From: Justin Pryzby
• slow query to improve performace
  • From: Ayub Khan
• RE: Slow Running Queries in Azure PostgreSQL
  • From: Kumar, Mukesh
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Justin Pryzby
• Re: Slow plan choice with prepared query
  • From: MichaelDBA
• Re: Slow plan choice with prepared query
  • From: MichaelDBA
• Re: Advice needed: query performance deteriorates by 2000% within 1 minute
  • From: Tom Lane
• Re: Advice needed: query performance deteriorates by 2000% within 1 minute
  • From: Michael Lewis
• Advice needed: query performance deteriorates by 2000% within 1 minute
  • From: Peter Adlersburg
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Ranier Vilela
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Justin Pryzby
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Ranier Vilela
• Slow plan choice with prepared query
  • From: Mark Saward
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Justin Pryzby
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Justin Pryzby
• RE: An I/O error occurred while sending to the backend (PG 13.4)
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Slow Running Queries in Azure PostgreSQL
  • From: Justin Pryzby
• Slow Running Queries in Azure PostgreSQL
  • From: Kumar, Mukesh
• Re: Poor performance PostgreSQL 13/ PostGIS 3.x
  • From: Merlin Moncure
• Re: Query chooses Bad Index Path
  • From: Tomas Vondra
• Query chooses Bad Index Path
  • From: Valli Annamalai
• Re: slow "select count(*) from information_schema.tables;" in some cases
  • From: Lars Aksel Opsahl
• Re: Query choosing Bad Index Path (ASC/DESC ordering).
  • From: Mind Body Nature
• Query choosing Bad Index Path (ASC/DESC ordering).
  • From: Valli Annamalai
• Re: slow "select count(*) from information_schema.tables;" in some cases
  • From: Imre Samu
• Re: slow "select count(*) from information_schema.tables;" in some cases
  • From: Lars Aksel Opsahl
• Re: slow "select count(*) from information_schema.tables;" in some cases
  • From: Tom Lane
• Re: slow "select count(*) from information_schema.tables;" in some cases
  • From: Lars Aksel Opsahl
• Re: slow "select count(*) from information_schema.tables;" in some cases
  • From: Vijaykumar Jain
• Re: slow "select count(*) from information_schema.tables;" in some cases
  • From: Lars Aksel Opsahl
• Re: slow "select count(*) from information_schema.tables;" in some cases
  • From: Justin Pryzby
• slow "select count(*) from information_schema.tables;" in some cases
  • From: Lars Aksel Opsahl
• Re: Query choosing Bad Index Path
  • From: Pavel Stehule
• Query choosing Bad Index Path
  • From: Valli Annamalai
• Re: Terribly slow query with very good plan?
  • From: Vijaykumar Jain
• Re: Terribly slow query with very good plan?
  • From: Les
• Re: Terribly slow query with very good plan?
  • From: Thomas Kellerer
• Re: Terribly slow query with very good plan?
  • From: Nick Cleaton
• Re: Terribly slow query with very good plan?
  • From: Les
• Re: Terribly slow query with very good plan?
  • From: Nick Cleaton
• Re: Terribly slow query with very good plan?
  • From: Ninad Shah
• Re: Terribly slow query with very good plan?
  • From: Les
• Re: Terribly slow query with very good plan?
  • From: Nick Cleaton
• Re: Terribly slow query with very good plan?
  • From: Les
• Re: Terribly slow query with very good plan?
  • From: Nick Cleaton
• Re: Terribly slow query with very good plan?
  • From: Les
• Re: Terribly slow query with very good plan?
  • From: Nick Cleaton
• Re: Terribly slow query with very good plan?
  • From: Les
• Re: Terribly slow query with very good plan?
  • From: Les
• Re: Terribly slow query with very good plan?
  • From: Les
• Re: Terribly slow query with very good plan?
  • From: Les
• Re: Terribly slow query with very good plan?
  • From: Nick Cleaton
• Re: Terribly slow query with very good plan?
  • From: Les
• Re: Terribly slow query with very good plan?
  • From: Pavel Stehule
• Re: Terribly slow query with very good plan?
  • From: Laurenz Albe
• Terribly slow query with very good plan?
  • From: Les
• Query runs slower as prepared statement - identical execution plans
  • From: Thomas Kellerer
• Re: Slow query fixed by replacing equality with a nested query
  • From: Michael Lewis
• Re: Slow query fixed by replacing equality with a nested query
  • From: Michael Lewis
• Re: Slow query fixed by replacing equality with a nested query
  • From: Valentin Janeiko
• RE: Slow query fixed by replacing equality with a nested query
  • From: val.janeiko
• Re: Slow query fixed by replacing equality with a nested query
  • From: Michael Lewis
• Re: PostgreSQL and Linux CPU's
  • From: David G. Johnston
• PostgreSQL and Linux CPU's
  • From: Sbob
• Poor performance PostgreSQL 13/ PostGIS 3.x
  • From: Lugosi, Jim
• Slow query fixed by replacing equality with a nested query
  • From: Valentin Janeiko
• RE: PostgreSQL 12.8 Same Query Same Execution Plan Different Time
  • From: Michel SALAIS
• Re: PostgreSQL 12.8 Same Query Same Execution Plan Different Time
  • From: David G. Johnston
• PostgreSQL 12.8 Same Query Same Execution Plan Different Time
  • From: Ludwig Isaac Lim
• Re: Unique constraint blues
  • From: David G. Johnston
• Unique constraint blues
  • From: Mladen Gogala
• Re: PostgreSQLv14 TPC-H performance GCC vs Clang
  • From: arjun shetty
• PGBench connection issue with -C option only
  • From: T T
• Re: About Query Performaces Problem
  • From: Julien Rouhaud
• Re: About Query Performaces Problem
  • From: Pavel Stehule
• Re: About Query Performaces Problem
  • From: Hüseyin Ellezer
• Re: About Query Performaces Problem
  • From: Pavel Stehule
• About Query Performaces Problem
  • From: Hüseyin Ellezer
• Re: Same query 10000x More Time
  • From: Vijaykumar Jain
• RE: Same query 10000x More Time
  • From: Avi Weinberg
• Re: Same query 10000x More Time
  • From: Vijaykumar Jain
• RE: Same query 10000x More Time
  • From: Avi Weinberg
• Re: Same query 10000x More Time
  • From: Kyotaro Horiguchi
• Re: Same query 10000x More Time
  • From: Vijaykumar Jain
• Same query 10000x More Time
  • From: Avi Weinberg
• Re: VACUUM: Nonremovable rows due to wal sender process
  • From: Steve Nixon
• Re:VACUUM: Nonremovable rows due to wal sender process
  • From: Sergei Kornilov
• VACUUM: Nonremovable rows due to wal sender process
  • From: Steve Nixon
• Re: WAL files keep piling up
  • From: Zbigniew Kostrzewa
• Re: 9.6 write time
  • From: Marc Millas
• Re: 9.6 write time
  • From: Tom Lane
• Re: 9.6 write time
  • From: Marc Millas
• Re: 9.6 write time
  • From: Tom Lane
• 9.6 write time
  • From: Marc Millas
• Re: WAL files keep piling up
  • From: Laurenz Albe
• Re: WAL files keep piling up
  • From: Zbigniew Kostrzewa
• Re: WAL files keep piling up
  • From: Tom Lane
• Re: WAL files keep piling up
  • From: Zbigniew Kostrzewa
• Re: WAL files keep piling up
  • From: Ninad Shah
• WAL files keep piling up
  • From: Zbigniew Kostrzewa
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: David G. Johnston
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: Tom Lane
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: Lars Bergeson
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: Justin Pryzby
• Re: Lock contention high
  • From: Yura Sokolov
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: Tom Lane
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: David G. Johnston
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: David G. Johnston
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: Tom Lane
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: Justin Pryzby
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: Lars Bergeson
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: Tom Lane
• Re: Query is slower with a large proportion of NULLs in several columns
  • From: David G. Johnston
• Query is slower with a large proportion of NULLs in several columns
  • From: Lars Bergeson
• PostgreSQLv14 performance client-server-HammerDB
  • From: arjun shetty
• Re: PostgreSQLv14 TPC-H performance GCC vs Clang
  • From: Imre Samu
• Re: pg_trgm word_similarity query does not use index for input strings longer than 8 characters
  • From: pgsql-performance
• Re: pg_trgm word_similarity query does not use index for input strings longer than 8 characters
  • From: Tom Lane
• Re: pg_trgm word_similarity query does not use index for input strings longer than 8 characters
  • From: Laurenz Albe
• pg_trgm word_similarity query does not use index for input strings longer than 8 characters
  • From: pgsql-performance
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Justin Pryzby
• RE: An I/O error occurred while sending to the backend (PG 13.4)
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: An I/O error occurred while sending to the backend (PG 13.4)
  • From: Justin Pryzby
• An I/O error occurred while sending to the backend (PG 13.4)
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: LwLockRelease performance
  • From: Andres Freund
• Re: LwLockRelease performance
  • From: Tom Lane
• LwLockRelease performance
  • From: Ashkil Dighin
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Lock contention high
  • From: arjun shetty
• Re: pg_dump backup verification
  • From: Justin Pryzby
• AW: [External] pg_dump backup verification
  • From: Dirk Krautschick
• pg_dump backup verification
  • From: Daulat
• Re: Need help identifying a periodic performance issue.
  • From: Justin Pryzby
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Out of memory error
  • From: aditya desai
• Re: Postgres process count GCC vs Clang is Different on autovaccum=on
  • From: Tomas Vondra
• Re: Out of memory error
  • From: Thomas Kellerer
• Re: Out of memory error
  • From: Thomas Kellerer
• Postgres process count GCC vs Clang is Different on autovaccum=on
  • From: hpc researcher_mspk
• Re: Out of memory error
  • From: aditya desai
• Re: Out of memory error
  • From: aditya desai
• Re: Out of memory error
  • From: Michael Lewis
• Re: Out of memory error
  • From: aditya desai
• Re: Out of memory error
  • From: Thomas Kellerer
• Re: Out of memory error
  • From: aditya desai
• Re: Out of memory error
  • From: Tom Lane
• Out of memory error
  • From: aditya desai
• Re: performance of analytical query
  • From: Justin Pryzby
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Need help identifying a periodic performance issue.
  • From: Tom Lane
• Re: Need help identifying a periodic performance issue.
  • From: Thomas Munro
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Need help identifying a periodic performance issue.
  • From: Justin Pryzby
• Re: Need help identifying a periodic performance issue.
  • From: Thomas Munro
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Need help identifying a periodic performance issue.
  • From: Justin Pryzby
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Need help identifying a periodic performance issue.
  • From: Thomas Munro
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Need help identifying a periodic performance issue.
  • From: Tom Lane
• Re: Need help identifying a periodic performance issue.
  • From: Justin Pryzby
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Lock contention high
  • From: arjun shetty
• Re: Need help identifying a periodic performance issue.
  • From: Thomas Munro
• Re: Need help identifying a periodic performance issue.
  • From: Thomas Munro
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Need help identifying a periodic performance issue.
  • From: Robert Creager
• PostgreSQLv14 TPC-H performance GCC vs Clang
  • From: arjun shetty
• Re: Need help identifying a periodic performance issue.
  • From: Thomas Munro
• Re: Need help identifying a periodic performance issue.
  • From: Justin Pryzby
• Need help identifying a periodic performance issue.
  • From: Robert Creager
• Re: Lock contention high
  • From: Tom Lane
• Re: postgresql13-llvm jit-13.5-1PGDG.rhel8.x86_64
  • From: Rick Otten
• Re: postgresql13-llvm jit-13.5-1PGDG.rhel8.x86_64
  • From: Mladen Gogala
• Re: Lock contention high
  • From: Ashkil Dighin
• Re: postgresql13-llvm jit-13.5-1PGDG.rhel8.x86_64
  • From: Pavel Stehule
• postgresql13-llvm jit-13.5-1PGDG.rhel8.x86_64
  • From: Mladen Gogala
• Re: performance of analytical query
  • From: Jiří Fejfar
• Re: performance of analytical query
  • From: Justin Pryzby
• Re: performance of analytical query
  • From: Michael Lewis
• Re: performance of analytical query
  • From: Justin Pryzby
• performance of analytical query
  • From: Jiří Fejfar
• Re: EXISTS by itself vs SELECT EXISTS much slower in query.
  • From: Jimmy A
• Re: EXISTS by itself vs SELECT EXISTS much slower in query.
  • From: Tom Lane
• Re: EXISTS by itself vs SELECT EXISTS much slower in query.
  • From: Vasya Boytsov
• EXISTS by itself vs SELECT EXISTS much slower in query.
  • From: Jimmy A
• Re: PostgreSQLv14 TPC-H performance GCC vs Clang
  • From: Tomas Vondra
• Re: PostgreSQLv14 TPC-H performance GCC vs Clang
  • From: arjun shetty
• JIT llvm11 package
  • From: ANASTACIO Tiago
• Re: PostgreSQLv14 TPC-H performance GCC vs Clang
  • From: Imre Samu
• PostgreSQLv14 TPC-H performance GCC vs Clang
  • From: arjun shetty
• Re: Lock contention high
  • From: Ashkil Dighin
• Re: Views don't seem to use indexes?
  • From: Tim Slechta
• Re: Views don't seem to use indexes?
  • From: Tom Lane
• Re: Views don't seem to use indexes?
  • From: David G. Johnston
• Views don't seem to use indexes?
  • From: Tim Slechta
• Re: Lock contention high
  • From: Andres Freund
• Re: Performance for initial copy when using pg_logical to upgrade Postgres
  • From: Westwood, Giles
• Re: Lock contention high
  • From: Andres Freund
• Re: Lock contention high
  • From: Michael Lewis
• Re: Lock contention high
  • From: Andres Freund
• Re: Query out of memory
  • From: Ninad Shah
• Re: Lock contention high
  • From: Ashkil Dighin
• Re: Postgres views cannot use both union and join/where
  • From: David G. Johnston
• Re: Postgres views cannot use both union and join/where
  • From: Tom Lane
• Re: Postgres views cannot use both union and join/where
  • From: David G. Johnston
• Re: Postgres views cannot use both union and join/where
  • From: Michael Lewis
• Re: Postgres views cannot use both union and join/where
  • From: Benedict Holland
• Re: Postgres views cannot use both union and join/where
  • From: David G. Johnston
• Postgres views cannot use both union and join/where
  • From: Mithran Kulasekaran
• Re: Query out of memory
  • From: aditya desai
• Re: Query out of memory
  • From: Michael Lewis
• Sv: Fwd: Query out of memory
  • From: Andreas Joseph Krogh
• Re: Query out of memory
  • From: aditya desai
• Re: Fwd: Query out of memory
  • From: Justin Pryzby
• Re: Query out of memory
  • From: Dave Cramer
• Re: Query out of memory
  • From: Adam Brusselback
• Fwd: Query out of memory
  • From: aditya desai
• Re: Lock contention high
  • From: Ashkil Dighin
• Re: Lock contention high
  • From: Ashkil Dighin
• Re: Lock contention high
  • From: Ashkil Dighin
• Re: Lock contention high
  • From: Mikhail Zhilin
• Re: Lock contention high
  • From: Laurenz Albe
• Re: Lock contention high
  • From: Peter Geoghegan
• Re: Lock contention high
  • From: Jeremy Schneider
• Re: Lock contention high
  • From: Peter Geoghegan
• Re: Lock contention high
  • From: Paul Friedman
• Re: Lock contention high
  • From: MichaelDBA
• Re: Lock contention high
  • From: Justin Pryzby
• Re: Lock contention high
  • From: Mladen Gogala
• Re: Lock contention high
  • From: Laurenz Albe
• Re: Lock contention high
  • From: Mikhail Zhilin
• Lock contention high
  • From: Ashkil Dighin
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Bruce Momjian
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Laurenz Albe
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Franck Pachot
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Mladen Gogala
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Thomas Kellerer
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Julien Rouhaud
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Bruce Momjian
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Thomas Kellerer
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Bruce Momjian
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Bruce Momjian
• Re: PG 12 slow selects from pg_settings
  • From: Julius Tuskenis
• Re: PG 12 slow selects from pg_settings
  • From: Ranier Vilela
• Re: PG 12 slow selects from pg_settings
  • From: Julius Tuskenis
• Re: PG 12 slow selects from pg_settings
  • From: Ranier Vilela
• PG 12 slow selects from pg_settings
  • From: Julius Tuskenis
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Jeremy Schneider
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Mladen Gogala
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Bruce Momjian
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Jeremy Schneider
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Bruce Momjian
• Re: [EXT] Re: Troubleshooting a long running delete statement
  • From: Corey Huinker
• Re: [EXT] Re: Troubleshooting a long running delete statement
  • From: Maciek Sakrejda
• Re: Troubleshooting a long running delete statement
  • From: Michael Lewis
• Re: [EXT] Re: Troubleshooting a long running delete statement
  • From: Mladen Gogala
• Re: [EXT] Re: Troubleshooting a long running delete statement
  • From: Mladen Gogala
• RE: [EXT] Re: Troubleshooting a long running delete statement
  • From: Dirschel, Steve
• RE: [EXT] Re: Troubleshooting a long running delete statement
  • From: Dirschel, Steve
• Re: Troubleshooting a long running delete statement
  • From: Laurenz Albe
• Re: Troubleshooting a long running delete statement
  • From: Justin Pryzby
• Re: Troubleshooting a long running delete statement
  • From: Mladen Gogala
• Troubleshooting a long running delete statement
  • From: Dirschel, Steve
• Installation of PostgreSQL on fedora zVM
  • From: Manish Lad
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Mladen Gogala
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Tim
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Mladen Gogala
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Peter Geoghegan
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Mladen Gogala
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Ranier Vilela
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Laurenz Albe
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Peter Geoghegan
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Mladen Gogala
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Mladen Gogala
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Peter Geoghegan
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Michaeldba@xxxxxxxxxxx
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Mladen Gogala
• Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Laurenz Albe
• Better, consistent instrumentation for postgreSQL using a similar API as Oracle
  • From: Jeff Holt
• Re: Query going to all paritions
  • From: aditya desai
• Re: Query going to all paritions
  • From: hubert depesz lubaczewski
• Re: Query going to all paritions
  • From: aditya desai
• Re: Query going to all paritions
  • From: Laurenz Albe
• Query going to all paritions
  • From: aditya desai
• How to improve cockroach performance with pgbench?
  • From: Fabien COELHO
• Re: hashjoins, index loops to retrieve pk/ux constrains in pg12
  • From: Arturas Mazeika
• Re: Problem with indices from 10 to 13
  • From: Pavel Stehule
• RE: Problem with indices from 10 to 13
  • From: Daniel Diniz
• Re: Problem with indices from 10 to 13
  • From: Justin Pryzby
• RE: Problem with indices from 10 to 13
  • From: Daniel Diniz
• Re: Problem with indices from 10 to 13
  • From: Tom Lane
• Re: Problem with indices from 10 to 13
  • From: Alan Hodgson
• RE: Problem with indices from 10 to 13
  • From: Daniel Diniz
• RE: Problem with indices from 10 to 13
  • From: Daniel Diniz
• Re: Problem with indices from 10 to 13
  • From: Tom Lane
• Re: Problem with indices from 10 to 13
  • From: Ranier Vilela
• Problem with indices from 10 to 13
  • From: Daniel Diniz
• Re: hashjoins, index loops to retrieve pk/ux constrains in pg12
  • From: Tom Lane
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Partial index on enum type is not being used, type issue?
  • From: Tom Lane
• Partial index on enum type is not being used, type issue?
  • From: Kim Johan Andersson
• Re: hashjoins, index loops to retrieve pk/ux constrains in pg12
  • From: Arturas Mazeika
• 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: tushar
• Re: hashjoins, index loops to retrieve pk/ux constrains in pg12
  • From: Michael Lewis
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Andrew Dunstan
• Re: hashjoins, index loops to retrieve pk/ux constrains in pg12
  • From: Arturas Mazeika
• 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: Andrew Dunstan
• Re: Performance for initial copy when using pg_logical to upgrade Postgres
  • From: Tim
• Re: Performance for initial copy when using pg_logical to upgrade Postgres
  • From: Andrew Dunstan
• Re: Performance for initial copy when using pg_logical to upgrade Postgres
  • From: Westwood, Giles
• Re: Performance for initial copy when using pg_logical to upgrade Postgres
  • From: Justin Pryzby
• Performance for initial copy when using pg_logical to upgrade Postgres
  • From: Westwood, Giles
• Re: hashjoins, index loops to retrieve pk/ux constrains in pg12
  • From: Michael Lewis
• hashjoins, index loops to retrieve pk/ux constrains in pg12
  • From: Arturas Mazeika
• Re: multi-tenant queries select wrong index
  • From: Alexey M Boltenkov
• multi-tenant queries select wrong index
  • From: Kirill
• Re: Query executed during pg_dump leads to excessive memory usage
  • From: Tom Lane
• Re: Query executed during pg_dump leads to excessive memory usage
  • From: Gogala, Mladen
• Re: Query executed during pg_dump leads to excessive memory usage
  • From: Ulf Lohbrügge
• RE: sql execution time in pg_stat_statements
  • From: Michel SALAIS
• Re: Query executed during pg_dump leads to excessive memory usage
  • From: Ranier Vilela
• Query executed during pg_dump leads to excessive memory usage
  • From: Ulf Lohbrügge
• Re: Want function to be called only once in query
  • From: Steve Pritchard
• Re: Want function to be called only once in query
  • From: Jim Mlodgenski
• Want function to be called only once in query
  • From: Steve Pritchard
• Re: Postgres chooses slow query plan from time to time
  • From: Kristjan Mustkivi
• Re: Postgres chooses slow query plan from time to time
  • From: Tom Lane
• Re: Postgres chooses slow query plan from time to time
  • From: Kristjan Mustkivi
• Re: Postgres chooses slow query plan from time to time
  • From: Tom Lane
• Re: Postgres chooses slow query plan from time to time
  • From: Kristjan Mustkivi
• Re: EnterpriseDB
  • From: manish yadav
• Re: Postgres chooses slow query plan from time to time
  • From: Tom Lane
• Re: Postgres chooses slow query plan from time to time
  • From: Kristjan Mustkivi
• Re: EnterpriseDB
  • From: sbob
• Re: Postgres chooses slow query plan from time to time
  • From: Tom Lane
• Re: Postgres chooses slow query plan from time to time
  • From: Kristjan Mustkivi
• Re: Postgres chooses slow query plan from time to time
  • From: Jeff Janes
• Re: Postgres chooses slow query plan from time to time
  • From: Laurenz Albe
• Re: Postgres chooses slow query plan from time to time
  • From: Kristjan Mustkivi
• Re: Postgres chooses slow query plan from time to time
  • From: Kristjan Mustkivi
• EnterpriseDB
  • From: Mladen Gogala
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Andrew Dunstan
• Re: Postgres chooses slow query plan from time to time
  • From: Jeff Janes
• Re: Postgres chooses slow query plan from time to time
  • From: Jeff Janes
• 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: Andrew Dunstan
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Postgres chooses slow query plan from time to time
  • From: Justin Pryzby
• Re: Postgres chooses slow query plan from time to time
  • From: Michael Lewis
• Re: Postgres chooses slow query plan from time to time
  • From: Tomas Vondra
• Postgres chooses slow query plan from time to time
  • From: Kristjan Mustkivi
• Re: sql execution time in pg_stat_statements
  • From: Julien Rouhaud
• Re: sql execution time in pg_stat_statements
  • From: Tom Lane
• RE: sql execution time in pg_stat_statements
  • From: Michel SALAIS
• Re: PostgreSql 9.4 Database connection failure
  • From: Ranier Vilela
• Re: sql execution time in pg_stat_statements
  • From: Julien Rouhaud
• RE: sql execution time in pg_stat_statements
  • From: Michel SALAIS
• sql execution time in pg_stat_statements
  • From: Michel SALAIS
• Re: PostgreSql 9.4 Database connection failure
  • From: Ranier Vilela
• PostgreSql 9.4 Database connection failure
  • From: Lionel Napoleon
• RE: Better performance no-throw conversion?
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Better performance no-throw conversion?
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Better performance no-throw conversion?
  • From: Michael Lewis
• Re: Better performance no-throw conversion?
  • From: Tom Lane
• Re: Better performance no-throw conversion?
  • From: Andrew Dunstan
• Better performance no-throw conversion?
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Foreign table as partition - Non optimal aggregation plan
  • From: Stepan Yankevych
• FDW join vs full join push down
  • From: Marc Olivé
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Andrew Dunstan
• 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: Julien Rouhaud
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Andrew Dunstan
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Julien Rouhaud
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Andrew Dunstan
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Julien Rouhaud
• 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: Andrew Dunstan
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Michel SALAIS
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: pg_restore schema dump to schema with different name
  • From: Nagaraj Raj
• 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 (workarounds)
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4 (workarounds)
  • From: Justin Pryzby
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Pavel Stehule
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Julien Rouhaud
• 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: Ranier Vilela
• 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: Ranier Vilela
• 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: 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: 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: Andrew Dunstan
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Using regexp from table has unpredictable poor performance
  • From: Vitalii Tymchyshyn
• Re: Using regexp from table has unpredictable poor performance
  • From: Jack Christensen
• Re: Using regexp from table has unpredictable poor performance
  • From: Justin Pryzby
• Using regexp from table has unpredictable poor performance
  • From: Jack Christensen
• Re: pg_restore schema dump to schema with different name
  • From: David G. Johnston
• Re: pg_restore schema dump to schema with different name
  • From: Laurenz Albe
• Re: Postgres using the wrong index index
  • From: Matt Dupree
• Re: Postgres using the wrong index index
  • From: Justin Pryzby
• Re: pg_restore schema dump to schema with different name
  • From: Nagaraj Raj
• Re: pg_restore schema dump to schema with different name
  • From: Jean-Christophe Boggio
• Re: pg_restore schema dump to schema with different name
  • From: Laurenz Albe
• pg_restore schema dump to schema with different name
  • From: Nagaraj Raj
• 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: Ranier Vilela
• 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: Ranier Vilela
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Andrew Dunstan
• 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: Andrew Dunstan
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx