Postgres Performance Date Index

• Thread Index

• Re: Replication lag due to lagging restart_lsn
  • From: milist ujang
• Re: Is there any tool which will help me run and explain analyze about 150 queries?
  • From: kunwar singh
• Re: Is there any tool which will help me run and explain analyze about 150 queries?
  • From: kyle Hailey
• RE: Query unable to utilize index without typecast to fixed length character
  • From: msalais
• Re: Is there any tool which will help me run and explain analyze about 150 queries?
  • From: Jerry Sievers
• Re: Is there any tool which will help me run and explain analyze about 150 queries?
  • From: kunwar singh
• Re: Is there any tool which will help me run and explain analyze about 150 queries?
  • From: kyle Hailey
• Re: Is there any tool which will help me run and explain analyze about 150 queries?
  • From: Achilleas Mantzios
• Is there any tool which will help me run and explain analyze about 150 queries?
  • From: kunwar singh
• Re: Query unable to utilize index without typecast to fixed length character
  • From: ahi
• Re: Query unable to utilize index without typecast to fixed length character
  • From: Tom Lane
• Query unable to utilize index without typecast to fixed length character
  • From: ahi
• Re: Why are commits consuming most of the database time?
  • From: Tim Slechta
• Re: Why are commits consuming most of the database time?
  • From: Tom Lane
• Why are commits consuming most of the database time?
  • From: Tim Slechta
• Re:Explain plan shows fewer shared blocks when index+table compared to index alone?
  • From: Sergei Kornilov
• Explain plan shows fewer shared blocks when index+table compared to index alone?
  • From: Amin Jaffer
• Re: multicolumn partitioning help
  • From: David Rowley
• Re: multicolumn partitioning help
  • From: David Rowley
• Re: multicolumn partitioning help
  • From: James Robertson
• Re: multicolumn partitioning help
  • From: Laurenz Albe
• Re: multicolumn partitioning help
  • From: Laurenz Albe
• Re: multicolumn partitioning help
  • From: Justin Pryzby
• multicolumn partitioning help
  • From: James Robertson
• Re: Huge Tables
  • From: André Rodrigues
• Re: Huge Tables
  • From: Rick Otten
• Re: Planner choosing nested loop in place of Hashjoin
  • From: Jeff Janes
• Huge Tables
  • From: André Rodrigues
• Re: INSERT statement going in IPC Wait_event
  • From: Samed YILDIRIM
• Re: Planner choosing nested loop in place of Hashjoin
  • From: Samed YILDIRIM
• Planner choosing nested loop in place of Hashjoin
  • From: Praneel Devisetty
• Re: INSERT statement going in IPC Wait_event
  • From: Andrew Dunstan
• INSERT statement going in IPC Wait_event
  • From: aditya desai
• Re: BRIN index worse than sequential scan for large search set
  • From: Tomas Vondra
• Re: BRIN index worse than sequential scan for large search set
  • From: Justin Pryzby
• Re: BRIN index worse than sequential scan for large search set
  • From: Mickael van der Beek
• Re: BRIN index worse than sequential scan for large search set
  • From: Justin Pryzby
• BRIN index worse than sequential scan for large search set
  • From: Mickael van der Beek
• Re: Window Functions & Table Partitions
  • From: David Rowley
• Re: Connection forcibly closed remote server error.
  • From: Ranier Vilela
• Re: Connection forcibly closed remote server error.
  • From: aditya desai
• Re: Connection forcibly closed remote server error.
  • From: Jeff Janes
• Re: Connection forcibly closed remote server error.
  • From: Tom Lane
• Re: Connection forcibly closed remote server error.
  • From: aditya desai
• Connection forcibly closed remote server error.
  • From: aditya desai
• Re: For loop execution times in PostgreSQL 12 vs 15
  • From: Pavel Stehule
• Re: Performance of UPDATE operation
  • From: Jeff Janes
• Re: For loop execution times in PostgreSQL 12 vs 15
  • From: Andres Freund
• Re: Performance of UPDATE operation
  • From: Oluwatobi Ogunsola
