Postgres Performance Date Index

• Thread Index

• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Sverre Boschman
• ODP: Planner performance in partitions
  • From: Piotr Włodarczyk
• Re: Last event per user
  • From: Michael Lewis
• Re: Last event per user
  • From: Luís Roberto Weck
• Re:
  • From: Michael Lewis
• Re:
  • From: Luís Roberto Weck
• Re: Planner performance in partitions
  • From: Michael Lewis
• Re: Last event per user
  • From: Michael Lewis
• Re: Last event per user
  • From: Luís Roberto Weck
• Re: Planner performance in partitions
  • From: David Rowley
• Re: Last event per user
  • From: Michael Lewis
• Last event per user
  • From: Luís Roberto Weck
• Re: Planner performance in partitions
  • From: Michael Lewis
• ODP: Planner performance in partitions
  • From: Piotr Włodarczyk
• Re: Planner performance in partitions
  • From: MichaelDBA
• Re: Planner performance in partitions
  • From: Michael Lewis
• Planner performance in partitions
  • From: Piotr Włodarczyk
• Re: Bitmap heap scan performance
  • From: Jeremy Finzel
• Re: Bitmap heap scan performance
  • From: Rob Emery
• Re: Postgres not using correct indices for views.
  • From: Tom Lane
• Re: Postgres not using correct indices for views.
  • From: Michaeldba@xxxxxxxxxxx
• Re: Postgres not using correct indices for views.
  • From: Thomas Rosenstein
• Re: Postgres not using correct indices for views.
  • From: Tom Lane
• Re: Bitmap heap scan performance
  • From: Jeff Janes
• Bitmap heap scan performance
  • From: Rob Emery
• Re: Postgres not using correct indices for views.
  • From: Tom Lane
• Re: Postgres not using correct indices for views.
  • From: Thomas Rosenstein
• Re: Postgres not using correct indices for views.
  • From: Thomas Rosenstein
• Re: Postgres not using correct indices for views.
  • From: Tom Lane
• Postgres not using correct indices for views.
  • From: Thomas Rosenstein
• Re: improving windows functions performance
  • From: Andreas Kretschmer
• improving windows functions performance
  • From: Mariel Cherkassky
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Thomas Kellerer
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: MichaelDBA
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Tom Lane
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Andreas Kretschmer
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Thomas Kellerer
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: Andreas Kretschmer
• Re: Strange runtime partition pruning behaviour with 11.4
  • From: MichaelDBA
• Strange runtime partition pruning behaviour with 11.4
  • From: Thomas Kellerer
• Re: PSQL performance - TPS
  • From: Imre Samu
• Re: PSQL performance - TPS
  • From: Shital A
• Re: PSQL performance - TPS
  • From: Rick Otten
• Re: PSQL performance - TPS
  • From: Andres Freund
• Re: PSQL performance - TPS
  • From: Purav Chovatia
• Re: PSQL performance - TPS
  • From: Andres Freund
• Re: PSQL performance - TPS
  • From: Shital A
• Re: PSQL performance - TPS
  • From: Gavin Flower
• PSQL performance - TPS
  • From: Shital A
• Re: Oracle to postgres migration via ora2pg (blob data)
  • From: Gilles Darold
• Re: Oracle to postgres migration via ora2pg (blob data)
  • From: Amol Tarte
• SV: Oracle to postgres migration via ora2pg (blob data)
  • From: Niels Jespersen
• Oracle to postgres migration via ora2pg (blob data)
  • From: Daulat Ram
• Re: A question regarding streaming replication
  • From: Holger Jakobs
• A question regarding streaming replication
  • From: Mariel Cherkassky
• Re: High concurrency same row (inventory)
  • From: Jean Baro
• Re: High concurrency same row (inventory)
  • From: MichaelDBA
• Re: High concurrency same row (inventory)
  • From: Jean Baro
• Re: High concurrency same row (inventory)
  • From: Jean Baro
• Re: High concurrency same row (inventory)
  • From: Jean Baro
• Re: High concurrency same row (inventory)
  • From: Michael Lewis
