Postgres Performance Date Index

• Thread Index

• pg_restore takes more time on creation of rules
  • From: Mariel Cherkassky
• Re: Log size in bytes of query result
  • From: Dmitry Dolgov
• Re: Log size in bytes of query result
  • From: Franklin Haut
• Re: Use Postgres as a column store by creating one table per column
  • From: Justin Pryzby
• Use Postgres as a column store by creating one table per column
  • From: Lev Kokotov
• Re: Temporarily very slow planning time after a big delete
  • From: Peter Geoghegan
• Re: Temporarily very slow planning time after a big delete
  • From: didier
• Re: Temporarily very slow planning time after a big delete
  • From: Walter Smith
• Re: Temporarily very slow planning time after a big delete
  • From: Peter Geoghegan
• Re: Temporarily very slow planning time after a big delete
  • From: Walter Smith
• Re: Temporarily very slow planning time after a big delete
  • From: Peter Geoghegan
• Re: Temporarily very slow planning time after a big delete
  • From: Walter Smith
• Re: Trying to handle db corruption 9.6
  • From: Tomas Vondra
• Re: Trying to handle db corruption 9.6
  • From: Mariel Cherkassky
• Re: Trying to handle db corruption 9.6
  • From: Tomas Vondra
• Re: Trying to handle db corruption 9.6
  • From: Mariel Cherkassky
• Re: Temporarily very slow planning time after a big delete
  • From: David Rowley
• Re: Temporarily very slow planning time after a big delete
  • From: Walter Smith
• Re: Analyze results in more expensive query plan
  • From: David Rowley
• Re: Temporarily very slow planning time after a big delete
  • From: Walter Smith
• Re: Temporarily very slow planning time after a big delete
  • From: Tom Lane
• Re: Temporarily very slow planning time after a big delete
  • From: David Rowley
• Temporarily very slow planning time after a big delete
  • From: Walter Smith
• Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Tomas Vondra
• Re: Re: Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Deepak Somaiya
• Re: Trying to handle db corruption 9.6
  • From: Tomas Vondra
• Re: Trying to handle db corruption 9.6
  • From: Tomas Vondra
• Re: Analyze results in more expensive query plan
  • From: Jeremy Altavilla
• Re: Trying to handle db corruption 9.6
  • From: Mariel Cherkassky
• Re: Trying to handle db corruption 9.6
  • From: Bimal
• Re: Trying to handle db corruption 9.6
  • From: Mariel Cherkassky
• Re: Trying to handle db corruption 9.6
  • From: Mariel Cherkassky
• Re: Trying to handle db corruption 9.6
  • From: Flo Rance
• Trying to handle db corruption 9.6
  • From: Mariel Cherkassky
• Re: Analyze results in more expensive query plan
  • From: Tom Lane
• Re: using sequential scan instead of index for join with a union
  • From: Kent Tong
• RE: Re: Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Naik, Sameer
• Analyze results in more expensive query plan
  • From: Jeremy Altavilla
• Re: using sequential scan instead of index for join with a union
  • From: Sergei Kornilov
• using sequential scan instead of index for join with a union
  • From: Kent Tong
• The wrong (?) query plan for queries with remote (postgres_fdw) tables
  • From: Vitaly Baranovsky
• Re: Huge generated UNION ALL faster than JOIN?
  • From: Ancoron Luciferis
• Re: Huge generated UNION ALL faster than JOIN?
  • From: Tom Lane
• Huge generated UNION ALL faster than JOIN?
  • From: Ancoron Luciferis
• Re: Log size in bytes of query result
  • From: Sergei Kornilov
• Re: Log size in bytes of query result
  • From: Laurenz Albe
• Log size in bytes of query result
  • From: Franklin Haut
• RE: GCC 8.3.0 vs. 9.0.1
  • From: Steven Winfield
• RE: integrate Postgres Users Authentication with our own LDAP Server
  • From: M Tarkeshwar Rao
• Re: integrate Postgres Users Authentication with our own LDAP Server
  • From: Laurenz Albe
• integrate Postgres Users Authentication with our own LDAP Server
  • From: M Tarkeshwar Rao
• Re: Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Deepak Somaiya
• Re: GCC 8.3.0 vs. 9.0.1
  • From: Andres Freund
• Re: GCC 8.3.0 vs. 9.0.1
  • From: Andres Freund
• Re: GCC 8.3.0 vs. 9.0.1
  • From: Andres Freund
• Re: GCC 8.3.0 vs. 9.0.1
  • From: Peter Geoghegan
• Re: GCC 8.3.0 vs. 9.0.1
  • From: Tom Lane
• GCC 8.3.0 vs. 9.0.1
  • From: Steven Winfield
• Re: PostgreSQL optimizer use seq scan instead of pkey index only scan (in queries with postgres_fdw)
  • From: Jeff Janes
• Re: PostgreSQL optimizer use seq scan instead of pkey index only scan (in queries with postgres_fdw)
  • From: Vitaly Baranovsky
