Postgres Performance Date Index

• Thread Index

• 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
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Justin Pryzby
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Ranier Vilela
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Justin Pryzby
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Justin Pryzby
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Maciek Sakrejda
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Justin Pryzby
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Mladen Gogala
• Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: Tom Lane
• RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Postgres using the wrong index index
  • From: Justin Pryzby
• Re: Postgres using the wrong index index
  • From: Matt Dupree
• Re: Postgres using the wrong index index
  • From: Justin Pryzby
• Re: Postgres using the wrong index index
  • From: Matt Dupree
• Re: Postgres using the wrong index index
  • From: Justin Pryzby
• Re: Postgres using the wrong index index
  • From: Mladen Gogala
• Re: Postgres using the wrong index index
  • From: Matt Dupree
• Re: PostgreSQL equivalent of UTL_HTTP
  • From: Pavel Stehule
• PostgreSQL equivalent of UTL_HTTP
  • From: aditya desai
• Re: difference between pg_triggers and information_schema.triggers
  • From: aditya desai
• Re: difference between pg_triggers and information_schema.triggers
  • From: David G. Johnston
• difference between pg_triggers and information_schema.triggers
  • From: aditya desai
• Re: Postgres using the wrong index index
  • From: Justin Pryzby
• Postgres using the wrong index index
  • From: Matt Dupree
• Re: Slow query because lexeme index not used
  • From: Alex
• Re: Slow query because lexeme index not used
  • From: Justin Pryzby
• Slow query because lexeme index not used
  • From: Alex
• Re: Logical Replication speed-up initial data
  • From: Jeff Janes
• Re: Logical Replication speed-up initial data
  • From: Vijaykumar Jain
• Re: Logical Replication speed-up initial data
  • From: Nikhil Shetty
• Re: Logical Replication speed-up initial data
  • From: Nikhil Shetty
• Re: Logical Replication speed-up initial data
  • From: Avinash Kumar
• Re: Logical Replication speed-up initial data
  • From: Vijaykumar Jain
• Re: Logical Replication speed-up initial data
  • From: Rick Otten
• Re: Logical Replication speed-up initial data
  • From: Nikhil Shetty
• Re: Logical Replication speed-up initial data
  • From: Nikhil Shetty
• Re: Logical Replication speed-up initial data
  • From: Christophe Pettus
• Re: Logical Replication speed-up initial data
  • From: Stefano Amoroso
• Re: Logical Replication speed-up initial data
  • From: Hüseyin Demir
• Logical Replication speed-up initial data
  • From: Nikhil Shetty
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Daniel Westermann (DWE)
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Pavel Stehule
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Daniel Westermann (DWE)
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Pavel Stehule
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Pavel Stehule
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Pavel Stehule
• Re: Performance issue with thousands of calls to procedures and functions?
  • From: Imre Samu
• Performance issue with thousands of calls to procedures and functions?
  • From: Daniel Westermann (DWE)
• Re: Query performance !
  • From: Justin Pryzby
• Re: Performance of lateral join
  • From: Simen Andreas Andreassen Lønsethagen
• Query performance !
  • From: kenny a
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: David G. Johnston
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Performance of lateral join
  • From: Justin Pryzby
• Re: Query performance !
  • From: Bruce Momjian
• Query performance !
  • From: kenny a
• Re: Performance of lateral join
  • From: Justin Pryzby
• Performance of lateral join
  • From: Simen Andreas Andreassen Lønsethagen
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Performance Issue on a table
  • From: Justin Pryzby
• Performance Issue on a table
  • From: Manoj Kumar
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Vijaykumar Jain
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Vijaykumar Jain
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Alvaro Herrera
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Ranier Vilela
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Justin Pryzby
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Justin Pryzby
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Justin Pryzby
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Justin Pryzby
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: David Rowley
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• Re: Big performance slowdown from 11.2 to 13.3
  • From: David Rowley
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Partitioned table statistics vs autoanalyze
  • From: Kamil Frydel
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Partitioned table statistics vs autoanalyze
  • From: Justin Pryzby
• Partitioned table statistics vs autoanalyze
  • From: Kamil Frydel
• Re: Big performance slowdown from 11.2 to 13.3
  • From: David Rowley
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Tom Lane
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Peter Geoghegan
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Michael Lewis
• Re: Big performance slowdown from 11.2 to 13.3
  • From: Justin Pryzby
• Big performance slowdown from 11.2 to 13.3
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Query Performance
  • From: Tom Lane
• Query Performance
  • From: Dirschel, Steve
• Re: Performance benchmark of PG
  • From: Manish Lad
• Re: Performance benchmark of PG
  • From: Ninad Shah
• Re: Performance benchmark of PG
  • From: Manish Lad