• Re: Performance of UPDATE operation
  • From: Laurenz Albe
• Performance of UPDATE operation
  • From: Mkrtchyan, Tigran
• Re: For loop execution times in PostgreSQL 12 vs 15
  • From: Pavel Stehule
• Re: For loop execution times in PostgreSQL 12 vs 15
  • From: Pavel Stehule
• For loop execution times in PostgreSQL 12 vs 15
  • From: Adithya Kumaranchath
• Re: Domain check taking place unnecessarily?
  • From: Mark Hills
• Re: Window Functions & Table Partitions
  • From: Benjamin Tingle
• Re: Domain check taking place unnecessarily?
  • From: Tom Lane
• Re: Domain check taking place unnecessarily?
  • From: Mark Hills
• Re: Domain check taking place unnecessarily?
  • From: Mark Hills
• Re: max_wal_senders
  • From: Andres Freund
• Re: max_wal_senders
  • From: Laurenz Albe
• max_wal_senders
  • From: Rick Otten
• Re: Window Functions & Table Partitions
  • From: David Rowley
• Window Functions & Table Partitions
  • From: Benjamin Tingle
• Re: Domain check taking place unnecessarily?
  • From: Laurenz Albe
• Re: Domain check taking place unnecessarily?
  • From: David G. Johnston
• Domain check taking place unnecessarily?
  • From: Mark Hills
• Routing & Concurrency with trigger functions
  • From: chanukya SDS
• Re: Database Stalls
  • From: Craig Jackson
• Re: Getting an index scan to be a parallel index scan
  • From: Alex Kaiser
• Re: Getting an index scan to be a parallel index scan
  • From: David Rowley
• Re: Getting an index scan to be a parallel index scan
  • From: Thomas Munro
• Re: Getting an index scan to be a parallel index scan
  • From: Alex Kaiser
• Re: Getting an index scan to be a parallel index scan
  • From: Thomas Munro
• Re: Getting an index scan to be a parallel index scan
  • From: Justin Pryzby
• Re: Getting an index scan to be a parallel index scan
  • From: Alex Kaiser
• Re: Getting an index scan to be a parallel index scan
  • From: David Rowley
• Re: Getting an index scan to be a parallel index scan
  • From: Ranier Vilela
• Getting an index scan to be a parallel index scan
  • From: Alex Kaiser
• Fwd: Database Stalls
  • From: Rick Otten
• Re: Database Stalls
  • From: Mok
• Re: Database Stalls
  • From: Shiv Iyer
• Re: Database Stalls
  • From: José Arthur Benetasso Villanova
• Re: Database Stalls
  • From: Justin Pryzby
• Database Stalls
  • From: Mok
• Re: LIKE CLAUSE on VIEWS
  • From: Jeff Janes
• Re: LIKE CLAUSE on VIEWS
  • From: Rick Otten
• Re: LIKE CLAUSE on VIEWS
  • From: Samed YILDIRIM
• LIKE CLAUSE on VIEWS
  • From: aditya desai
• Re: ALTER STATEMENT getting blocked
  • From: aditya desai
• Re: ALTER STATEMENT getting blocked
  • From: MichaelDBA
• Re: ALTER STATEMENT getting blocked
  • From: Tom Lane
• ALTER STATEMENT getting blocked
  • From: aditya desai
• Re: change the default value of enable_bitmapscan to off
  • From: Tom Lane
• Re: change the default value of enable_bitmapscan to off
  • From: Pavel Stehule
• change the default value of enable_bitmapscan to off
  • From: hehaochen@xxxxxxxxxxx
• Re: Advice on best way to store a large amount of data in postgresql
  • From: spiral
• Re: Advice on best way to store a large amount of data in postgresql
  • From: Samed YILDIRIM
• Re: Advice on best way to store a large amount of data in postgresql
  • From: Justin Pryzby
• Re: Advice on best way to store a large amount of data in postgresql
  • From: Michaeldba@xxxxxxxxxxx
• Advice on best way to store a large amount of data in postgresql
  • From: spiral