• Re: PostgreSQL optimizer use seq scan instead of pkey index only scan (in queries with postgres_fdw)
  • From: Jeff Janes
• Re: PostgreSQL optimizer use seq scan instead of pkey index only scan (in queries with postgres_fdw)
  • From: Tom Lane
• Re: PostgreSQL optimizer use seq scan instead of pkey index only scan (in queries with postgres_fdw)
  • From: Vitaly Baranovsky
• Re: PostgreSQL optimizer use seq scan instead of pkey index only scan (in queries with postgres_fdw)
  • From: Jeff Janes
• PostgreSQL optimizer use seq scan instead of pkey index only scan (in queries with postgres_fdw)
  • From: Vitaly Baranovsky
• Re: Failure to reordering in case of a lateral join in combination with a left join (not inner join) resulting in suboptimal nested loop plan
  • From: Tom Lane
• Failure to reordering in case of a lateral join in combination with a left join (not inner join) resulting in suboptimal nested loop plan
  • From: Peter Billen
• RE: Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Naik, Sameer
• Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Tom Lane
• Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Andres Freund
• Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Tom Lane
• Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Bruce Momjian
• Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Naik, Sameer
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Jeff Janes
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Gaetano Mendola
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Backup and Restore (pg_dump & pg_restore)
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Backup and Restore (pg_dump & pg_restore)
  • From: Daulat Ram
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Jeff Janes
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Jeremy Schneider
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Gaetano Mendola
• Re: Pg10 : Client Configuration for Parallelism ?
  • From: Tom Lane
• Re: Pg10 : Client Configuration for Parallelism ?
  • From: Thomas Kellerer
• Re: Best Filesystem for PostgreSQL
  • From: Robert Blayzor
• Re: Best Filesystem for PostgreSQL
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Fwd: iscsi performance
  • From: Mahmoud Moharam
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• AW: Best Filesystem for PostgreSQL
  • From: Stephan Schmidt
• Re: Best Filesystem for PostgreSQL
  • From: Gunther Schadow
• Re: Best Filesystem for PostgreSQL
  • From: Imre Samu
• Re: Best Filesystem for PostgreSQL
  • From: Bruce Momjian
• Best Filesystem for PostgreSQL
  • From: Stephan Schmidt
• Re: Block / Page Size Optimization
  • From: Bruce Momjian
• Re: Pg10 : Client Configuration for Parallelism ?
  • From: Laurenz Albe
• RE: Pg10 : Client Configuration for Parallelism ?
  • From: laurent.dechambe
• Re: Pg10 : Client Configuration for Parallelism ?
  • From: Justin Pryzby
• Re: Pg10 : Client Configuration for Parallelism ?
  • From: Gunther Schadow
• Re: Pg10 : Client Configuration for Parallelism ?
  • From: Gunther Schadow
• RE: Pg10 : Client Configuration for Parallelism ?
  • From: laurent.dechambe
• RE: Pg10 : Client Configuration for Parallelism ?
  • From: laurent.dechambe
• Re: Pg10 : Client Configuration for Parallelism ?
  • From: Andreas Kretschmer
• RE: Pg10 : Client Configuration for Parallelism ?
  • From: laurent.dechambe
• RE: Pg10 : Client Configuration for Parallelism ?
  • From: laurent.dechambe
• Sv: Pg10 : Client Configuration for Parallelism ?
  • From: Andreas Joseph Krogh
• Re: Pg10 : Client Configuration for Parallelism ?
  • From: Thomas Kellerer
• Re: Pg10 : Client Configuration for Parallelism ?
  • From: Andreas Kretschmer
• Re: Out of Memory errors are frustrating as heck!
  • From: Gavin Flower
• Pg10 : Client Configuration for Parallelism ?
  • From: laurent.dechambe
• Re: Out of Memory errors are frustrating as heck!
  • From: Jean-David Beyer
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Gavin Flower
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Jeff Janes
• Re: Postgres backup & restore
  • From: Justin Pryzby
• Postgres backup & restore
  • From: Daulat Ram
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Alvaro Herrera
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: PostgreSQL upgrade.
  • From: Mark Kirkwood
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Jeff Janes
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Alvaro Herrera
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Jeff Janes
• Re: Block / Page Size Optimization
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Tomas Vondra
• Re: Out of Memory errors are frustrating as heck!
  • From: Jeff Janes
• Re: Out of Memory errors are frustrating as heck!
  • From: Jeff Janes
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Peter
• Re: Out of Memory errors are frustrating as heck!
  • From: Jeff Janes
• Re: PostgreSQL upgrade.
  • From: Mark Kirkwood
• Re: Out of Memory errors are frustrating as heck!
  • From: Justin Pryzby
• Re: Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: Out of Memory errors are frustrating as heck!
  • From: Jeff Janes
• Re: Out of Memory errors are frustrating as heck!
  • From: Tom Lane
• Out of Memory errors are frustrating as heck!
  • From: Gunther