• Re: Performance benchmark of PG
  • From: Thomas Kellerer
• Re: Performance benchmark of PG
  • From: Hüseyin Demir
• Re: Performance benchmark of PG
  • From: Manish Lad
• Re: Performance benchmark of PG
  • From: Laurenz Albe
• Performance benchmark of PG
  • From: Manish Lad
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Laurenz Albe
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Tobias Gierke
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Tobias Gierke
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Tobias Gierke
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Ninad Shah
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Tom Lane
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: David Rowley
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Benjamin Scherrey
• Re: Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Justin Pryzby
• Linear slow-down while inserting into a table with an ON INSERT trigger ?
  • From: Tobias Gierke
• Re: temporary file log lines
  • From: Tomas Vondra
• Re: temporary file log lines
  • From: Guillaume Lelarge
• Re: temporary file log lines
  • From: MichaelDBA
• Re: temporary file log lines
  • From: Laurenz Albe
• RE: Partition column should be part of PK
  • From: Michel SALAIS
• Re: Partition column should be part of PK
  • From: Thomas Kellerer
• Re: Partition column should be part of PK
  • From: David Rowley
• Re: Partition column should be part of PK
  • From: Christophe Pettus
• Re: Partition column should be part of PK
  • From: Justin Pryzby
• Re: Partition column should be part of PK
  • From: Nagaraj Raj
• Re: Partition column should be part of PK
  • From: Christophe Pettus
• Re: Partition column should be part of PK
  • From: Nagaraj Raj
• Re: Strange execution plan
  • From: Manuel Weitzman
• RE: Partition column should be part of PK
  • From: Mike Sofen
• Re: Partition column should be part of PK
  • From: Alvaro Herrera
• Re: Partition column should be part of PK
  • From: Justin Pryzby
• temporary file log lines
  • From: MichaelDBA
• Re: Strange execution plan
  • From: Manuel Weitzman
• Re: Strange execution plan
  • From: Manuel Weitzman
• ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification
  • From: Nagaraj Raj
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Allan Barrielle
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Allan Barrielle
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Allan Barrielle
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Justin Pryzby
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Imre Samu
• Re: ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Justin Pryzby
• ETL - sql orchestrator is stuck when there is not sleep() between queries
  • From: Allan Barrielle
• Strange execution plan
  • From: Joel Frid
• Strange execution plan
  • From: Joel Frid
• Re: hint in determining effective_io_concurrency
  • From: Luca Ferrari
• Re: hint in determining effective_io_concurrency
  • From: Merlin Moncure
• Re: slow performance with cursor
  • From: Tomas Vondra
• Re: Planning performance problem (67626.278ms)
  • From: David Rowley
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: slow performance with cursor
  • From: Ayub Khan
• Re: slow performance with cursor
  • From: Justin Pryzby
• Re: slow performance with cursor
  • From: Ayub Khan
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: Planning performance problem (67626.278ms)
  • From: Tom Lane
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: Planning performance problem (67626.278ms)
  • From: Tom Lane
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: slow performance with cursor
  • From: Tom Lane
• Re: slow performance with cursor
  • From: Ayub Khan
• Re: slow performance with cursor
  • From: Justin Pryzby
• slow performance with cursor
  • From: Ayub Khan
• Re: Partition column should be part of PK
  • From: Justin Pryzby
• Partition column should be part of PK
  • From: Nagaraj Raj
• Re: Planning performance problem (67626.278ms)
  • From: Tom Lane
• Re: Estimating wal_keep_size
  • From: Dean Gibson (DB Administrator)
• Re: Planning performance problem (67626.278ms)
  • From: Ranier Vilela
• Re: Planning performance problem (67626.278ms)
  • From: Tom Lane
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: Estimating wal_keep_size
  • From: Vijaykumar Jain
• Re: Estimating wal_keep_size
  • From: Julien Rouhaud
• Re: Estimating wal_keep_size
  • From: Dean Gibson (DB Administrator)
• Re: PostgreSQL V13 Replication Issue
  • From: Michael Paquier
• Re: Estimating wal_keep_size
  • From: Julien Rouhaud
• Estimating wal_keep_size
  • From: Dean Gibson (DB Administrator)
• Re: PostgreSQL V13 Replication Issue
  • From: Dean Gibson (DB Administrator)
• PostgreSQL V13 Replication Issue
  • From: Haseeb Khan
• Re: waiting for client write
  • From: Vijaykumar Jain
• Re: Master - Slave Replication Window Server
  • From: Atul Kumar
• Re: waiting for client write
  • From: Ayub Khan
• Re: Master - Slave Replication Window Server
  • From: Haseeb Khan
• Re: Master - Slave Replication Window Server
  • From: Rory Campbell-Lange
• Re: overcommit_ratio setting
  • From: Yi Sun