• Max write throughput for single COPY
  • From: Joe Wildish
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: Maxim Boguk
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: MichaelDBA
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: MichaelDBA
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: Maxim Boguk
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: Maxim Boguk
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: MichaelDBA
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: Maxim Boguk
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: MichaelDBA
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: Maxim Boguk
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: MichaelDBA
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: Maxim Boguk
• Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: Justin Pryzby
• How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
  • From: Maxim Boguk
• Re: When you really want to force a certain join type?
  • From: Tom Lane
• Re: When you really want to force a certain join type?
  • From: Gunther Schadow
• Re: When you really want to force a certain join type?
  • From: Justin Pryzby
• When you really want to force a certain join type?
  • From: Gunther Schadow
• Re: Fwd: temp_file_limit?
  • From: Frits Jalvingh
• Re: Fwd: temp_file_limit?
  • From: Justin Pryzby
• Re: Fwd: temp_file_limit?
  • From: Frits Jalvingh
• Re: Fwd: temp_file_limit?
  • From: Frits Jalvingh
• Re: Fwd: temp_file_limit?
  • From: Thomas Munro
• Re: Fwd: temp_file_limit?
  • From: Frits Jalvingh
• Re: Fwd: temp_file_limit?
  • From: Justin Pryzby
• Re: Fwd: temp_file_limit?
  • From: Ranier Vilela
• Re: Fwd: temp_file_limit?
  • From: Frits Jalvingh
• Re: Fwd: temp_file_limit?
  • From: Justin Pryzby
• Re: Fwd: temp_file_limit?
  • From: Frits Jalvingh
• Re: Fwd: temp_file_limit?
  • From: Justin Pryzby
• Re: Fwd: temp_file_limit?
  • From: Frits Jalvingh
• RE: Postgres12 looking for possible HashAggregate issue workarounds?
  • From: João Paulo Luís
• Re: Fwd: temp_file_limit?
  • From: Frits Jalvingh
• Re: Fwd: temp_file_limit?
  • From: Ranier Vilela
• Re: Fwd: temp_file_limit?
  • From: Frits Jalvingh
• Re: Fwd: temp_file_limit?
  • From: Ranier Vilela
• Re: Fwd: temp_file_limit?
  • From: Frits Jalvingh
• Re: Fwd: temp_file_limit?
  • From: Thomas Munro
• Re: Fwd: temp_file_limit?
  • From: Thomas Munro
• Re: Fwd: temp_file_limit?
  • From: Justin Pryzby
• Re: Fwd: temp_file_limit?
  • From: Tom Lane
• Fwd: temp_file_limit?
  • From: Frits Jalvingh
• Re: temp_file_limit?
  • From: Justin Pryzby
• temp_file_limit?
  • From: Frits Jalvingh
• Re: Postgres12 looking for possible HashAggregate issue workarounds?
  • From: David Rowley
• RE: Postgres12 looking for possible HashAggregate issue workarounds?
  • From: João Paulo Luís
• Re: JSON down performacen when id:1
  • From: Render Comunicacion S.L.
• Re: Postgres12 looking for possible HashAggregate issue workarounds?
  • From: Justin Pryzby
• Postgres12 looking for possible HashAggregate issue workarounds?
  • From: João Paulo Luís
• Re: JSON down performacen when id:1
  • From: Tom Lane
• JSON down performacen when id:1
  • From: Render Comunicacion S.L.
• RE: DML sql execution time slow down PGv14 compared with PGv13
  • From: James Pang (chaolpan)
• Re: time sorted UUIDs
  • From: Adrien Nayrat
• Re: time sorted UUIDs
  • From: Laurenz Albe
• time sorted UUIDs
  • From: Tim Jones
• RE: DML sql execution time slow down PGv14 compared with PGv13
  • From: James Pang (chaolpan)
• Re: DML sql execution time slow down PGv14 compared with PGv13
  • From: David Rowley
• RE: DML sql execution time slow down PGv14 compared with PGv13
  • From: James Pang (chaolpan)
• RE: DML sql execution time slow down PGv14 compared with PGv13
  • From: James Pang (chaolpan)