• Re: PostgreSQL upgrade.
  • From: Andreas Kretschmer
• Re: Commit(?) overhead
  • From: Laurenz Albe
• PostgreSQL upgrade.
  • From: Daulat Ram
• Re: Commit(?) overhead
  • From: Duncan Kinnear
• Re: Commit(?) overhead
  • From: Andres Freund
• Re: Commit(?) overhead
  • From: Justin Pryzby
• Re: Commit(?) overhead
  • From: Duncan Kinnear
• Re: Planning performance problem (67626.278ms)
  • From: Andres Freund
• Re: Planning performance problem (67626.278ms)
  • From: Jeremy Schneider
• Re: Oracle to postgres migration
  • From: David G. Johnston
• Re: Oracle to postgres migration
  • From: Gavin Flower
• Re: Planning performance problem (67626.278ms)
  • From: Justin Pryzby
• Re: Oracle to postgres migration
  • From: legrand legrand
• Re: Oracle to postgres migration
  • From: phb07
• Re: Block / Page Size Optimization
  • From: Andres Freund
• Block / Page Size Optimization
  • From: Gunther
• Re: Planning performance problem (67626.278ms)
  • From: Pavel Stehule
• Re: Planning performance problem (67626.278ms)
  • From: Krzysztof Plocharz
• Re: Planning performance problem (67626.278ms)
  • From: Krzysztof Plocharz
• Re: Planning performance problem (67626.278ms)
  • From: Justin Pryzby
• Re: Planning performance problem (67626.278ms)
  • From: Pavel Stehule
• Re: Planning performance problem (67626.278ms)
  • From: Krzysztof Plocharz
• RE: Planning performance problem (67626.278ms)
  • From: Igor Neyman
• Planning performance problem (67626.278ms)
  • From: Krzysztof Plocharz
• Re: Oracle to postgres migration
  • From: Rick Otten
• Re: Oracle to postgres migration
  • From: Julien Rouhaud
• Oracle to postgres migration
  • From: Daulat Ram
• Re: monitoring options for postgresql under AWS/RDS?
  • From: Praveen Duraiswami
• RE: monitoring options for postgresql under AWS/RDS?
  • From: Mamet, Eric (GfK)
• Re: RAM usage of PostgreSql
  • From: Keith
• Re: RAM usage of PostgreSql
  • From: Laurenz Albe
• Re: monitoring options for postgresql under AWS/RDS?
  • From: Rijo Roy
• Re: RAM usage of PostgreSql
  • From: Justin Pryzby
• Re: monitoring options for postgresql under AWS/RDS?
  • From: Justin Pryzby
• monitoring options for postgresql under AWS/RDS?
  • From: Mamet, Eric (GfK)
• Re: Commit(?) overhead
  • From: Jeff Janes
• RAM usage of PostgreSql
  • From: Prasad
• Commit(?) overhead
  • From: Duncan Kinnear
• Re: parallel query
  • From: Laurenz Albe
• [no subject]
  • From: Mariel Cherkassky
• Re: Postgresql Sort cost Poor performance?
  • From: tank.zhang
• Re: Postgresql Sort cost Poor performance?
  • From: David Rowley
• Re: Postgresql Sort cost Poor performance?
  • From: tank.zhang
• Re: Postgresql Sort cost Poor performance?
  • From: Ramón Bastidas
• Re: Good afternoon.
  • From: Ramón Bastidas
• Re: LIMIT OFFSET with DB view vs plain SQL
  • From: Ramón Bastidas
• Re: LIMIT OFFSET with DB view vs plain SQL
  • From: SAMEER KUMAR
• Re: LIMIT OFFSET with DB view vs plain SQL
  • From: Raj Gandhi
• Re: LIMIT OFFSET with DB view vs plain SQL
  • From: Raj Gandhi
• Re: Good afternoon.
  • From: Rafia Sabih
• Re: trying to analyze deadlock
  • From: Mariel Cherkassky
• Re: Postgresql Sort cost Poor performance?
  • From: Christoph Berg
• Re: Postgresql Sort cost Poor performance?
  • From: Gavin Flower
• Re: Postgresql Sort cost Poor performance?
  • From: tank.zhang
• Re: Postgresql Sort cost Poor performance?
  • From: Andrew Gierth
• Postgresql Sort cost Poor performance?
  • From: tank.zhang
• Re: LIMIT OFFSET with DB view vs plain SQL
  • From: Raj Gandhi
• Need advice: Parallel query execution introduces performance regression
  • From: Jinho Jung
• Re: endless quere when upsert with ON CONFLICT clause
  • From: Andreas Kretschmer
• Re: LIMIT OFFSET with DB view vs plain SQL
  • From: Merlin Moncure
• endless quere when upsert with ON CONFLICT clause
  • From: Stephan Schmidt
• Re: LIMIT OFFSET with DB view vs plain SQL
  • From: Raj Gandhi
• Re: Scale out postgresql
  • From: Sumedh Pathak
• Re: Scale out postgresql
  • From: Mariel Cherkassky
