Postgres Performance Date Index

• Thread Index

• Re: Query performance issue
  • From: Thomas Kellerer
• Query performance issue
  • From: Nagaraj Raj
• Re: Too few rows expected by Planner on partitioned tables
  • From: Michael Lewis
• Re: Too few rows expected by Planner on partitioned tables
  • From: Julian Wolf
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jeff Janes
• Re: sizing / capacity planning tipps related to expected request or transactions per second
  • From: Pavel Stehule
• Re: sizing / capacity planning tipps related to expected request or transactions per second
  • From: MichaelDBA
• sizing / capacity planning tipps related to expected request or transactions per second
  • From: Dirk Krautschick
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Thomas Munro
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: David Rowley
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: Replication lag due to lagging restart_lsn
  • From: Kiran Singh
• Re: Replication lag due to lagging restart_lsn
  • From: Kyotaro Horiguchi
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Laurenz Albe
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Henrique Montenegro
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Michael Lewis
• CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
  • From: Jim Jarvie
• Replication lag due to lagging restart_lsn
  • From: Satyam Shekhar
• Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
  • From: Justin Pryzby
• Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
  • From: Jeff Janes
• Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
  • From: Ken Tanzer
• Re: Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
  • From: Justin Pryzby
• Query takes way longer with LIMIT, and EXPLAIN takes way longer than actual query
  • From: Ken Tanzer
• Re: Hstore index for full text search
  • From: Tom Lane
• Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?
  • From: Jim Jarvie
• Re: Hstore index for full text search
  • From: Michael Lewis
• Re: Hstore index for full text search
  • From: Tom Lane
• Re: Hstore index for full text search
  • From: Michael Lewis
• Hstore index for full text search
  • From: Burhan Akbulut
• Problems with Multixacts LWLocks
  • From: Czarek
• Re: Too few rows expected by Planner on partitioned tables
  • From: Julian Wolf
• Re: Too few rows expected by Planner on partitioned tables
  • From: Julian Wolf
• Re: Too few rows expected by Planner on partitioned tables
  • From: Justin Pryzby
• Re: Too few rows expected by Planner on partitioned tables
  • From: Justin Pryzby
• Re: Too few rows expected by Planner on partitioned tables
  • From: Justin Pryzby
• Too few rows expected by Planner on partitioned tables
  • From: Julian Wolf
• Re: Same query taking less time in low configuration machine
  • From: Vishwa Kalyankar
• Re: Same query taking less time in low configuration machine
  • From: Justin Pryzby
• Re: Same query taking less time in low configuration machine
  • From: Vishwa Kalyankar
• Re: Same query taking less time in low configuration machine
  • From: Justin Pryzby
• Same query taking less time in low configuration machine
  • From: Vishwa Kalyankar
• Re: Sudden insert performance degradation
  • From: Justin Pryzby
• Re: Sudden insert performance degradation
  • From: Henrique Montenegro
• Re: Sudden insert performance degradation
  • From: Henrique Montenegro
• Re: Sudden insert performance degradation
  • From: Sebastian Dressler
• Re: Sudden insert performance degradation
  • From: Henrique Montenegro
• Re: Sudden insert performance degradation
  • From: Henrique Montenegro
• Re: Sudden insert performance degradation
  • From: Henrique Montenegro
• Re: Sudden insert performance degradation
  • From: Jeff Janes
• Re: Sudden insert performance degradation
  • From: Henrique Montenegro
• Re: Sudden insert performance degradation
  • From: Sebastian Dressler
• Re: Sudden insert performance degradation
  • From: Henrique Montenegro
• Re: Sudden insert performance degradation
  • From: Henrique Montenegro
• Re: Sudden insert performance degradation
  • From: Michael Lewis
• Re: Sudden insert performance degradation
  • From: Sebastian Dressler
• Sudden insert performance degradation
  • From: Henrique Montenegro
• Re: Request to help on Query improvement suggestion.
  • From: Marlene Villanueva
• Re: Recommended value for pg_test_fsync
  • From: Bruce Momjian
• Re: Recommended value for pg_test_fsync
  • From: Nikhil Shetty
• Re: Recommended value for pg_test_fsync
  • From: Nikhil Shetty
• Re: Recommended value for pg_test_fsync
  • From: Haroldo Kerry
• Re: Recommended value for pg_test_fsync
  • From: Nikhil Shetty
• Re: Recommended value for pg_test_fsync
  • From: Nikhil Shetty
• Re: Recommended value for pg_test_fsync
  • From: Nikhil Shetty
• Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?
  • From: Gunther Schadow
• Re: Recommended value for pg_test_fsync
  • From: Jeff Janes
• Re: Recommended value for pg_test_fsync
  • From: Jeff Janes
• Re: Recommended value for pg_test_fsync
  • From: Bruce Momjian
• Re: Recommended value for pg_test_fsync
  • From: Nikhil Shetty
• Re: Recommended value for pg_test_fsync
  • From: Bruce Momjian
• Recommended value for pg_test_fsync
  • From: Nikhil Shetty
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Tom Lane
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Kenneth Marshall
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Alvaro Herrera
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Kenneth Marshall
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Tom Lane
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Tom Lane
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Kenneth Marshall
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Tom Lane
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Kenneth Marshall
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Tom Lane
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Kenneth Marshall
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Tom Lane
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Kenneth Marshall
• Re: Unclamped row estimates whith OR-ed subplans
  • From: Benjamin Coutu
• Re: PostgreSQL 12.3 slow index scan chosen
  • From: Tom Lane
• PostgreSQL 12.3 slow index scan chosen
  • From: Kenneth Marshall
• Re: Unclamped row estimates whith OR-ed subplans
  • From: Michael Lewis
• Re: Unclamped row estimates whith OR-ed subplans
  • From: Tom Lane
• Re: Unclamped row estimates whith OR-ed subplans
  • From: Benjamin Coutu
• Re: Unclamped row estimates whith OR-ed subplans
  • From: David G. Johnston