• Re: DML sql execution time slow down PGv14 compared with PGv13
  • From: Samed YILDIRIM
• DML sql execution time slow down PGv14 compared with PGv13
  • From: James Pang (chaolpan)
• DML sql execution time slow down PGv14 compared with PGv13
  • From: James Pang (chaolpan)
• Re: creating hash indexes
  • From: Peter Geoghegan
• creating hash indexes
  • From: Rick Otten
• Re: Increased iowait and blk_read_time with higher shared_buffers
  • From: Jordan Hurwich
• Re: Increased iowait and blk_read_time with higher shared_buffers
  • From: Samed YILDIRIM
• Re: Increased iowait and blk_read_time with higher shared_buffers
  • From: Jordan Hurwich
• Re: Increased iowait and blk_read_time with higher shared_buffers
  • From: Tom Lane
• Re: Increased iowait and blk_read_time with higher shared_buffers
  • From: Jordan Hurwich
• Re: Increased iowait and blk_read_time with higher shared_buffers
  • From: Samed YILDIRIM
• Increased iowait and blk_read_time with higher shared_buffers
  • From: Jordan Hurwich
• wrong rows and cost estimation when generic plan
  • From: James Pang
• Re: wrong rows and cost estimation when generic plan
  • From: David Rowley
• RE: wrong rows and cost estimation when generic plan
  • From: James Pang (chaolpan)
• Re: wrong rows and cost estimation when generic plan
  • From: David Rowley
• RE: wrong rows and cost estimation when generic plan
  • From: James Pang (chaolpan)
• RE: wrong rows and cost estimation when generic plan
  • From: James Pang (chaolpan)
• Re: Catching up with performance & PostgreSQL 15
  • From: Jeff Janes
• sort performance better with little memory than big memory
  • From: yang zhao
• Re: Odd Choice of seq scan
  • From: Chris Hoover
• Re: Odd Choice of seq scan
  • From: Paul McGarry
• Re: Odd Choice of seq scan
  • From: Tom Lane
• Re: Odd Choice of seq scan
  • From: Ronuk Raval
• Re: Odd Choice of seq scan
  • From: Justin Pryzby
• Odd Choice of seq scan
  • From: Paul McGarry
• Re: Catching up with performance & PostgreSQL 15
  • From: Andrew Dunstan
• Re: Geometric types row estimation
  • From: Igor ALBUQUERQUE SILVA
• Re: Geometric types row estimation
  • From: Tom Lane
• Re: Geometric types row estimation
  • From: Igor ALBUQUERQUE SILVA
• Re: Geometric types row estimation
  • From: Tom Lane
• Re: Geometric types row estimation
  • From: Igor ALBUQUERQUE SILVA
• Geometric types row estimation
  • From: Igor ALBUQUERQUE SILVA
• Re: Catching up with performance & PostgreSQL 15
  • From: Tom Lane
• Re: Catching up with performance & PostgreSQL 15
  • From: Andres Freund
• Re: Catching up with performance & PostgreSQL 15
  • From: Andrew Dunstan
• Re: Catching up with performance & PostgreSQL 15
  • From: Mladen Gogala
• Re: Catching up with performance & PostgreSQL 15
  • From: David Rowley
• Re: Catching up with performance & PostgreSQL 15
  • From: Alvaro Herrera
• Re: Catching up with performance & PostgreSQL 15
  • From: Tom Lane
• Re: Catching up with performance & PostgreSQL 15
  • From: Mladen Gogala
• Re: Catching up with performance & PostgreSQL 15
  • From: Mladen Gogala
• Re: Catching up with performance & PostgreSQL 15
  • From: Alvaro Herrera
• Re: Catching up with performance & PostgreSQL 15
  • From: Alvaro Herrera
• Re: Catching up with performance & PostgreSQL 15
  • From: Josh Berkus
• Re: Catching up with performance & PostgreSQL 15
  • From: Mladen Gogala
• Re: Catching up with performance & PostgreSQL 15
  • From: Justin Pryzby
