pgsql-performance  

Messages by Thread

• • Re: Useless memoize path generated for unique join on primary keys David Rowley
• FATAL: canceling authentication due to timeout aditya desai
• LISTEN NOTIFY sometimes huge delay Peter Eser HEUFT [Germany]
  • Re: LISTEN NOTIFY sometimes huge delay Tom Lane
• Unworkable plan above certain row count André Hänsel
  • Re: Unworkable plan above certain row count Tom Lane
• Fwd: Array of integer indexed nested-loop semi join Mickael van der Beek
  • Re: Array of integer indexed nested-loop semi join Jeff Janes
  • Re: Array of integer indexed nested-loop semi join Mickael van der Beek
  • Re: Array of integer indexed nested-loop semi join Mickael van der Beek
  • Re: Array of integer indexed nested-loop semi join Jeff Janes
  • Re: Array of integer indexed nested-loop semi join Mickael van der Beek
  • Re: Array of integer indexed nested-loop semi join Jeff Janes
  • Re: Array of integer indexed nested-loop semi join Mickael van der Beek
• Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected. Emil Iggland
  • Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected. Tom Lane
  • Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected. Emil Iggland
  • Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected. David Rowley
  • Re: Performance differential when 0 values present vs when 1 values present. Planner return 52k rows when 0 expected. Emil Iggland
• significant jump in sql statement timing for on server vs a remote connection Sbob
  • Re: significant jump in sql statement timing for on server vs a remote connection Justin Pryzby
  • Re: significant jump in sql statement timing for on server vs a remote connection Jeff Janes
  • Re: significant jump in sql statement timing for on server vs a remote connection Sbob
  • Re: significant jump in sql statement timing for on server vs a remote connection Ranier Vilela
• How to find all SQLs executed by a transaction id? Patil, Ravi
• How to find the final transformed query in postgresql Goti
  • Re: How to find the final transformed query in postgresql Tom Lane
  • Re: How to find the final transformed query in postgresql Goti
• Query Planner not taking advantage of HASH PARTITION Benjamin Tingle
  • Re: Query Planner not taking advantage of HASH PARTITION Tom Lane
  • Re: Query Planner not taking advantage of HASH PARTITION Benjamin Tingle
  • Re: Query Planner not taking advantage of HASH PARTITION Tom Lane
  • Re: Query Planner not taking advantage of HASH PARTITION Alvaro Herrera
  • Re: Query Planner not taking advantage of HASH PARTITION Benjamin Tingle
  • Re: Query Planner not taking advantage of HASH PARTITION Justin Pryzby
• Query Tunning related to function Kumar, Mukesh
  • Re: Query Tunning related to function Ranier Vilela
  • RE: Query Tunning related to function Kumar, Mukesh
  • RE: Query Tunning related to function Michel SALAIS
  • RE: Query Tunning related to function Kumar, Mukesh
  • Re: Query Tunning related to function Bhupendra Babu
  • RE: Query Tunning related to function Kumar, Mukesh
  • RE: Query Tunning related to function Kumar, Mukesh
  • Re: Query Tunning related to function David G. Johnston
  • Re: Query Tunning related to function Justin Pryzby
• SQL performance issue after migration from Oracle to Aurora postgres Goti
  • Re: SQL performance issue after migration from Oracle to Aurora postgres Andrew Dunstan
• Performance for SQL queries on Azure PostgreSQL PaaS instance Kumar, Mukesh
  • Re: Performance for SQL queries on Azure PostgreSQL PaaS instance Frits Jalvingh
  • Re: Performance for SQL queries on Azure PostgreSQL PaaS instance Tomas Vondra
  • Re: Performance for SQL queries on Azure PostgreSQL PaaS instance Laurenz Albe
  • RE: Performance for SQL queries on Azure PostgreSQL PaaS instance Kumar, Mukesh
  • Re: Performance for SQL queries on Azure PostgreSQL PaaS instance andrew cooke
  • Re: Performance for SQL queries on Azure PostgreSQL PaaS instance overland
• Slow Planning Times Saurabh Sehgal
  • Re: Slow Planning Times Saurabh Sehgal
  • Re: Slow Planning Times David G. Johnston
  • Re: Slow Planning Times Saurabh Sehgal
  • Re: Slow Planning Times Tom Lane
  • Re: Slow Planning Times Saurabh Sehgal