• Partial join
  • From: Arne Roland
• Re: High concurrency same row (inventory)
  • From: Jean Baro
• Re: High concurrency same row (inventory)
  • From: MichaelDBA
• Re: High concurrency same row (inventory)
  • From: Jayadevan M
• Re: High concurrency same row (inventory)
  • From: Rick Otten
• Re: Standard uuid vs. custom data type uuid_v1
  • From: Ancoron Luciferis
• High concurrency same row (inventory)
  • From: Jean Baro
• Re: Standard uuid vs. custom data type uuid_v1
  • From: Tomas Vondra
• Standard uuid vs. custom data type uuid_v1
  • From: Ancoron Luciferis
• Re: zabbix on postgresql - very slow delete of events
  • From: Maxim Boguk
• Re: zabbix on postgresql - very slow delete of events
  • From: Kristian Ejvind
• Re: zabbix on postgresql - very slow delete of events
  • From: Maxim Boguk
• Re: zabbix on postgresql - very slow delete of events
  • From: Maxim Boguk
• Re: zabbix on postgresql - very slow delete of events
  • From: Kristian Ejvind
• Re: zabbix on postgresql - very slow delete of events
  • From: Kenneth Marshall
• Re: zabbix on postgresql - very slow delete of events
  • From: Kristian Ejvind
• Re: zabbix on postgresql - very slow delete of events
  • From: Kenneth Marshall
• zabbix on postgresql - very slow delete of events
  • From: Kristian Ejvind
• Re: Speeding up query pulling comments from pg_catalog
  • From: Tom Lane
• Re: benchmarking effective_io_concurrency
  • From: Merlin Moncure
• Re: Speeding up query pulling comments from pg_catalog
  • From: Ken Tanzer
• Re: benchmarking effective_io_concurrency
  • From: Fabio Pardi
• Re: benchmarking effective_io_concurrency
  • From: Rick Otten
• benchmarking effective_io_concurrency
  • From: Fabio Pardi
• Re: Speeding up query pulling comments from pg_catalog
  • From: Tom Lane
• Re: Speeding up query pulling comments from pg_catalog
  • From: Ken Tanzer
• Re: Speeding up query pulling comments from pg_catalog
  • From: Tom Lane
• Speeding up query pulling comments from pg_catalog
  • From: Ken Tanzer
• Re: Searching in varchar column having 100M records
  • From: mgbii bax
• Re: Searching in varchar column having 100M records
  • From: Tomas Vondra
• Re: Searching in varchar column having 100M records
  • From: Michael Lewis
• Re: Searching in varchar column having 100M records
  • From: mayank rupareliya
• Re: Perplexing, regular decline in performance
  • From: Andres Freund
• Re: Searching in varchar column having 100M records
  • From: Gavin Flower
• Re: Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: Searching in varchar column having 100M records
  • From: Tomas Vondra
• Re: Searching in varchar column having 100M records
  • From: mayank rupareliya
• Re: Searching in varchar column having 100M records
  • From: Gavin Flower
• Re: Perplexing, regular decline in performance
  • From: Andres Freund
• Re: Perplexing, regular decline in performance
  • From: Alvaro Herrera
• Re: Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: Searching in varchar column having 100M records
  • From: David G. Johnston
• Re: Searching in varchar column having 100M records
  • From: Andreas Kretschmer
• Re: Searching in varchar column having 100M records
  • From: Tomas Vondra
• Re: Searching in varchar column having 100M records
  • From: Sergei Kornilov
• Searching in varchar column having 100M records
  • From: mayank rupareliya
• Re: Filtering on an enum field in a foreign table
  • From: Vladimir Ryabtsev
• Re: Filtering on an enum field in a foreign table
  • From: Vladimir Ryabtsev
• Re: Filtering on an enum field in a foreign table
  • From: Nikolay Samokhvalov
• Filtering on an enum field in a foreign table
  • From: Vladimir Ryabtsev
• Re: Optimizing `WHERE x IN` query
  • From: Michael Lewis