• Catching up with performance & PostgreSQL 15
  • From: Josh Berkus
• Need suggestion to set-up RDS alerts on GP3 volumes
  • From: Sengottaiyan T
• Re: why choosing an hash index instead of the btree version even if the cost is lower?
  • From: Luca Ferrari
• Re: why choosing an hash index instead of the btree version even if the cost is lower?
  • From: Luca Ferrari
• Re: why choosing an hash index instead of the btree version even if the cost is lower?
  • From: Tom Lane
• Re: why choosing an hash index instead of the btree version even if the cost is lower?
  • From: Tomas Vondra
• why choosing an hash index instead of the btree version even if the cost is lower?
  • From: Luca Ferrari
• Re: When can joins be avoided?
  • From: Tom Lane
• When can joins be avoided?
  • From: Stefan Fehrenbach
• Help needed with perf tests on subtransaction overflow
  • From: Simon Riggs
• Re: =ANY(ARRAY) vs =ANY(ARRAY(expr)) performance
  • From: Guillaume Cottenceau
• Re: =ANY(ARRAY) vs =ANY(ARRAY(expr)) performance
  • From: Rick Otten
• Re: =ANY(ARRAY) vs =ANY(ARRAY(expr)) performance
  • From: Ramdip Gill
• =ANY(ARRAY) vs =ANY(ARRAY(expr)) performance
  • From: Ramdip Gill
• Re: ogr2ogr slow sql when checking system tables for column info and so on.
  • From: Lars Aksel Opsahl
• Re: ogr2ogr slow sql when checking system tables for column info and so on.
  • From: Julien Rouhaud
• Re: ogr2ogr slow sql when checking system tables for column info and so on.
  • From: Lars Aksel Opsahl
• Re: ogr2ogr slow sql when checking system tables for column info and so on.
  • From: Julien Rouhaud
• ogr2ogr slow sql when checking system tables for column info and so on.
  • From: Lars Aksel Opsahl
• Explain returns different number of rows
  • From: Vince McMahon
• Re: Identify root-cause for intermittent spikes
  • From: hubert depesz lubaczewski
• Re: Identify root-cause for intermittent spikes
  • From: Julien Rouhaud
• Re: Identify root-cause for intermittent spikes
  • From: Sengottaiyan T
• Re: Identify root-cause for intermittent spikes
  • From: hubert depesz lubaczewski
• Re: Identify root-cause for intermittent spikes
  • From: Sengottaiyan T
• Re: Identify root-cause for intermittent spikes
  • From: Sengottaiyan T
• Re: Identify root-cause for intermittent spikes
  • From: SAMEER KUMAR
• Re: Identify root-cause for intermittent spikes
  • From: Rick Otten
• Re: Identify root-cause for intermittent spikes
  • From: MichaelDBA
• Identify root-cause for intermittent spikes
  • From: Sengottaiyan T
• Re: Milions of views - performance, stability
  • From: Laurenz Albe
• Milions of views - performance, stability
  • From: Hubert Rutkowski
• Re: Query is sometimes fast and sometimes slow: what could be the reason?
  • From: Justin Pryzby
• Query is sometimes fast and sometimes slow: what could be the reason?
  • From: tiaswin
• Faster more low-level methods of having hot standby / secondary read-only servers?
  • From: Gunther Schadow
• RE: Postgresql JDBC process consumes more memory with partition tables update delete
  • From: James Pang (chaolpan)
• RE: Postgresql JDBC process consumes more memory than psql client
  • From: James Pang (chaolpan)
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: bruno da silva
• Re: Postgresql JDBC process consumes more memory than psql client
  • From: Justin Pryzby
• RE: Postgresql JDBC process consumes more memory than psql client
  • From: James Pang (chaolpan)
• Re: Postgresql JDBC process consumes more memory than psql client
  • From: Justin Pryzby
• RE: Postgresql JDBC process consumes more memory than psql client
  • From: James Pang (chaolpan)
• Re: Postgresql JDBC process consumes more memory than psql client
  • From: Justin Pryzby