• Postgresql TPS Bottleneck wakandavision
  • Re: Postgresql TPS Bottleneck Guillaume Cottenceau
  • Re: Postgresql TPS Bottleneck MichaelDBA
  • Re: Postgresql TPS Bottleneck Tomas Vondra
  • Re: Postgresql TPS Bottleneck wakandavision
  • Re: Postgresql TPS Bottleneck Jeff Janes
  • Re: Postgresql TPS Bottleneck wakandavision
  • Re: Postgresql TPS Bottleneck Benedict Holland
  • Re: Postgresql TPS Bottleneck Mladen Gogala
• HIGH IO and Less CPU utilization Rambabu g
  • Re: HIGH IO and Less CPU utilization Justin Pryzby
  • Re: HIGH IO and Less CPU utilization Rambabu g
  • Re: HIGH IO and Less CPU utilization Justin Pryzby
  • Re: HIGH IO and Less CPU utilization Rambabu g
  • Re: HIGH IO and Less CPU utilization Justin Pryzby
  • Re: HIGH IO and Less CPU utilization Rambabu g
  • Re: HIGH IO and Less CPU utilization Mladen Gogala
• View taking time to show records Kumar, Mukesh
  • Re: View taking time to show records aditya desai
  • Re: View taking time to show records hubert depesz lubaczewski
  • Re: View taking time to show records Laurenz Albe
  • RE: View taking time to show records Kumar, Mukesh
  • Re: View taking time to show records Laurenz Albe
• Performance issue post upgrade on Version 13 - Incorrect Estimation Cost choosing Hash Aggregate-Nested Left Loop Join Prajna Shetty
  • Re: Performance issue post upgrade on Version 13 - Incorrect Estimation Cost choosing Hash Aggregate-Nested Left Loop Join Justin Pryzby
  • Re: Performance issue post upgrade on Version 13 - Incorrect Estimation Cost choosing Hash Aggregate-Nested Left Loop Join Tomas Vondra
• High process memory consumption when running sort Shai Shapira
  • Re: High process memory consumption when running sort Justin Pryzby
  • RE: High process memory consumption when running sort Shai Shapira
• Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view. Lars Aksel Opsahl
  • Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view. Lars Aksel Opsahl
  • Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view. Justin Pryzby
  • Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view. Lars Aksel Opsahl
  • Re: Using system tables directly takes many hours, using temp tables with no indexes takes a few seconds for geometry_columns view. Lars Aksel Opsahl
• Explain analyse with track_io_timing Jayadevan M
  • Re: Explain analyse with track_io_timing Julien Rouhaud
  • Re: Explain analyse with track_io_timing Jayadevan M
• Optimal configuration for server Luiz Felipph
  • Re: Optimal configuration for server Ranier Vilela
  • Re: Optimal configuration for server Luiz Felipph
  • Re: Optimal configuration for server Ranier Vilela
  • Re: Optimal configuration for server Tomas Vondra
  • Re: Optimal configuration for server Luiz Felipph
  • Re: Optimal configuration for server Ranier Vilela
  • RE: Optimal configuration for server Michel SALAIS
  • Re: Optimal configuration for server Justin Pryzby
  • Re: Optimal configuration for server Moises Lopez
• XA transactions much slower on 14.2 than on 13.5 Mladen Gogala
  • Re: XA transactions much slower on 14.2 than on 13.5 Tom Lane
• Any way to speed up INSERT INTO aditya desai
  • Re: Any way to speed up INSERT INTO Bruce Momjian
  • Re: Any way to speed up INSERT INTO aditya desai
  • Re: Any way to speed up INSERT INTO Imre Samu
  • Re: Any way to speed up INSERT INTO Tom Lane
  • Re: Any way to speed up INSERT INTO Bruce Momjian
  • Re: Any way to speed up INSERT INTO aditya desai
  • Re: Any way to speed up INSERT INTO Andres Freund
  • RES: Any way to speed up INSERT INTO Edson Richter
  • Re: Any way to speed up INSERT INTO aditya desai
  • Re: Any way to speed up INSERT INTO Bruce Momjian
  • Re: Any way to speed up INSERT INTO aditya desai
• OOM killer while pg_restore Marc Rechté
  • Re: OOM killer while pg_restore Ranier Vilela
  • Re: OOM killer while pg_restore Marc Rechté
  • Re: OOM killer while pg_restore Ranier Vilela
  • Re: OOM killer while pg_restore Justin Pryzby
  • Re: OOM killer while pg_restore Tom Lane
  • Re: OOM killer while pg_restore Marc Rechté
  • Re: OOM killer while pg_restore Tom Lane
  • Re: OOM killer while pg_restore Marc Rechté
  • Re: OOM killer while pg_restore Ranier Vilela