• Re: Unclamped row estimates whith OR-ed subplans
  • From: Tom Lane
• Re: Unclamped row estimates whith OR-ed subplans
  • From: Laurenz Albe
• Unclamped row estimates whith OR-ed subplans
  • From: Benjamin Coutu
• Re: simple query running for ever
  • From: Laurenz Albe
• Re: simple query running for ever
  • From: Justin Pryzby
• Re: simple query running for ever
  • From: Andreas Joseph Krogh
• Re: simple query running for ever
  • From: Justin Pryzby
• Re: simple query running for ever
  • From: Nagaraj Raj
• Re: simple query running for ever
  • From: Nagaraj Raj
• Re: simple query running for ever
  • From: Nagaraj Raj
• Re: simple query running for ever
  • From: Justin Pryzby
• Re: simple query running for ever
  • From: Michael Lewis
• simple query running for ever
  • From: Nagaraj Raj
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: regrog
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: Michael Lewis
• Re: Performance issue
  • From: Justin Pryzby
• Re: Performance issue
  • From: David Rowley
• Performance issue
  • From: Nagaraj Raj
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: Tom Lane
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: David Rowley
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: David Rowley
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: Pavel Stehule
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: Pavel Stehule
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: Pavel Stehule
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: Justin Pryzby
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: Tom Lane
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: David Rowley
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: David Rowley
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: Tom Lane
• Re: view reading information_schema is slow in PostgreSQL 12
  • From: Imre Samu
• view reading information_schema is slow in PostgreSQL 12
  • From: regrog
• Re: Windows slowness?
  • From: Mikkel Lauritsen
• Re: Windows slowness?
  • From: David Rowley
• Re: Windows slowness?
  • From: mountain the blue
• Windows slowness?
  • From: Mikkel Lauritsen
• Re: Postgresql server gets stuck at low load
  • From: Justin Pryzby
• Re: Postgresql server gets stuck at low load
  • From: Krzysztof Olszewski
• Re: Postgresql server gets stuck at low load
  • From: Avinash Kumar
• Re: Postgresql server gets stuck at low load
  • From: Krzysztof Olszewski
• Re: Postgresql server gets stuck at low load
  • From: Krzysztof Olszewski
• Re: When to use PARTITION BY HASH?
  • From: Michaeldba@xxxxxxxxxxx
• Re: When to use PARTITION BY HASH?
  • From: David Rowley
• Re: When to use PARTITION BY HASH?
  • From: MichaelDBA
• Re: Date vs Timestamp without timezone Partition Key
  • From: Cedric Leong
• Re: Date vs Timestamp without timezone Partition Key
  • From: David Rowley
• Re: Date vs Timestamp without timezone Partition Key
  • From: Cedric Leong
• Re: Date vs Timestamp without timezone Partition Key
  • From: David Rowley
• Re: Date vs Timestamp without timezone Partition Key
  • From: Cedric Leong
• Re: When to use PARTITION BY HASH?
  • From: Imre Samu
• Re: Postgresql server gets stuck at low load
  • From: Pavel Stehule
• Re: Postgresql server gets stuck at low load
  • From: luis . roberto
• Postgresql server gets stuck at low load
  • From: Krzysztof Olszewski
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Philip Semanchuk
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Sebastian Dressler
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Philip Semanchuk
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Sebastian Dressler
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Philip Semanchuk
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Magnus Hagander
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Tomas Vondra
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Luis Carril
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Sebastian Dressler
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Justin Pryzby
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Philip Semanchuk
• Re: increased max_parallel_workers_per_gather results in fewer workers?
  • From: Justin Pryzby
• increased max_parallel_workers_per_gather results in fewer workers?
  • From: Philip Semanchuk
• Re: When to use PARTITION BY HASH?
  • From: Justin Pryzby
• Re: When to use PARTITION BY HASH?
  • From: Oleksandr Shulgin
• Re: When to use PARTITION BY HASH?
  • From: Michel Pelletier
• Re: When to use PARTITION BY HASH?
  • From: David G. Johnston
• Re: When to use PARTITION BY HASH?
  • From: MichaelDBA
• Re: When to use PARTITION BY HASH?
  • From: Justin Pryzby
• When to use PARTITION BY HASH?
  • From: Oleksandr Shulgin
• Re: Configuration
  • From: Filip Rembiałkowski
• Configuration
  • From: sugnathi hai
• Re: Performance tunning
  • From: Jeff Janes
• Re: Performance tunning
  • From: Justin Pryzby
• Re: Performance tunning
  • From: Pavel Stehule
• Performance tunning
  • From: sugnathi hai
• Re: PostgreSQL performance problem moving from 9.6.17 to 12.3
  • From: Tom Lane
• PostgreSQL performance problem moving from 9.6.17 to 12.3
  • From: Kenneth Marshall
• Re: Request to help on Query improvement suggestion.
  • From: Laurenz Albe
• Re: Date vs Timestamp without timezone Partition Key
  • From: Tom Lane
• Date vs Timestamp without timezone Partition Key
  • From: Cedric Leong
• Strategy for materialisation and centralisation of data
  • From: Rory Campbell-Lange
• Re: Request to help on GIS Query improvement suggestion.
  • From: Michael Lewis
• Request to help on Query improvement suggestion.
  • From: devchef2020 d
• Request to help on GIS Query improvement suggestion.
  • From: postggen2020 s
• Re: Suggestion to improve query performance for GIS query.
  • From: postgann2020 s
• Re: Suggestion to improve query performance for GIS query.
  • From: Mohammed Afsar
• Re: Suggestion to improve query performance for GIS query.
  • From: David G. Johnston
• Suggestion to improve query performance for GIS query.
  • From: postgann2020 s
• Suggestion to improve query performance of data validation in proc.
  • From: postgann2020 s
• Re: Suggestion on index creation for TEXT data field
  • From: postgann2020 s
• Re: Suggestion on index creation for TEXT data field
  • From: David G. Johnston
• Re: Suggestion on table analyze
  • From: postgann2020 s