• Re: Scale out postgresql
  • From: Sam R.
• Scale out postgresql
  • From: Mariel Cherkassky
• Re: trying to analyze deadlock
  • From: Laurenz Albe
• Re: trying to analyze deadlock
  • From: Laurenz Albe
• trying to analyze deadlock
  • From: Mariel Cherkassky
• Re: EXPLAIN PLAN for DELETE CASCADE or DELETE not using pkey index despite EXPLAINing that it would?
  • From: Justin Pryzby
• Re: EXPLAIN PLAN for DELETE CASCADE or DELETE not using pkey index despite EXPLAINing that it would?
  • From: Gunther
• Re: Poor man's partitioned index .... not being used?
  • From: David Rowley
• Re: EXPLAIN PLAN for DELETE CASCADE or DELETE not using pkey index despite EXPLAINing that it would?
  • From: Tom Lane
• EXPLAIN PLAN for DELETE CASCADE or DELETE not using pkey index despite EXPLAINing that it would?
  • From: Gunther
• Re: Poor man's partitioned index .... not being used?
  • From: Gunther
• Re: Poor man's partitioned index .... not being used?
  • From: Andrew Gierth
• Re: Poor man's partitioned index .... not being used?
  • From: David Rowley
• Poor man's partitioned index .... not being used?
  • From: Gunther
• AW: Performance issue with order by clause on
  • From: Stephan Schmidt
• Re: Performance issue with order by clause on
  • From: Corey Huinker
• Performance issue with order by clause on
  • From: Maracska Ádám
• Re: Distributing data over "spindles" even on AWS EBS, (followup to the work queue saga)
  • From: Sam Gendler
• Re: Distributing data over "spindles" even on AWS EBS, (followup to the work queue saga)
  • From: Gunther
• Re: Facing issue in using special characters
  • From: Warner, Gary, Jr
• MDRaid or LSI MegaRAID?
  • From: Rory Campbell-Lange
• jsonb_set performance degradation / multiple jsonb_set on multiple documents
  • From: Alexandru Lazarev
• Re: Facing issue in using special characters
  • From: Gunther
• Re: impact of auto explain on overall performance
  • From: Jeremy Schneider
• Re: impact of auto explain on overall performance
  • From: Jeff Janes
• Re: Distributing data over "spindles" even on AWS EBS, (followup to the work queue saga)
  • From: Justin Pryzby
• Re: Distributing data over "spindles" even on AWS EBS, (followup to the work queue saga)
  • From: Jeremy Schneider
• Re: Distributing data over "spindles" even on AWS EBS, (followup to the work queue saga)
  • From: Gunther
• Re: impact of auto explain on overall performance
  • From: Adrien NAYRAT
• Re: impact of auto explain on overall performance
  • From: Justin Pryzby
• impact of auto explain on overall performance
  • From: Stephan Schmidt
• Distributing data over "spindles" even on AWS EBS, (followup to the work queue saga)
  • From: Gunther
• Re: ERROR: found xmin from before relfrozenxid
  • From: Adrien NAYRAT
• Re: Planner not choosing GIN index
  • From: Flo Rance
• Re: Planner not choosing GIN index
  • From: Corey Huinker
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: ERROR: found xmin from before relfrozenxid
  • From: Alexandre Arruda
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: ERROR: found xmin from before relfrozenxid
  • From: Adrien NAYRAT
• Re: Planner not choosing GIN index
  • From: Flo Rance
• Planner not choosing GIN index
  • From: Corey Huinker
• Re: Shared_buffers
  • From: MichaelDBA
• Re: Shared_buffers
  • From: Justin Pryzby
• Re: Shared_buffers
  • From: MichaelDBA
• Re: Shared_buffers
  • From: Michael Lewis
• Re: Shared_buffers
  • From: Laurenz Albe
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Performance regression related to parallel execution
  • From: Jinho Jung
• Shared_buffers
  • From: Daulat Ram
• Wired execution in my benchmark using postgresql 9.6
  • From: tayeb merabti
• Re: Hot to model data in DB (PostgreSQL) for SNMP-like multiple configurations
  • From: Rene Romero Benavides
• Re: Hot to model data in DB (PostgreSQL) for SNMP-like multiple configurations
  • From: Alexandru Lazarev
• Re: Hot to model data in DB (PostgreSQL) for SNMP-like multiple configurations
  • From: Alban Hertroys
• Re: IS NOT DISTINCT FROM statement
  • From: Tom Lane
• Hot to model data in DB (PostgreSQL) for SNMP-like multiple configurations
  • From: Alexandru Lazarev
• Re: IS NOT DISTINCT FROM statement
  • From: David Rowley
• RE: IS NOT DISTINCT FROM statement
  • From: Artur Zając
• Re: IS NOT DISTINCT FROM statement
  • From: David Rowley
• Re: IS NOT DISTINCT FROM statement
  • From: Laurenz Albe
• IS NOT DISTINCT FROM statement
  • From: Artur Zając