• Postgresql JDBC process consumes more memory than psql client
  • From: James Pang (chaolpan)
• Re: Select on partitioned table is very slow
  • From: Jose Osinde
• Re: Select on partitioned table is very slow
  • From: Ranier Vilela
• Re: Select on partitioned table is very slow
  • From: Jose Osinde
• Re: Select on partitioned table is very slow
  • From: Laurenz Albe
• Re: Select on partitioned table is very slow
  • From: hubert depesz lubaczewski
• Select on partitioned table is very slow
  • From: Jose Osinde
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Thomas Munro
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Thomas Munro
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Thomas Munro
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Junwang Zhao
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Junwang Zhao
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Thomas Munro
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Kevin McKibbin
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Thomas Munro
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Thomas Munro
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Thomas Munro
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Andres Freund
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Thomas Munro
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Andrew Dunstan
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Andrew Dunstan
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Kevin McKibbin
• Re: pgbench: could not connect to server: Resource temporarily unavailable
  • From: Tom Lane
• pgbench: could not connect to server: Resource temporarily unavailable
  • From: Kevin McKibbin
• Re: to_jsonb performance on array aggregated correlated subqueries
  • From: Rick Otten
• Re: to_jsonb performance on array aggregated correlated subqueries
  • From: Nico Heller
• Re: to_jsonb performance on array aggregated correlated subqueries
  • From: Nico Heller
• Re: to_jsonb performance on array aggregated correlated subqueries
  • From: Andres Freund
• Re: to_jsonb performance on array aggregated correlated subqueries
  • From: Justin Pryzby
• Re: to_jsonb performance on array aggregated correlated subqueries
  • From: Nico Heller
• Re: to_jsonb performance on array aggregated correlated subqueries
  • From: Nico Heller
• Re: to_jsonb performance on array aggregated correlated subqueries
  • From: Justin Pryzby
• to_jsonb performance on array aggregated correlated subqueries
  • From: Nico Heller
• Re: Postgresql 14 partitioning advice
  • From: Justin Pryzby
• Re: Postgresql 14 partitioning advice
  • From: Slava Mudry
• Re: pg_wal filling up while running huge updates
  • From: Justin Pryzby
• Re: pg_wal filling up while running huge updates
  • From: Don Seiler
• pg_wal filling up while running huge updates
  • From: aditya desai
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: Tom Lane
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: bruno da silva
• Re: Postgresql 13 partitioning advice
  • From: Ameya Bidwalkar
• Re: PgSQL 14 - Logical Rep - Single table multiple publications?
  • From: Rory Campbell-Lange
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: Tom Lane
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: Tom Lane
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: bruno da silva
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: bruno da silva
• Re: PgSQL 14 - Logical Rep - Single table multiple publications?
  • From: Robert Blayzor
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: Tom Lane
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: bruno da silva
• Re: PgSQL 14 - Logical Rep - Single table multiple publications?
  • From: Rory Campbell-Lange
• PgSQL 14 - Logical Rep - Single table multiple publications?
  • From: Robert Blayzor
• Re: Postgresql 14 partitioning advice
  • From: Rick Otten
• Re: Postgresql 13 partitioning advice
  • From: David Rowley
• Postgresql 13 partitioning advice
  • From: Ameya Bidwalkar
• Re: Postgresql 14 partitioning advice
  • From: Rick Otten
• Re: Postgresql 14 partitioning advice
  • From: Nathan Ward
• Re: Postgresql 14 partitioning advice
  • From: Rick Otten
• Re: alter table xxx set unlogged take long time
  • From: Joe Conway
• RE: alter table xxx set unlogged take long time
  • From: James Pang (chaolpan)
• Re: alter table xxx set unlogged take long time
  • From: Kyotaro Horiguchi
• Re: Postgresql 14 partitioning advice
  • From: Jeff Janes
• Re: alter table xxx set unlogged take long time
  • From: Joe Conway
• Re: alter table xxx set unlogged take long time
  • From: Tom Lane
• Re: alter table xxx set unlogged take long time
  • From: Joe Conway