• Re: Suggestion on index creation for TEXT data field
  • From: Adrian Klaver
• Re: Suggestion on index creation for TEXT data field
  • From: postgann2020 s
• Re: Suggestion on table analyze
  • From: Adrian Klaver
• Re: Suggestion on index creation for TEXT data field
  • From: David G. Johnston
• Suggestion on index creation for TEXT data field
  • From: postgann2020 s
• Suggestion on table analyze
  • From: postgann2020 s
• Suggestion to improve query performance.
  • From: postgann2020 s
• Re: OOM Killer kills PostgreSQL
  • From: Stephen Frost
• Re: OOM Killer kills PostgreSQL
  • From: Justin Pryzby
• Re: OOM Killer kills PostgreSQL
  • From: Fabio Pardi
• Re: OOM Killer kills PostgreSQL
  • From: Piotr Włodarczyk
• Re: OOM Killer kills PostgreSQL
  • From: Laurenz Albe
• OOM Killer kills PostgreSQL
  • From: Piotr Włodarczyk
• Re: Execution time from >1s -> 80m+ when extra columns added in SELECT for sub-query
  • From: Tom Lane
• Re: Execution time from >1s -> 80m+ when extra columns added in SELECT for sub-query
  • From: A Guy Named Ryan
• Re: Execution time from >1s -> 80m+ when extra columns added in SELECT for sub-query
  • From: Pavel Stehule
• Execution time from >1s -> 80m+ when extra columns added in SELECT for sub-query
  • From: A Guy Named Ryan
• Re: Plan not skipping unnecessary inner join
  • From: Ranier Vilela
• Re: Plan not skipping unnecessary inner join
  • From: Justin Pryzby
• Re: Plan not skipping unnecessary inner join
  • From: Ranier Vilela
• Re: Plan not skipping unnecessary inner join
  • From: Matthew Nelson
• Re: Plan not skipping unnecessary inner join
  • From: David Wheeler
• Plan not skipping unnecessary inner join
  • From: Matthew Nelson
• Re: Please help! Query jumps from 1s -> 4m
  • From: James Thompson
• Re: Inaccurate Rows estimate for "Bitmap And" causes Planner to choose wrong join
  • From: Steve Pritchard
• Re: AutoVacuum and growing transaction XID's
  • From: github kran
• Re: 600 million rows of data. Bad hardware or need partitioning?
  • From: Arya F
• Re: AutoVacuum and growing transaction XID's
  • From: Michael Lewis
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: Jeff Janes
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: Jeff Janes
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: MichaelDBA
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: Avinash Kumar
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: Laurenz Albe
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: Avinash Kumar
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: Laurenz Albe
• Re: AutoVacuum and growing transaction XID's
  • From: github kran
• Re: AutoVacuum and growing transaction XID's
  • From: github kran
• Re: AutoVacuum and growing transaction XID's
  • From: David Rowley
• Re: AutoVacuum and growing transaction XID's
  • From: David Rowley
• Re: AutoVacuum and growing transaction XID's
  • From: github kran
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: David Rowley
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: David G. Johnston
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: Tom Lane
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: David G. Johnston
• Re: AutoVacuum and growing transaction XID's
  • From: github kran
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: Avinash Kumar
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: Rory Campbell-Lange
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: Avinash Kumar
• Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: David G. Johnston
• pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
  • From: samhitha g
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: Virendra Kumar
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: Adrian Klaver
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: Amarendra Konda
• Re: AutoVacuum and growing transaction XID's
  • From: Michael Lewis
• AutoVacuum and growing transaction XID's
  • From: github kran
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: Amarendra Konda
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: Amarendra Konda
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: Amarendra Konda
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: David G. Johnston
• Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: Adrian Klaver
• Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query )
  • From: Amarendra Konda
• Re: Inaccurate Rows estimate for "Bitmap And" causes Planner to choose wrong join
  • From: Jeff Janes
• Re: Inaccurate Rows estimate for "Bitmap And" causes Planner to choose wrong join
  • From: Justin Pryzby
• Inaccurate Rows estimate for "Bitmap And" causes Planner to choose wrong join
  • From: Steve Pritchard
• Re: 600 million rows of data. Bad hardware or need partitioning?
  • From: Justin Pryzby
• Re: 600 million rows of data. Bad hardware or need partitioning?
  • From: Arya F
• Re: 600 million rows of data. Bad hardware or need partitioning?
  • From: Arya F
• Re: Please help! Query jumps from 1s -> 4m
  • From: Tom Lane
• Re: Please help! Query jumps from 1s -> 4m
  • From: Justin Pryzby
• Re: Please help! Query jumps from 1s -> 4m
  • From: James Thompson
• Re: Please help! Query jumps from 1s -> 4m
  • From: Justin Pryzby
• Re: NUMA settings
  • From: Laurenz Albe
• Re: NUMA settings
  • From: Marc Rechté
• Re: Please help! Query jumps from 1s -> 4m
  • From: Laurenz Albe
• Re: NUMA settings
  • From: Laurenz Albe
• Re: NUMA settings
  • From: Marc Rechté
• Re: good book or any other resources for Postgresql
  • From: Bhupendra Babu
• Re: good book or any other resources for Postgresql
  • From: Craig Jackson
• Re: good book or any other resources for Postgresql
  • From: Michael Lewis
• good book or any other resources for Postgresql
  • From: Bhupendra Babu
• Re: Please help! Query jumps from 1s -> 4m
  • From: James Thompson
• Re: Please help! Query jumps from 1s -> 4m
  • From: David Rowley
• Re: Please help! Query jumps from 1s -> 4m
  • From: Justin Pryzby
• Re: Duplicate WHERE condition changes performance and plan
  • From: Michael Lewis
• Re: Recursive query slow on strange conditions
  • From: Jean-Christophe Boggio
• Re: NUMA settings
  • From: Andres Freund
• Re: Recursive query slow on strange conditions
  • From: David G. Johnston
• Re: Recursive query slow on strange conditions
  • From: Jean-Christophe Boggio