• Re: rusage (Re: Good afternoon.)
  • From: Julien Rouhaud
• rusage (Re: Good afternoon.)
  • From: Justin Pryzby
• Good afternoon.
  • From: Kenia Vergara
• Performance regressions found using sqlfuzz
  • From: Jinho Jung
• Re: JIT performance question
  • From: Andres Freund
• Re: JIT performance question
  • From: Tobias Gierke
• Re: JIT performance question
  • From: Andres Freund
• Re: autovacuum just stop vacuuming specific table for 7 hours
  • From: Mariel Cherkassky
• JIT performance question
  • From: Tobias Gierke
• Re: autovacuum just stop vacuuming specific table for 7 hours
  • From: Justin Pryzby
• autovacuum just stop vacuuming specific table for 7 hours
  • From: Mariel Cherkassky
• Re: Server upgrade advice [xpost]
  • From: Ian Harding
• Server upgrade advice [xpost]
  • From: Rory Campbell-Lange
• 2019 Database Trends – SQL vs. NoSQL, Top Databases, Single vs. Multiple Database Use
  • From: Kristi Anderson
• Re: pgstattuple_approx for toasted table
  • From: Laurenz Albe
• pgstattuple_approx for toasted table
  • From: Mariel Cherkassky
• RE: How to get the content of Bind variables
  • From: ROS Didier
• RE: How to get the content of Bind variables
  • From: ROS Didier
• Re: How to get the content of Bind variables
  • From: Sergei Kornilov
• Re: How to get the content of Bind variables
  • From: Tom Lane
• Re: How to get the content of Bind variables
  • From: Justin Pryzby
• RE: How to get the content of Bind variables
  • From: legrand legrand
• RE: How to get the content of Bind variables
  • From: ROS Didier
• RE: How to get the content of Bind variables
  • From: legrand legrand
• RE: How to get the content of Bind variables
  • From: ROS Didier
• Re: How to get the content of Bind variables
  • From: Tom Lane
• Re: How to get the content of Bind variables
  • From: Laurenz Albe
• RE: How to get the content of Bind variables
  • From: ROS Didier
• Re: Performance regressions found using sqlfuzz
  • From: Jung, Jinho
• Re: How to get the content of Bind variables
  • From: Justin Pryzby
• RE: How to get the content of Bind variables
  • From: ROS Didier
• Re: How to get the content of Bind variables
  • From: Laurenz Albe
• RE: What is pg_stat_user_tables Showing NULL for last_autoanalyze &last_autovacuum
  • From: Fd Habash
• RE: How to get the content of Bind variables
  • From: ROS Didier
• Re: How to get the content of Bind variables
  • From: MichaelDBA
• How to get the content of Bind variables
  • From: ROS Didier
• Re: What is pg_stat_user_tables Showing NULL for last_autoanalyze & last_autovacuum
  • From: Laurenz Albe
• Re: Query slow for new participants
  • From: support@xxxxxxxxx
• Re: What is pg_stat_user_tables Showing NULL for last_autoanalyze & last_autovacuum
  • From: Justin Pryzby
• What is pg_stat_user_tables Showing NULL for last_autoanalyze & last_autovacuum
  • From: Fd Habash
• Re: Query slow for new participants
  • From: Laurenz Albe
• Re: Query slow for new participants
  • From: Michael Lewis
• Re: Query slow for new participants
  • From: support@xxxxxxxxx
• Re: Aggregate and many LEFT JOIN
  • From: Jeff Janes
• Re: Aggregate and many LEFT JOIN
  • From: Justin Pryzby
• Re: Aggregate and many LEFT JOIN
  • From: kimaidou
• Re: Query slow for new participants
  • From: MichaelDBA
• Re: Query slow for new participants
  • From: Justin Pryzby
• Re: Query slow for new participants
  • From: support@xxxxxxxxx
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: MichaelDBA
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Jeff Janes
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Jeff Janes
• Re: Aggregate and many LEFT JOIN
  • From: Michael Lewis
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Corey Huinker
• Re: Query slow for new participants
  • From: Justin Pryzby
• Query slow for new participants
  • From: Kim
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Gunther Schadow
• Re: Idle backends outside a transaction holding onto large amounts of memory / swap space?
  • From: Pavel Stehule
• Idle backends outside a transaction holding onto large amounts of memory / swap space?
  • From: Tobias Gierke
• Re: Aggregate and many LEFT JOIN
  • From: kimaidou
• Re: Aggregate and many LEFT JOIN
  • From: kimaidou
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Justin Pryzby
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Gunther
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Jeff Janes
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Jeff Janes
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Corey Huinker
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Justin Pryzby
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Corey Huinker
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Peter Geoghegan
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Justin Pryzby
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Gunther
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Corey Huinker
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Justin Pryzby
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: David Rowley
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Gunther
• Re: Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Peter Geoghegan
• Massive parallel queue table causes index deterioration, but REINDEX fails with deadlocks.
  • From: Gunther