• Re: overcommit_ratio setting
  • From: Laurenz Albe
• Re: Master - Slave Replication Window Server
  • From: Haseeb Khan
• Re: Master - Slave Replication Window Server
  • From: Haseeb Khan
• Re: overcommit_ratio setting
  • From: Yi Sun
• Re: Master - Slave Replication Window Server
  • From: Rory Campbell-Lange
• Master - Slave Replication Window Server
  • From: Haseeb Khan
• Re: Planning performance problem (67626.278ms)
  • From: Manuel Weitzman
• Re: overcommit_ratio setting
  • From: Laurenz Albe
• Re: overcommit_ratio setting
  • From: Julien Rouhaud
• Re: pg_dumpall --exclude-database case folding, was Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Tom Lane
• pg_dumpall --exclude-database case folding, was Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• overcommit_ratio setting
  • From: Yi Sun
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Vijaykumar Jain
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Vijaykumar Jain
• Re: waiting for client write
  • From: Ranier Vilela
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Jeff Janes
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ranier Vilela
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ranier Vilela
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ranier Vilela
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Ranier Vilela
• Re: waiting for client write
  • From: Pavan Pusuluri
• Re: waiting for client write
  • From: Ayub Khan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Tom Lane
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: waiting for client write
  • From: Vijaykumar Jain
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Ranier Vilela
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: waiting for client write
  • From: Jeff Janes
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Joshua Drake
• Re: Page File Size Reached Critical Threshold PostgreSQL V13
  • From: Justin Pryzby
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: Page File Size Reached Critical Threshold PostgreSQL V13
  • From: Justin Pryzby
• Re: waiting for client write
  • From: Ayub Khan
• Re: Page File Size Reached Critical Threshold PostgreSQL V13
  • From: Haseeb Khan
• Re: Page File Size Reached Critical Threshold PostgreSQL V13
  • From: Justin Pryzby
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Page File Size Reached Critical Threshold PostgreSQL V13
  • From: Haseeb Khan
• Re: slow query
  • From: Ayub Khan
• Re: slow query
  • From: Jeff Janes
• Re: waiting for client write
  • From: Ayub Khan
• Re: waiting for client write
  • From: Magnus Hagander
• waiting for client write
  • From: Ayub Khan
• Re: slow query
  • From: Ayub Khan
• Re: slow query
  • From: Tom Lane
• Re: slow query
  • From: Ayub Khan
• Re: slow query
  • From: Christophe Pettus
• slow query
  • From: Ayub Khan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: dexter on AWS RDS auto tune queries
  • From: Ayub Khan
• Re: dexter on AWS RDS auto tune queries
  • From: Julien Rouhaud
• Re: dexter on AWS RDS auto tune queries
  • From: Ayub Khan
• Re: dexter on AWS RDS auto tune queries
  • From: Christophe Pettus
• Re: dexter on AWS RDS auto tune queries
  • From: Julien Rouhaud
• dexter on AWS RDS auto tune queries
  • From: Ayub Khan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: query planner not using index, instead using squential scan
  • From: Vijaykumar Jain
• Re: query planner not using index, instead using squential scan
  • From: Ayub Khan
• Re: query planner not using index, instead using squential scan
  • From: Vijaykumar Jain
• Re: query planner not using index, instead using squential scan
  • From: Tom Lane
• query planner not using index, instead using squential scan
  • From: Ayub Khan
• RE: PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: Taras Savchuk
• Re: PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: Tom Lane
• Re: PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: Vijaykumar Jain
• Re: PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: David Rowley
• PgSQL 12 on WinSrv ~3x faster than on Linux
  • From: Taras Savchuk
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Ayub Khan
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Pavel Stehule
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Ayub Khan
• Re: slow query with inline function on AWS RDS with RDS 24x large
  • From: Pavel Stehule
• slow query with inline function on AWS RDS with RDS 24x large
  • From: Ayub Khan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Justin Pryzby
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Tom Lane
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Christophe Pettus
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Jan Wieck
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Alexey M Boltenkov
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Christophe Pettus
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Jan Wieck
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Bob Lunney
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Bruce Momjian
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Pavel Stehule
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Jan Wieck
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Michael Lewis
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Ryan Bair
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: MichaelDBA
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Campbell, Lance
• Re: AWS forcing PG upgrade from v9.6 a disaster
  • From: Andrew Dunstan
• AWS forcing PG upgrade from v9.6 a disaster
  • From: Dean Gibson (DB Administrator)
• Re: transaction blocking on COMMIT
  • From: Bob Jolliffe
• Count (select 1) subquery as constant
  • From: Eugen Konkov
• Re: issue partition scan
  • From: Christophe Pettus
• Re: issue partition scan
  • From: David Rowley