• Re: Optimizing `WHERE x IN` query
  • From: Omar Roth
• Re: Custom opclass for column statistics?
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: Optimizing `WHERE x IN` query
  • From: Nicolas Charles
• Re: Optimizing `WHERE x IN` query
  • From: Omar Roth
• Re: UUID v1 optimizations...
  • From: Peter Geoghegan
• Re: Custom opclass for column statistics?
  • From: Tom Lane
• Re: Optimizing `WHERE x IN` query
  • From: Thomas Kellerer
• Optimizing `WHERE x IN` query
  • From: Omar Roth
• Re: Custom opclass for column statistics?
  • From: Ancoron Luciferis
• Re: Custom opclass for column statistics?
  • From: Tomas Vondra
• Re: Custom opclass for column statistics?
  • From: Ancoron Luciferis
• Re: Custom opclass for column statistics?
  • From: Tomas Vondra
• Custom opclass for column statistics?
  • From: Ancoron Luciferis
• Re: Perplexing, regular decline in performance
  • From: Justin Pryzby
• Re: scans on table fail to be excluded by partition bounds
  • From: David Rowley
• Re: Perplexing, regular decline in performance
  • From: Tom Lane
• Re: Perplexing, regular decline in performance
  • From: Alvaro Herrera
• Re: Perplexing, regular decline in performance
  • From: Peter Geoghegan
• Re: Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: Perplexing, regular decline in performance
  • From: Peter Geoghegan
• Re: Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: scans on table fail to be excluded by partition bounds
  • From: Justin Pryzby
• RE: Max_connections limit
  • From: Igor Neyman
• Re: Incorrect index used in few cases..
  • From: AminPG Jaffer
• Re: Max_connections limit
  • From: Rick Otten
• Re: Max_connections limit
  • From: Hervé Schweitzer (HER)
• Re: Max_connections limit
  • From: Laurenz Albe
• Max_connections limit
  • From: Daulat Ram
• Re: Perplexing, regular decline in performance
  • From: Justin Pryzby
• Re: Perplexing, regular decline in performance
  • From: Benjamin Scherrey
• Re: Perplexing, regular decline in performance
  • From: Justin Pryzby
• Re: Perplexing, regular decline in performance
  • From: Benjamin Scherrey
• Perplexing, regular decline in performance
  • From: Hugh Ranalli
• Re: materialized view refresh of a foreign table
  • From: Rick Otten
• RE: scans on table fail to be excluded by partition bounds
  • From: Steven Winfield
• scans on table fail to be excluded by partition bounds
  • From: Justin Pryzby
• Re: Incorrect index used in few cases..
  • From: AminPG Jaffer
• monitoring tuple_count vs dead_tuple_count
  • From: Mariel Cherkassky
• materialized view refresh of a foreign table
  • From: Rick Otten
• Using indexes in RLS policies (sub)queries
  • From: Grégory EL MAJJOUTI
• RE: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Chris Wilson
• RE: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Chris Wilson
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Simon Riggs
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Michael Lewis
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Justin Pryzby
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Michael Lewis
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Simon Riggs
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Justin Pryzby
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Simon Riggs
• RE: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Chris Wilson
• Re: EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Simon Riggs
• EXPLAIN ANALYZE of BRIN bitmap index scan with disjunction
  • From: Chris Wilson
• Re: Incorrect index used in few cases..
  • From: Tom Lane
• Re: Incorrect index used in few cases..
  • From: Andres Freund
• Re: Incorrect index used in few cases..
  • From: Peter Geoghegan
• Re: Incorrect index used in few cases..
  • From: Tom Lane
• Re: Incorrect index used in few cases..
  • From: AminPG Jaffer
• Re: Incorrect index used in few cases..
  • From: Tom Lane
• Incorrect index used in few cases..
  • From: AminPG Jaffer
• Re: wal_log_hints benchmarks
  • From: Fabio Pardi