• RE: Slow query with aggregate and many LEFT JOINS
  • From: Igor Neyman
• RE: Slow query with aggregate and many LEFT JOINS
  • From: Igor Neyman
• Re: Aggregate and many LEFT JOIN
  • From: Tom Lane
• Re: Aggregate and many LEFT JOIN
  • From: Michael Lewis
• Re: Aggregate and many LEFT JOIN
  • From: kimaidou
• Re: Aggregate and many LEFT JOIN
  • From: Michael Lewis
• Re: Aggregate and many LEFT JOIN
  • From: Justin Pryzby
• Slow query with aggregate and many LEFT JOINS
  • From: kimaidou
• Aggregate and many LEFT JOIN
  • From: kimaidou
• Re: neither CPU nor IO bound, but throttled performance
  • From: Gunther Schadow
• Re: neither CPU nor IO bound, but throttled performance
  • From: Magnus Hagander
• Re: neither CPU nor IO bound, but throttled performance
  • From: Justin Pryzby
• Re: How can sort performance be so different
  • From: Peter Geoghegan
• neither CPU nor IO bound, but throttled performance
  • From: Gunther
• Re: How can sort performance be so different
  • From: Peter Geoghegan
• Re: How can sort performance be so different
  • From: Bob Jolliffe
• Re: How can sort performance be so different
  • From: Merlin Moncure
• Re: Why isn't an index scan being used?
  • From: Jeff Janes
• Re: Why isn't an index scan being used?
  • From: Justin Pryzby
• Re: Why isn't an index scan being used?
  • From: Abi Noda
• Re: Why isn't an index scan being used?
  • From: Justin Pryzby
• Re: Why isn't an index scan being used?
  • From: Michael Lewis
• Re: Why isn't an index scan being used?
  • From: Andrew Gierth
• Re: Why isn't an index scan being used?
  • From: Abi Noda
• Re: Why isn't an index scan being used?
  • From: David Rowley
• Why isn't an index scan being used?
  • From: Abi Noda
• Re: index on jsonb col with 2D array inside the json
  • From: Mariel Cherkassky
• Re: index on jsonb col with 2D array inside the json
  • From: Michael Lewis
• Re: index on jsonb col with 2D array inside the json
  • From: Mariel Cherkassky
• Re: index on jsonb col with 2D array inside the json
  • From: Michael Lewis
• index on jsonb col with 2D array inside the json
  • From: Mariel Cherkassky
• Re: Performance regressions found using sqlfuzz
  • From: Jung, Jinho
• Re: How can sort performance be so different
  • From: Bob Jolliffe
• Re: dsa_allocate() faliure
  • From: Jakub Glapa
• Re: dsa_allocate() faliure
  • From: Justin Pryzby
• Re: Performance regressions found using sqlfuzz
  • From: Tom Lane
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Justin Pryzby
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Mariel Cherkassky
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Benedict Holland
• Re: Performance regressions found using sqlfuzz
  • From: Andres Freund
• Re: Performance regressions found using sqlfuzz
  • From: Andrew Gierth
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: suganthi Sekar
• Re: Performance regressions found using sqlfuzz
  • From: Jung, Jinho
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Alvaro Herrera
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Laurenz Albe
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Michael Lewis
• Re: JIT overhead slowdown
  • From: Justin Pryzby
• Re: Q on SQL Performance tuning
  • From: Greg Stark
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Michael Lewis
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Michael Lewis
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Michael Lewis
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: partition pruning
  • From: Justin Pryzby
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: suganthi Sekar
• Re: partition pruning
  • From: suganthi Sekar
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Michael Lewis
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Justin Pryzby
• Re: partition pruning
  • From: Laurenz Albe
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: suganthi Sekar
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: suganthi Sekar
• Re: server hardware tuning.
  • From: suganthi Sekar
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Justin Pryzby
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Mariel Cherkassky
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Alvaro Herrera
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Mariel Cherkassky
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Alvaro Herrera
• ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Mariel Cherkassky
• Re: understanding max_wal_size,wal_keep_segments and checkpoints
  • From: Laurenz Albe
• Re: understanding max_wal_size,wal_keep_segments and checkpoints
  • From: Mariel Cherkassky
• Re: understanding max_wal_size,wal_keep_segments and checkpoints
  • From: Laurenz Albe
• understanding max_wal_size,wal_keep_segments and checkpoints
  • From: Mariel Cherkassky
• Re: Bloom index cost model seems to be wrong
  • From: Jeff Janes
• Re: Bloom index cost model seems to be wrong
  • From: Tom Lane
• Re: Bloom index cost model seems to be wrong
  • From: Jeff Janes
• Re: Performance regressions found using sqlfuzz
  • From: Jeff Janes
• Re: Bloom index cost model seems to be wrong
  • From: Jeff Janes
• Re: Bloom index cost model seems to be wrong
  • From: Tom Lane
• Bloom index cost model seems to be wrong
  • From: Thomas Kellerer