• Re: 600 million rows of data. Bad hardware or need partitioning?
  • From: Justin Pryzby
• Re: 600 million rows of data. Bad hardware or need partitioning?
  • From: David Rowley
• Re: 600 million rows of data. Bad hardware or need partitioning?
  • From: Arya F
• Re: 600 million rows of data. Bad hardware or need partitioning?
  • From: Michael Lewis
• 600 million rows of data. Bad hardware or need partitioning?
  • From: Arya F
• Re: Please help! Query jumps from 1s -> 4m
  • From: Justin Pryzby
• Please help! Query jumps from 1s -> 4m
  • From: James Thompson
• Re: Duplicate WHERE condition changes performance and plan
  • From: singh400@xxxxxxxxx
• Re: Best partition type for billions of addresses
  • From: Stephen Frost
• Re: Best partition type for billions of addresses
  • From: Arya F
• Re: Best partition type for billions of addresses
  • From: Stephen Frost
• Re: Best partition type for billions of addresses
  • From: Justin Pryzby
• Best partition type for billions of addresses
  • From: Arya F
• Re: The query plan get all columns but I'm using only one column.
  • From: Moises Lopez
• Re: The query plan get all columns but I'm using only one column.
  • From: Michael Lewis
• Re: The query plan get all columns but I'm using only one column.
  • From: Moises Lopez
• Re: The query plan get all columns but I'm using only one column.
  • From: Michael Lewis
• Re: NUMA settings
  • From: Laurenz Albe
• NUMA settings
  • From: Marc Rechté
• Re: Recursive query slow on strange conditions
  • From: Jean-Christophe Boggio
• Re: Recursive query slow on strange conditions
  • From: Andreas Joseph Krogh
• Re: Recursive query slow on strange conditions
  • From: Justin Pryzby
• Recursive query slow on strange conditions
  • From: Jean-Christophe Boggio
• Re: The query plan get all columns but I'm using only one column.
  • From: Michael Lewis
• Re: PostgreSQL does not choose my indexes well
  • From: Arcadio Ortega Reinoso
• Re: The query plan get all columns but I'm using only one column.
  • From: Tom Lane
• Re: PostgreSQL does not choose my indexes well
  • From: Stephen Frost
• The query plan get all columns but I'm using only one column.
  • From: Moises Lopez
• Re: PostgreSQL does not choose my indexes well
  • From: Jeff Janes
• Re: PostgreSQL does not choose my indexes well
  • From: Tom Lane
• Re: PostgreSQL does not choose my indexes well
  • From: Stephen Frost
• Re: PostgreSQL does not choose my indexes well
  • From: Jeff Janes
• Re: Duplicate WHERE condition changes performance and plan
  • From: singh400@xxxxxxxxx
• Re: PostgreSQL does not choose my indexes well
  • From: Arcadio Ortega Reinoso
• Re: PostgreSQL does not choose my indexes well
  • From: Tom Lane
• Re: PostgreSQL does not choose my indexes well
  • From: David G. Johnston
• Re: PostgreSQL does not choose my indexes well
  • From: Tom Lane
• Re: PostgreSQL does not choose my indexes well
  • From: Stephen Frost
• Re: PostgreSQL does not choose my indexes well
  • From: Tom Lane
• Re: PostgreSQL does not choose my indexes well
  • From: Stephen Frost
• Re: PostgreSQL does not choose my indexes well
  • From: Stephen Frost
• Re: PostgreSQL does not choose my indexes well
  • From: David G. Johnston
• Re: PostgreSQL does not choose my indexes well
  • From: Tom Lane
• Re: PostgreSQL does not choose my indexes well
  • From: Michael Lewis
• Re: PostgreSQL does not choose my indexes well
  • From: Tom Lane
• Re: PostgreSQL does not choose my indexes well
  • From: David G. Johnston
• Re: PostgreSQL does not choose my indexes well
  • From: Thomas Kellerer
• PostgreSQL does not choose my indexes well
  • From: Arcadio Ortega Reinoso
• RE: Postgres not using index on views
  • From: Rick Vincent
• Re: Duplicate WHERE condition changes performance and plan
  • From: Justin Pryzby
• Re: Duplicate WHERE condition changes performance and plan
  • From: singh400@xxxxxxxxx
• RE: Postgres not using index on views
  • From: Rick Vincent
• Postgres not using index on views
  • From: David G. Johnston
• RE: Postgres not using index on views
  • From: Rick Vincent
• Re: Duplicate WHERE condition changes performance and plan
  • From: David Rowley
• Using unlogged tables for web sessions
  • From: Stephen Carboni
• Duplicate WHERE condition changes performance and plan
  • From: singh400@xxxxxxxxx
• Re: High kswapd
  • From: Don Seiler
• Re: PostgreSQL DBA consulting
  • From: Amol Tarte
• Re: High kswapd
  • From: Justin Pryzby
• Re: High kswapd
  • From: Don Seiler
• Re: High kswapd
  • From: Justin Pryzby
• High kswapd
  • From: Don Seiler
• Re: High insert rate server, unstable insert latency and load peaks with buffer_content and XidGenLock LWlocks with Postgresql 12 version
  • From: Maxim Boguk
• Re: High insert rate server, unstable insert latency and load peaks with buffer_content and XidGenLock LWlocks with Postgresql 12 version
  • From: Justin Pryzby
• High insert rate server, unstable insert latency and load peaks with buffer_content and XidGenLock LWlocks with Postgresql 12 version
  • From: Maxim Boguk
• Re: PostgreSQL DBA consulting
  • From: Justin Pryzby
• PostgreSQL DBA consulting
  • From: daya airody
• Re: slow query
  • From: Michael Christofides
• Re: Postgres not using index on views
  • From: Thomas Kellerer
• Re: Postgres not using index on views
  • From: Thomas Kellerer
• RE: Postgres not using index on views
  • From: Rick Vincent
• RE: Postgres not using index on views
  • From: Rick Vincent