• Simple task with partitioning which I can't realize Andrew Zakharov
  • Re: Simple task with partitioning which I can't realize David G. Johnston
  • RE: Simple task with partitioning which I can't realize Andrew Zakharov
  • Re: Simple task with partitioning which I can't realize David G. Johnston
  • Re: Simple task with partitioning which I can't realize Mladen Gogala
  • Re: Simple task with partitioning which I can't realize Marc Millas
  • RE: Simple task with partitioning which I can't realize Andrew Zakharov
  • Re: Simple task with partitioning which I can't realize Marc Millas
  • RE: Simple task with partitioning which I can't realize Andrew Zakharov
  • RE: Simple task with partitioning which I can't realize Michel SALAIS
  • Re: Simple task with partitioning which I can't realize Geri Wright
• RLS not using index scan but seq scan when condition gets a bit complicated Charles Huang
• Never Ending query in PostgreSQL Kumar, Mukesh
  • Re: Never Ending query in PostgreSQL Julien Rouhaud
  • Re: Never Ending query in PostgreSQL Jeff Janes
  • Re: Never Ending query in PostgreSQL Mladen Gogala
  • Re: Never Ending query in PostgreSQL Tomas Vondra
  • RE: Never Ending query in PostgreSQL Kumar, Mukesh
  • Re: Never Ending query in PostgreSQL Tomas Vondra
  • Re: Never Ending query in PostgreSQL Mladen Gogala
• slow query to improve performace Ayub Khan
  • Re: slow query to improve performace Justin Pryzby
  • Re: slow query to improve performace Jeff Janes
• Advice needed: query performance deteriorates by 2000% within 1 minute Peter Adlersburg
  • Re: Advice needed: query performance deteriorates by 2000% within 1 minute Michael Lewis
  • Re: Advice needed: query performance deteriorates by 2000% within 1 minute Tom Lane
  • Re: Advice needed: query performance deteriorates by 2000% within 1 minute Peter Adlersburg
  • Re: Advice needed: query performance deteriorates by 2000% within 1 minute Michael Lewis
  • Re: Advice needed: query performance deteriorates by 2000% within 1 minute Michael Lewis
• Slow plan choice with prepared query Mark Saward
  • Re: Slow plan choice with prepared query MichaelDBA
  • Re: Slow plan choice with prepared query MichaelDBA
• Re: Slow Running Queries in Azure PostgreSQL Justin Pryzby
  • RE: Slow Running Queries in Azure PostgreSQL Kumar, Mukesh
• Query chooses Bad Index Path Valli Annamalai
  • Re: Query chooses Bad Index Path Tomas Vondra
• Query choosing Bad Index Path (ASC/DESC ordering). Valli Annamalai
  • Re: Query choosing Bad Index Path (ASC/DESC ordering). Mind Body Nature
• slow "select count(*) from information_schema.tables;" in some cases Lars Aksel Opsahl
  • Re: slow "select count(*) from information_schema.tables;" in some cases Justin Pryzby
  • Re: slow "select count(*) from information_schema.tables;" in some cases Lars Aksel Opsahl
  • Re: slow "select count(*) from information_schema.tables;" in some cases Imre Samu
  • Re: slow "select count(*) from information_schema.tables;" in some cases Vijaykumar Jain
  • Re: slow "select count(*) from information_schema.tables;" in some cases Lars Aksel Opsahl
  • Re: slow "select count(*) from information_schema.tables;" in some cases Tom Lane
  • Re: slow "select count(*) from information_schema.tables;" in some cases Lars Aksel Opsahl
• Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Laurenz Albe
  • Re: Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Pavel Stehule
  • Re: Terribly slow query with very good plan? Nick Cleaton
  • Re: Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Nick Cleaton
  • Re: Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Nick Cleaton
  • Re: Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Nick Cleaton
  • Re: Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Ninad Shah
  • Re: Terribly slow query with very good plan? Nick Cleaton
  • Re: Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Nick Cleaton
  • Re: Terribly slow query with very good plan? Les
  • Re: Terribly slow query with very good plan? Thomas Kellerer
  • Re: Terribly slow query with very good plan? Vijaykumar Jain
• Query runs slower as prepared statement - identical execution plans Thomas Kellerer

• Earlier messages
• Later messages