• Re: Performance regressions found using sqlfuzz
  • From: Christoph Berg
• Performance regressions found using sqlfuzz
  • From: Jung, Jinho
• Re: Partitioning Optimizer Questions and Issues
  • From: keith anderson
• Re:
  • From: Tumasgiu Rossini
• Re: slow to run query 5000 times
  • From: Ricardo Martin Gomez
• Re: slow to run query 5000 times
  • From: Andres Freund
• Re: slow to run query 5000 times
  • From: Justin Pryzby
• [no subject]
  • From: Evandro Abreu
• Re: Partitioning Optimizer Questions and Issues
  • From: Justin Pryzby
• Partitioning Optimizer Questions and Issues
  • From: keith anderson
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Jeff Janes
• Managing High Availability in PostgreSQL – Part I
  • From: Kristi Anderson
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Transaction size and Wal2Json
  • From: Mai Peng
• Re: Transaction size and Wal2Json
  • From: Peter Eisentraut
• Re: autovacuum big table taking hours and sometimes seconds
  • From: David Rowley
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Jeff Janes
• Re: autovacuum big table taking hours and sometimes seconds
  • From: MichaelDBA
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Jeff Janes
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: dangal
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: David Rowley
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Laurenz Albe
• autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: How can sort performance be so different
  • From: Laurenz Albe
• Re: How can sort performance be so different
  • From: Merlin Moncure
• Re: dsa_allocate() faliure
  • From: Justin Pryzby
• RE: dsa_allocate() faliure
  • From: Arne Roland
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Sv: Re: Fw: server hardware tuning.
  • From: Andreas Joseph Krogh
• Re: Fw: server hardware tuning.
  • From: Prince Pathria
• Fw: server hardware tuning.
  • From: suganthi Sekar
• Re: dsa_allocate() faliure
  • From: Thomas Munro
• Re: dsa_allocate() faliure
  • From: Jakub Glapa
• Re: dsa_allocate() faliure
  • From: Justin Pryzby
• RE: dsa_allocate() faliure
  • From: Arne Roland
• Re: How can sort performance be so different
  • From: Bob Jolliffe
• Re: Setting effective_cache size
  • From: Laurenz Albe
• Re: Setting effective_cache size
  • From: Nandakumar M
• Setting effective_cache size
  • From: Nandakumar M
• Re: How can sort performance be so different
  • From: Peter Geoghegan
• Re: pgstattupple vs pg_total_relation_size
  • From: Tom Lane
• Re: pgstattupple vs pg_total_relation_size
  • From: Mariel Cherkassky
• Re: pgstattupple vs pg_total_relation_size
  • From: Jehan-Guillaume (ioguix) de Rorthais
• Re: pgstattupple vs pg_total_relation_size
  • From: Tumasgiu Rossini
• Re: How can sort performance be so different
  • From: Bob Jolliffe
• pgstattupple vs pg_total_relation_size
  • From: Mariel Cherkassky
• Re: dsa_allocate() faliure
  • From: Fabio Isabettini
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: ERROR: found xmin from before relfrozenxid
  • From: Alvaro Herrera
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: Will higher shared_buffers improve tpcb-like benchmarks?
  • From: Saurabh Nanda
• Re: dsa_allocate() faliure
  • From: Thomas Munro
• Re: How can sort performance be so different
  • From: Tom Lane
• Re: Interpreting shared_buffers setting
  • From: Jerry Sievers
• Re: How can sort performance be so different
  • From: Saurabh Nanda
• Re: How can sort performance be so different
  • From: Pavel Stehule
• Re: Interpreting shared_buffers setting
  • From: Jerry Sievers
• How can sort performance be so different
  • From: Bob Jolliffe
• Re: Will higher shared_buffers improve tpcb-like benchmarks?
  • From: Saurabh Nanda
• Re: Will higher shared_buffers improve tpcb-like benchmarks?
  • From: Jeff Janes
• Re: pg_locks - what is a virtualxid locktype
  • From: Alvaro Herrera
• Re: Interpreting shared_buffers setting
  • From: Bob Jolliffe
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Jeff Janes
• Re: Interpreting shared_buffers setting
  • From: Andrew Gierth
• Re: Interpreting shared_buffers setting
  • From: Thomas Markus
• Interpreting shared_buffers setting
  • From: Bob Jolliffe
• Re: Will higher shared_buffers improve tpcb-like benchmarks?
  • From: Joe Mirabal
• Re: dsa_allocate() faliure
  • From: Fabio Isabettini
• Will higher shared_buffers improve tpcb-like benchmarks?
  • From: Saurabh Nanda
• Re: pg_locks - what is a virtualxid locktype
  • From: Shreeyansh Dba
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Nicolas Charles
• pg_locks - what is a virtualxid locktype
  • From: Mariel Cherkassky
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: dsa_allocate() faliure
  • From: Thomas Munro
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• RE: dsa_allocate() faliure
  • From: Arne Roland
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Nicolas Charles
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: upgrade from 9.6 to 10/11
  • From: Justin Pryzby
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Nicolas Charles
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: upgrade from 9.6 to 10/11
  • From: Laurenz Albe