• Re: Postgres not using index on views
  • From: Laurenz Albe
• Re: Postgres not using index on views
  • From: Tom Lane
• Re: Postgres not using index on views
  • From: Justin Pryzby
• Postgres not using index on views
  • From: Rick Vincent
• Re: Postgresql 12, 512 partition by hash. Slow select
  • From: Neil
• Re: Postgresql 12, 512 partition by hash. Slow select
  • From: Arya F
• Re: Postgresql 12, 512 partition by hash. Slow select
  • From: Tom Lane
• Re: Postgresql 12, 512 partition by hash. Slow select
  • From: Andreas Kretschmer
• Postgresql 12, 512 partition by hash. Slow select
  • From: Arya F
• Re: BUG #16334: We recently upgraded PG version from 9.5 to 10.10 and system performance is not so good
  • From: Tejaswini GC
• Re: BUG #16334: We recently upgraded PG version from 9.5 to 10.10 and system performance is not so good
  • From: Julien Rouhaud
• Re: Increasing work_mem slows down query, why?
  • From: Silvio Moioli
• Re: slow query
  • From: dangal
• Re: slow query
  • From: Justin Pryzby
• slow query
  • From: dangal
• Re: Could someone please help us share the procedure to troubleshoot the locks on proc issues.
  • From: postgann2020 s
• Re: Could someone please help us share the procedure to troubleshoot the locks on proc issues.
  • From: Adrian Klaver
• Could someone please help us share the procedure to troubleshoot the locks on proc issues.
  • From: postgann2020 s
• Re: BUG #16334: We recently upgraded PG version from 9.5 to 10.10 and system performance is not so good
  • From: Tejaswini GC
• Re: BUG #16334: We recently upgraded PG version from 9.5 to 10.10 and system performance is not so good
  • From: Julien Rouhaud
• Re: BUG #16334: We recently upgraded PG version from 9.5 to 10.10 and system performance is not so good
  • From: Tejaswini GC
• Re: BUG #16334: We recently upgraded PG version from 9.5 to 10.10 and system performance is not so good
  • From: Julien Rouhaud
• Re: Increasing work_mem slows down query, why?
  • From: Pavel Stehule
• Re: Increasing work_mem slows down query, why?
  • From: Tom Lane
• Re: Increasing work_mem slows down query, why?
  • From: Pavel Stehule
• Re: Increasing work_mem slows down query, why?
  • From: Tom Lane
• Re: Increasing work_mem slows down query, why?
  • From: Pavel Stehule
• Re: Increasing work_mem slows down query, why?
  • From: Pavel Stehule
• Re: Increasing work_mem slows down query, why?
  • From: Silvio Moioli
• Re: Increasing work_mem slows down query, why?
  • From: Pavel Stehule
• Re: Increasing work_mem slows down query, why?
  • From: Silvio Moioli
• Re: Increasing work_mem slows down query, why?
  • From: Pavel Stehule
• Increasing work_mem slows down query, why?
  • From: Silvio Moioli
• Re: Best way to delete big amount of records from big table
  • From: Laurenz Albe
• Re: JOIN on partitions is very slow
  • From: daya airody
• Re: Best way to delete big amount of records from big table
  • From: Ekaterina Amez
• Re: Best way to delete big amount of records from big table
  • From: Justin Pryzby
• Re: Best way to delete big amount of records from big table
  • From: Rick Otten
• Re: Best way to delete big amount of records from big table
  • From: Ekaterina Amez
• Re: Best way to delete big amount of records from big table
  • From: Ekaterina Amez
• Re: Best way to delete big amount of records from big table
  • From: Laurenz Albe
• Re: Best way to delete big amount of records from big table
  • From: Michael Lewis
• Best way to delete big amount of records from big table
  • From: Ekaterina Amez
• Re: Slow planning time when public schema included (12 vs. 9.4)
  • From: Anders Steinlein
• Re: Random function
  • From: David G. Johnston
• Re: Random function
  • From: Tom Lane
• Random function
  • From: Luis Roberto Weck
• Re: JOIN on partitions is very slow
  • From: Thomas Kellerer
• Re: JOIN on partitions is very slow
  • From: Michael Lewis
• Re: Partition Pruning (Hash Partitions) Support for DELETEs in PostgreSQL 11 and 12
  • From: Ronnie S
• Re: JOIN on partitions is very slow
  • From: daya airody
• Re: Partition Pruning (Hash Partitions) Support for DELETEs in PostgreSQL 11 and 12
  • From: Justin Pryzby
• Partition Pruning (Hash Partitions) Support for DELETEs in PostgreSQL 11 and 12
  • From: Ronnie S
• Re: Partitions to improve write/update speed for tables with indexes?
  • From: Justin Pryzby
• Partitions to improve write/update speed for tables with indexes?
  • From: Arya F
• Re: JOIN on partitions is very slow
  • From: Michael Lewis
• JOIN on partitions is very slow
  • From: daya airody
• Re: Slow planning time when public schema included (12 vs. 9.4)
  • From: Tom Lane
• Re: Slow planning time when public schema included (12 vs. 9.4)
  • From: Anders Steinlein
• Re: Slow planning time when public schema included (12 vs. 9.4)
  • From: Tom Lane
• Re: Slow planning time when public schema included (12 vs. 9.4)
  • From: Anders Steinlein
• Re: Slow planning time when public schema included (12 vs. 9.4)
  • From: Anders Steinlein
• Re: Slow planning time when public schema included (12 vs. 9.4)
  • From: Tom Lane
• Re: Slow planning time when public schema included (12 vs. 9.4)
  • From: Andreas Kretschmer
• Slow planning time when public schema included (12 vs. 9.4)
  • From: Anders Steinlein
• Re: Slow ext'd query via client native implementation vs. libpq & simple psql
  • From: Justin Pryzby
• Re: Slow ext'd query via client native implementation vs. libpq & simple psql
  • From: Tom Lane
• Re: Slow ext'd query via client native implementation vs. libpq & simple psql
  • From: Justin Pryzby