• Re: Postgresql 14 partitioning advice
  • From: Justin Pryzby
• Postgresql 14 partitioning advice
  • From: Rick Otten
• Re: alter table xxx set unlogged take long time
  • From: David G. Johnston
• RE: alter table xxx set unlogged take long time
  • From: James Pang (chaolpan)
• Re: alter table xxx set unlogged take long time
  • From: Jim Mlodgenski
• RE: alter table xxx set unlogged take long time
  • From: James Pang (chaolpan)
• Re: alter table xxx set unlogged take long time
  • From: Tom Lane
• RE: alter table xxx set unlogged take long time
  • From: James Pang (chaolpan)
• Re: alter table xxx set unlogged take long time
  • From: Jim Mlodgenski
• alter table xxx set unlogged take long time
  • From: James Pang (chaolpan)
• Re: data consolidation: logical replication design considerations
  • From: Rory Campbell-Lange
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: bruno da silva
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: bruno da silva
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: Justin Pryzby
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: Andrew Dunstan
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: bruno da silva
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: bruno da silva
• Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: Justin Pryzby
• PostgresSQL 9.5.21 very slow to connect and perform basic queries
  • From: bruno da silva
• Re: data consolidation: logical replication design considerations
  • From: Rory Campbell-Lange
• Re: data consolidation: logical replication design considerations
  • From: Rick Otten
• data consolidation: logical replication design considerations
  • From: Rory Campbell-Lange
• Re: Occasional performance issue after changing table partitions
  • From: Justin Pryzby
• Re: Occasional performance issue after changing table partitions
  • From: Nathan Ward
• Re: Oracle_FDW table performance issue
  • From: aditya desai
• Re: Oracle_FDW table performance issue
  • From: Laurenz Albe
• Re: Oracle_FDW table performance issue
  • From: aditya desai
• Re: Oracle_FDW table performance issue
  • From: Justin Pryzby
• Oracle_FDW table performance issue
  • From: aditya desai
• functionality difference-performance postgreSQLv14-GCC-llvm-clang
  • From: arjun shetty
• Re: Occasional performance issue after changing table partitions
  • From: Nathan Ward
• Re: Occasional performance issue after changing table partitions
  • From: Justin Pryzby
• Re: Occasional performance issue after changing table partitions
  • From: Nathan Ward
• Re: Occasional performance issue after changing table partitions
  • From: Justin Pryzby
• Occasional performance issue after changing table partitions
  • From: Nathan Ward
• RE: partition pruning only works for select but update
  • From: James Pang (chaolpan)
• Re: partition pruning only works for select but update
  • From: Tom Lane
• Re: partition pruning only works for select but update
  • From: Justin Pryzby
• RE: partition pruning only works for select but update
  • From: James Pang (chaolpan)
• Re: Fluctuating performance of updates on small table with trigger
  • From: Justin Pryzby
• Fluctuating performance of updates on small table with trigger
  • From: Mikkel Lauritsen
• RE: partition pruning only works for select but update
  • From: James Pang (chaolpan)
• Re: partition pruning only works for select but update
  • From: Tom Lane
• partition pruning only works for select but update
  • From: James Pang (chaolpan)
• Re: reindex option for tuning load large data
  • From: I. V.
• RE: reindex option for tuning load large data
  • From: James Pang (chaolpan)
• Re: reindex option for tuning load large data
  • From: Jeff Janes
• RE: reindex option for tuning load large data
  • From: James Pang (chaolpan)
• Re: reindex option for tuning load large data
  • From: Vitalii Tymchyshyn
• reindex option for tuning load large data
  • From: James Pang (chaolpan)
• Re: Missed query planner optimization: `n in (select q)` -> `n in (q)`
  • From: David G. Johnston
• Missed query planner optimization: `n in (select q)` -> `n in (q)`
  • From: Josh
• Re: Strange behavior of limit clause in complex query
  • From: Justin Pryzby
• Re: Adding non-selective key to jsonb query @> reduces performance?
  • From: Tom Lane
• Re: Strange behavior of limit clause in complex query
  • From: Paulo Silva
• 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