• upgrade from 9.6 to 10/11
  • From: Mariel Cherkassky
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Jeff Janes
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Jeff Janes
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Justin Pryzby
• Re: Q on SQL Performance tuning
  • From: Justin Pryzby
• Re: Q on SQL Performance tuning
  • From: legrand legrand
• Q on SQL Performance tuning
  • From: Bhupathi, Kaushik (CORP)
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: ERROR: found xmin from before relfrozenxid
  • From: Adrien NAYRAT
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: ERROR: found xmin from before relfrozenxid
  • From: Adrien NAYRAT
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: Tom Lane
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: Tom Lane
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: Tom Lane
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: ERROR: found xmin from before relfrozenxid
  • From: Adrien NAYRAT
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Zero throughput on a query on a very large table.
  • From: David Rowley
• Re: Zero throughput on a query on a very large table.
  • From: Tom Lane
• Re: Zero throughput on a query on a very large table.
  • From: Andreas Kretschmer
• Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: SELECT performance drop
  • From: Jan Nielsen
• RE: dsa_allocate() faliure
  • From: Arne Roland
• Re: SELECT performance drop
  • From: Jan Nielsen
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: Parallel stats in execution plans
  • From: David Rowley
• Re: Parallel stats in execution plans
  • From: David Conlin
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: SELECT performance drop
  • From: Laurenz Albe
• Re: ERROR: found xmin from before relfrozenxid
  • From: Jerry Sievers
• RE:SELECT performance drop
  • From: legrand legrand
• Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: SELECT performance drop
  • From: Jan Nielsen
• ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: SELECT performance drop
  • From: Jim Finnerty
• Re: SELECT performance drop
  • From: Jan Nielsen
• Re: SELECT performance drop
  • From: legrand legrand
• ANALYZE accuracy problems for n_distinct, and a solution
  • From: Jim Finnerty
• Re: SELECT performance drop
  • From: Jan Nielsen
• SELECT performance drop
  • From: Jan Nielsen
• RE: Memory and hard ware calculation :
  • From: Rangaraj G
• Re: Very long query planning times for database with lots of partitions
  • From: Mickael van der Beek
• RE: Very long query planning times for database with lots of partitions
  • From: Steven Winfield
• Re: Very long query planning times for database with lots of partitions
  • From: Justin Pryzby
• Very long query planning times for database with lots of partitions
  • From: Mickael van der Beek
• Re: Memory and hard ware calculation :
  • From: Fabio Pardi
• Re: Memory and hard ware calculation :
  • From: Cleiton Luiz Domazak
• Memory and hard ware calculation :
  • From: Rangaraj G
• Re: JIT overhead slowdown
  • From: Luis Carril
• Re: JIT overhead slowdown
  • From: Andres Freund
• JIT overhead slowdown
  • From: Luis Carril
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Alvaro Herrera
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Alvaro Herrera
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Alvaro Herrera
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Justin Pryzby
• autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: No matching tables have ever been vacuumed
  • From: Laurenz Albe
• Parallel stats in execution plans
  • From: David Conlin
• No matching tables have ever been vacuumed
  • From: Daulat Ram
• Re: Detect missing combined indexes (automatically)
  • From: Julien Rouhaud
• Re: Detect missing combined indexes (automatically)
  • From: Thomas Güttler
• Re: Detect missing combined indexes (automatically)
  • From: Julien Rouhaud
• Re: Detect missing combined indexes (automatically)
  • From: Thomas Kellerer
• Re: Detect missing combined indexes (automatically)
  • From: Jim Finnerty
• Re: does dml operations load the blocks to the shared buffers ?
  • From: Guillaume Lelarge
• Detect missing combined indexes (automatically)
  • From: Thomas Güttler
• Re: does dml operations load the blocks to the shared buffers ?
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Ken Tanzer
• Re: PostgreSQL Read IOPS limit per connection
  • From: Mark Hogg
• Re: does dml operations load the blocks to the shared buffers ?
  • From: Guillaume Lelarge
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• does dml operations load the blocks to the shared buffers ?
  • From: Mariel Cherkassky
• Re: PostgreSQL Read IOPS limit per connection
  • From: Merlin Moncure
• Re: PostgreSQL Read IOPS limit per connection
  • From: Haroldo Kerry
• Re: select query does not pick up the right index
  • From: Abadie Lana
• Re: PostgreSQL Read IOPS limit per connection
  • From: Merlin Moncure
• Re: select query does not pick up the right index
  • From: David Rowley
• Re: postgresql unix socket connections
  • From: Tom Lane
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Jeff Janes
• Re: postgresql unix socket connections
  • From: Jeff Janes
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Tom Lane
• RE: select query does not pick up the right index
  • From: Abadie Lana
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• postgresql unix socket connections
  • From: Mariel Cherkassky