• Slow ext'd query via client native implementation vs. libpq & simple psql
  • From: Richard Michael
• Re: pg12 partitions show bad performance vs pg96
  • From: David Rowley
• Re: pg12 partitions show bad performance vs pg96
  • From: Mariel Cherkassky
• Re: pg12 partitions show bad performance vs pg96
  • From: Mariel Cherkassky
• Re: pg12 partitions show bad performance vs pg96
  • From: Justin Pryzby
• Re: pg12 partitions show bad performance vs pg96
  • From: Mariel Cherkassky
• Re: pg12 partitions show bad performance vs pg96
  • From: Mariel Cherkassky
• Re: pg12 partitions show bad performance vs pg96
  • From: Justin Pryzby
• Re: pg12 partitions show bad performance vs pg96
  • From: David Rowley
• Re: pg12 partitions show bad performance vs pg96
  • From: Mariel Cherkassky
• pg12 partitions show bad performance vs pg96
  • From: Mariel Cherkassky
• Re: Many DataFileRead - IO waits
  • From: legrand legrand
• Re: Many DataFileRead - IO waits
  • From: Ben Snaidero
• Re: Many DataFileRead - IO waits
  • From: Ben Snaidero
• Re: Many DataFileRead - IO waits
  • From: Jeff Janes
• Re: Many DataFileRead - IO waits
  • From: legrand legrand
• Re: Many DataFileRead - IO waits
  • From: Ben Snaidero
• Re: Many DataFileRead - IO waits
  • From: Michael Lewis
• Re: Many DataFileRead - IO waits
  • From: Ben Snaidero
• Re: Many DataFileRead - IO waits
  • From: Michael Lewis
• Many DataFileRead - IO waits
  • From: Ben Snaidero
• Re: much slower query in production
  • From: Guillaume Cottenceau
• Re: much slower query in production
  • From: Jeff Janes
• Re: much slower query in production
  • From: Jeff Janes
• Re: much slower query in production
  • From: Guillaume Cottenceau
• Re: much slower query in production
  • From: MichaelDBA@xxxxxxxxxxx
• Re: much slower query in production
  • From: Michael Lewis
• Re: much slower query in production
  • From: Guillaume Cottenceau
• Re: much slower query in production
  • From: Guillaume Cottenceau
• Re: much slower query in production
  • From: Michael Lewis
• Re: much slower query in production
  • From: Justin Pryzby
• much slower query in production
  • From: Guillaume Cottenceau
• Connections dropping while using Postgres backend DB with Ejabberd
  • From: Dipanjan Ganguly
• Re: LDAP with TLS is taking more time in Postgresql 11.5
  • From: Laurenz Albe
• Re: LDAP with TLS is taking more time in Postgresql 11.5
  • From: Adrian Klaver
• LDAP with TLS is taking more time in Postgresql 11.5
  • From: Mani Sankar
• Re: PostgreSQL 11 higher Planning time on Partitioned table
  • From: Ravi Garg
• Re: PostgreSQL 11 higher Planning time on Partitioned table
  • From: Ravi Garg
• Re: DB running out of memory issues after upgrade
  • From: Merlin Moncure
• Re: PostgreSQL 11 higher Planning time on Partitioned table
  • From: Imre Samu
• Re: PostgreSQL 11 higher Planning time on Partitioned table
  • From: Justin Pryzby
• Re: PostgreSQL 11 higher Planning time on Partitioned table
  • From: Ravi Garg
• Re: PostgreSQL 11 higher Planning time on Partitioned table
  • From: Justin Pryzby
• Re: PostgreSQL 11 higher Planning time on Partitioned table
  • From: Justin Pryzby
• PostgreSQL 11 higher Planning time on Partitioned table
  • From: Ravi Garg
• RE: Can we have multiple tablespaces with in a database.
  • From: Daulat Ram
• RE: Can we have multiple tablespaces with in a database.
  • From: Patrick FICHE
• RE: Can we have multiple tablespaces with in a database.
  • From: Daulat Ram
• Re: Can we have multiple tablespaces with in a database.
  • From: amul sul
• RE: Can we have multiple tablespaces with in a database.
  • From: Daulat Ram
• Re: Can we have multiple tablespaces with in a database.
  • From: amul sul
• RE: Can we have multiple tablespaces with in a database.
  • From: Daulat Ram
• Re: Can we have multiple tablespaces with in a database.
  • From: David G. Johnston
• Re: Can we have multiple tablespaces with in a database.
  • From: amul sul
• Can we have multiple tablespaces with in a database.
  • From: Daulat Ram
• Re: tablespace to benefit from ssd ?
  • From: Jeff Janes
• Re: SubtransControlLock and performance problems
  • From: Lars Aksel Opsahl
• Re: How to avoid UPDATE performance degradation in a transaction
  • From: Andres Freund
• Re: SubtransControlLock and performance problems
  • From: Alvaro Herrera
• Re: tablespace to benefit from ssd ?
  • From: Justin Pryzby
• Re: SubtransControlLock and performance problems
  • From: Lars Aksel Opsahl
• Re: tablespace to benefit from ssd ?
  • From: Laurenz Albe
• Re: tablespace to benefit from ssd ?
  • From: Sebastiaan Mannem
• tablespace to benefit from ssd ?
  • From: Nicolas PARIS
• Re: SubtransControlLock and performance problems
  • From: Pavel Stehule
• Re: DB running out of memory issues after upgrade
  • From: Nagaraj Raj
• Re: DB running out of memory issues after upgrade
  • From: Merlin Moncure
• Re: DB running out of memory issues after upgrade
  • From: Justin Pryzby
• Re: DB running out of memory issues after upgrade
  • From: Merlin Moncure
• Re: DB running out of memory issues after upgrade
  • From: Nagaraj Raj
• Re: DB running out of memory issues after upgrade
  • From: Tomas Vondra
• DB running out of memory issues after upgrade
  • From: Nagaraj Raj