• Re: wal_log_hints benchmarks
  • From: Michael Paquier
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Stephen Frost
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Stephen Frost
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Bruce Momjian
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Bruce Momjian
• wal_log_hints benchmarks
  • From: Fabio Pardi
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Fabio Pardi
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Bruce Momjian
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: Strange query behaviour between 9.4 and 12beta1
  • From: Tomas Vondra
• Re: Shortest offline window on database migration
  • From: Stephen Frost
• Strange query behaviour between 9.4 and 12beta1
  • From: Vasilis Ventirozos
• Re: Shortest offline window on database migration
  • From: Haroldo Kerry
• Re: Sv: JIT in PostgreSQL 12 ?
  • From: Justin Pryzby
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• Re: Shortest offline window on database migration
  • From: Fabio Pardi
• Re: Shortest offline window on database migration
  • From: Ian Lawrence Barwick
• Re: Shortest offline window on database migration
  • From: Jeff Janes
• Re: Shortest offline window on database migration
  • From: Haroldo Kerry
• Re: Shortest offline window on database migration
  • From: Haroldo Kerry
• RE: Shortest offline window on database migration
  • From: Steven Winfield
• Re: Shortest offline window on database migration
  • From: Tomas Vondra
• Shortest offline window on database migration
  • From: Haroldo Kerry
• Re: improve wals replay on secondary
  • From: Mariel Cherkassky
• Re: improve wals replay on secondary
  • From: Nikolay Samokhvalov
• Re: JIT in PostgreSQL 12 ?
  • From: Andreas Karlsson
• Re: Sv: JIT in PostgreSQL 12 ?
  • From: Andreas Joseph Krogh
• Re: Sv: JIT in PostgreSQL 12 ?
  • From: Tobias Gierke
• Sv: JIT in PostgreSQL 12 ?
  • From: Andreas Joseph Krogh
• Re: improve wals replay on secondary
  • From: Mariel Cherkassky
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• JIT in PostgreSQL 12 ?
  • From: Tobias Gierke
• Re: improve wals replay on secondary
  • From: Mariel Cherkassky
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• Re: improve wals replay on secondary
  • From: Mariel Cherkassky
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• Re: improve wals replay on secondary
  • From: Fabio Pardi
• improve wals replay on secondary
  • From: Mariel Cherkassky
• Re: UUID v1 optimizations...
  • From: Morris de Oryx
• Re: UUID v1 optimizations...
  • From: Morris de Oryx
• Re: UUID v1 optimizations...
  • From: Tomas Vondra
• Re: UUID v1 optimizations...
  • From: Morris de Oryx
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Morris de Oryx
• Re: UUID v1 optimizations...
  • From: Tomas Vondra
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Tomas Vondra
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Tom Lane
• Re: UUID v1 optimizations...
  • From: Tomas Vondra
• Re: UUID v1 optimizations...
  • From: Tom Lane
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Vitalii Tymchyshyn
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: UUID v1 optimizations...
  • From: Tom Lane
• Re: UUID v1 optimizations...
  • From: Peter Eisentraut
• UUID v1 optimizations...
  • From: Ancoron Luciferis
• Re: Use Postgres as a column store by creating one table per column
  • From: Mark Kirkwood
• Re: Use Postgres as a column store by creating one table per column
  • From: Stephen Frost
• Re: Use Postgres as a column store by creating one table per column
  • From: Tomas Vondra
• Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Tom Lane
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Stephen Frost
• Re: Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Fabio Pardi
• RE: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Greg Clough
• Fwd: upgrade to PG11 on secondary fails (no initdb was launched)
  • From: Mariel Cherkassky
• RE: Re: Generic Plans for Prepared Statement are 158155 times slower than Custom Plans
  • From: Naik, Sameer
• Re: Analyze results in more expensive query plan
  • From: Jeremy Altavilla
• Re: Use Postgres as a column store by creating one table per column
  • From: George Neuner
• Re: pg_restore takes more time on creation of rules
  • From: Tomas Vondra
• Re: pg_restore takes more time on creation of rules
  • From: Mariel Cherkassky
• Re: pg_restore takes more time on creation of rules
  • From: Tomas Vondra
• 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