• Re: SubtransControlLock and performance problems
  • From: Laurenz Albe
• Re: SubtransControlLock and performance problems
  • From: Alvaro Herrera
• Re: SubtransControlLock and performance problems
  • From: Pavel Stehule
• Re: SubtransControlLock and performance problems
  • From: Tom Lane
• Re: SubtransControlLock and performance problems
  • From: Pavel Stehule
• Re: SubtransControlLock and performance problems
  • From: Laurenz Albe
• Re: SubtransControlLock and performance problems
  • From: Lars Aksel Opsahl
• Re: SubtransControlLock and performance problems
  • From: Laurenz Albe
• Re: Partial index creation always scans the entire table
  • From: Tom Lane
• Re: Partial index creation always scans the entire table
  • From: Justin Pryzby
• RE: Partial index creation always scans the entire table
  • From: Mike Sofen
• Re: Partial index creation always scans the entire table
  • From: Tom Lane
• Re: Partial index creation always scans the entire table
  • From: Tom Lane
• Re: Partial index creation always scans the entire table
  • From: Justin Pryzby
• SubtransControlLock and performance problems
  • From: Lars Aksel Opsahl
• Re: Partial index creation always scans the entire table
  • From: Laurenz Albe
• Re: Partial index creation always scans the entire table
  • From: Justin Pryzby
• Re: Partial index creation always scans the entire table
  • From: Sergei Kornilov
• Partial index creation always scans the entire table
  • From: MingJu Wu
• Re: How to avoid UPDATE performance degradation in a transaction
  • From: Michael Lewis
• Re: How to avoid UPDATE performance degradation in a transaction
  • From: Karl Düüna
• Re: How to avoid UPDATE performance degradation in a transaction
  • From: Tom Lane
• Re: How to avoid UPDATE performance degradation in a transaction
  • From: David G. Johnston
• How to avoid UPDATE performance degradation in a transaction
  • From: Karl Düüna
• Re: Bad selectivity estimate when using a sub query to determine WHERE condition
  • From: Chris Borckholder
• Re: Bad selectivity estimate when using a sub query to determine WHERE condition
  • From: Chris Borckholder
• Re: Writing 1100 rows per second
  • From: Amol Tarte
• Re: Bad selectivity estimate when using a sub query to determine WHERE condition
  • From: Justin Pryzby
• Re: Bad selectivity estimate when using a sub query to determine WHERE condition
  • From: Tom Lane
• Re: Fwd: TOAST table performance problem
  • From: Asya Nevra Buyuksoy
• Re: Fwd: TOAST table performance problem
  • From: Jeff Janes
• Re: Fwd: TOAST table performance problem
  • From: Asya Nevra Buyuksoy
• Re: Fwd: TOAST table performance problem
  • From: Luís Roberto Weck
• Bad selectivity estimate when using a sub query to determine WHERE condition
  • From: Chris Borckholder
• Fwd: TOAST table performance problem
  • From: Asya Nevra Buyuksoy
• Re: Writing 1100 rows per second
  • From: Jeff Janes
• Re: TOAST table performance problem
  • From: Andreas Joseph Krogh
• Re: TOAST table performance problem
  • From: Asya Nevra Buyuksoy
• Re: TOAST table performance problem
  • From: Andreas Joseph Krogh
• Re: TOAST table performance problem
  • From: Andreas Joseph Krogh
• Re: TOAST table performance problem
  • From: Asya Nevra Buyuksoy
• Re: TOAST table performance problem
  • From: MichaelDBA
• Re: TOAST table performance problem
  • From: Andreas Joseph Krogh
• Re: TOAST table performance problem
  • From: Asya Nevra Buyuksoy
• Re: TOAST table performance problem
  • From: Asya Nevra Buyuksoy
• Sv: TOAST table performance problem
  • From: Andreas Joseph Krogh
• TOAST table performance problem
  • From: Asya Nevra Buyuksoy
• Re: Writing 1100 rows per second
  • From: Ogden Brash
• Re: Slow performance with trivial self-joins
  • From: David Rowley
• Re: Slow performance with trivial self-joins
  • From: Adam Brusselback
• Re: Slow performance with trivial self-joins
  • From: Benny Kramek
• Re: Writing 1100 rows per second
  • From: Haroldo Kerry
• Re: Writing 1100 rows per second
  • From: Arya F
• Re: Writing 1100 rows per second
  • From: Justin Pryzby
• Re: Writing 1100 rows per second
  • From: Laurenz Albe
• Writing 1100 rows per second
  • From: Arya F
• Re: Slow performance with trivial self-joins
  • From: Tom Lane
• Slow performance with trivial self-joins
  • From: Benny Kramek
• Re: Statistics on array values
  • From: Marco Colli
• Re: Statistics on array values
  • From: Tom Lane
• Re: Statistics on array values
  • From: Marco Colli
• Re: Statistics on array values
  • From: Tom Lane
• Re: Statistics on array values
  • From: Marco Colli
• Re: Statistics on array values
  • From: Justin Pryzby
• Statistics on array values
  • From: Marco Colli
• Re: Specific query taking time to process
  • From: Duncan Whitham
• Re: Specific query taking time to process
  • From: Tom Lane
• Re: Specific query taking time to process
  • From: Duncan Whitham
• Re: Specific query taking time to process
  • From: Fahiz Mohamed
• Re: Query optimization advice for beginners
  • From: Laurenz Albe
• Re: Query optimization advice for beginners
  • From: Michael Lewis
• Re: Query optimization advice for beginners
  • From: Kemal Ortanca
• Re: Query optimization advice for beginners
  • From: Andreas Kretschmer
• Query optimization advice for beginners
  • From: Kemal Ortanca
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Cosmin Prund
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Cosmin Prund
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Tom Lane
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Michael Lewis
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Tom Lane
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Laurenz Albe
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Cosmin Prund
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Tom Lane
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Cosmin Prund
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Michael Lewis
• Re: Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Tom Lane
• Bad query plan decision when using multiple column index - postgresql uses only first column then filters
  • From: Cosmin Prund
• Queries in plpgsql are 6 times slower on partitioned tables
  • From: Marcin Barczyński
• Re: shared buffers and startup process
  • From: Michael Paquier
• shared buffers and startup process
  • From: Joao Junior
• Re: Bad query plan when you add many OR conditions
  • From: Thomas Kellerer
• Re: Seeking reason behind performance gain in 12 with HashAggregate
  • From: Shira Bezalel
• Re: Seeking reason behind performance gain in 12 with HashAggregate
  • From: Alvaro Herrera
• Re: Bad query plan when you add many OR conditions
  • From: Tomas Vondra
• Re: Seeking reason behind performance gain in 12 with HashAggregate
  • From: Shira Bezalel
• Re: Seeking reason behind performance gain in 12 with HashAggregate
  • From: Tomas Vondra
• Re: Seeking reason behind performance gain in 12 with HashAggregate
  • From: Shira Bezalel
• Re: Seeking reason behind performance gain in 12 with HashAggregate
  • From: Michael Lewis
• Re: Seeking reason behind performance gain in 12 with HashAggregate
  • From: Shira Bezalel
• Re: Seeking reason behind performance gain in 12 with HashAggregate
  • From: Justin Pryzby
• Seeking reason behind performance gain in 12 with HashAggregate
  • From: Shira Bezalel
• Re: Bad query plan when you add many OR conditions
  • From: Jeff Janes
• Re: Bad query plan when you add many OR conditions
  • From: Marco Colli
• Re: Bad query plan when you add many OR conditions
  • From: Tom Lane
• Re: Bad query plan when you add many OR conditions
  • From: Marco Colli
• Re: Bad query plan when you add many OR conditions
  • From: Justin Pryzby
• Re: Bad query plan when you add many OR conditions
  • From: Marco Colli
• Re: Bad query plan when you add many OR conditions
  • From: Marco Colli
• Re: Bad query plan when you add many OR conditions
  • From: Justin Pryzby
• Bad query plan when you add many OR conditions
  • From: Marco Colli
• Re: distinguish index cost component from table component
  • From: Justin Pryzby
• Re: distinguish index cost component from table component
  • From: Jeff Janes
• distinguish index cost component from table component
  • From: Justin Pryzby
• Re: Merge join doesn't seem to break early when I (and planner) think it should - 10.4
  • From: Jeff Janes
• Merge join doesn't seem to break early when I (and planner) think it should - 10.4
  • From: Timothy Garnett
• Re: How to set parallel_tuple_cost
  • From: Jeff Janes
• Re: How to set parallel_tuple_cost
  • From: Andres Freund
• Re: How to set parallel_tuple_cost
  • From: Tom Lane
• Re: How to set parallel_tuple_cost
  • From: Laurenz Albe
• How to set parallel_tuple_cost
  • From: Jeff Janes
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Shijia Wei
• Re: How to prevent POSTGRES killing linux system from accepting too much inserts?
  • From: Jeff Janes
• Re: How to prevent POSTGRES killing linux system from accepting too much inserts?
  • From: Merlin Moncure
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Tom Lane
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Laurenz Albe
• Re: shared memory size during upgrade pgsql with partitions (max_locks_per_transaction)
  • From: Piotr Włodarczyk
• How to prevent POSTGRES killing linux system from accepting too much inserts?
  • From: James(王旭)
• Re: weird long time query
  • From: Kaijiang Chen
• Re: shared memory size during upgrade pgsql with partitions (max_locks_per_transaction)
  • From: Justin Pryzby
• shared memory size during upgrade pgsql with partitions
  • From: Piotr Włodarczyk
• Re: weird long time query
  • From: Tom Lane
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Jeff Janes
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Laurenz Albe
• Re: weird long time query
  • From: Pavel Stehule
• weird long time query
  • From: Kaijiang Chen
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Andres Freund
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Sam Gendler
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Tom Lane
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Nicolas Charles
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Tom Lane
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Peter Geoghegan
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Pavel Stehule
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Shijia Wei
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Tom Lane
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Laurenz Albe
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Mariel Cherkassky
• RE: performance degredation after upgrade from 9.6 to 12
  • From: Andrew Zakharov
• Re: performance degredation after upgrade from 9.6 to 12
  • From: Mariel Cherkassky
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Olivier Gautherot
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Shijia Wei
• Re: Consecutive Query Executions with Increasing Execution Time
  • From: Olivier Gautherot
• Consecutive Query Executions with Increasing Execution Time
  • From: Shijia Wei
• Re: Legal disclaimers on emails to this group
  • From: Moreno Andreo
• Re: Legal disclaimers on emails to this group
  • From: Moreno Andreo
• Re: Specific query taking time to process
  • From: Jeff Janes
• Re: Specific query taking time to process
  • From: Fahiz Mohamed
• Re: Specific query taking time to process
  • From: Jeff Janes
• Re: Specific query taking time to process
  • From: Michael Lewis
• Re: unexpected result for wastedbytes query after vacuum full
  • From: Guillaume Lelarge
• Re: Specific query taking time to process
  • From: Justin Pryzby
• Re: Specific query taking time to process
  • From: Michael Lewis
• Re: unexpected result for wastedbytes query after vacuum full
  • From: Jeff Janes
• Re: unexpected result for wastedbytes query after vacuum full
  • From: Guillaume Lelarge
• Re: Specific query taking time to process
  • From: Fahiz Mohamed
• RE: unexpected result for wastedbytes query after vacuum full
  • From: Mike Schanne
• RE: Legal disclaimers on emails to this group
  • From: Mike Schanne
• Re: Logical replication performance
  • From: Jeff Janes
• Re: Specific query taking time to process
  • From: Michael Lewis
• Re: Specific query taking time to process
  • From: Justin Pryzby
• Specific query taking time to process
  • From: Fahiz Mohamed
• Re: How to run in parallel in Postgres, EXECUTE_PARALLEL
  • From: Lars Aksel Opsahl