Postgres Performance Date Index

• Thread Index

• Re: JIT overhead slowdown
  • From: Andres Freund
• JIT overhead slowdown
  • From: Luis Carril
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Alvaro Herrera
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Alvaro Herrera
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Alvaro Herrera
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Justin Pryzby
• autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: No matching tables have ever been vacuumed
  • From: Laurenz Albe
• Parallel stats in execution plans
  • From: David Conlin
• No matching tables have ever been vacuumed
  • From: Daulat Ram
• Re: Detect missing combined indexes (automatically)
  • From: Julien Rouhaud
• Re: Detect missing combined indexes (automatically)
  • From: Thomas Güttler
• Re: Detect missing combined indexes (automatically)
  • From: Julien Rouhaud
• Re: Detect missing combined indexes (automatically)
  • From: Thomas Kellerer
• Re: Detect missing combined indexes (automatically)
  • From: Jim Finnerty
• Re: does dml operations load the blocks to the shared buffers ?
  • From: Guillaume Lelarge
• Detect missing combined indexes (automatically)
  • From: Thomas Güttler
• Re: does dml operations load the blocks to the shared buffers ?
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Ken Tanzer
• Re: PostgreSQL Read IOPS limit per connection
  • From: Mark Hogg
• Re: does dml operations load the blocks to the shared buffers ?
  • From: Guillaume Lelarge
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• does dml operations load the blocks to the shared buffers ?
  • From: Mariel Cherkassky
• Re: PostgreSQL Read IOPS limit per connection
  • From: Merlin Moncure
• Re: PostgreSQL Read IOPS limit per connection
  • From: Haroldo Kerry
• Re: select query does not pick up the right index
  • From: Abadie Lana
• Re: PostgreSQL Read IOPS limit per connection
  • From: Merlin Moncure
• Re: select query does not pick up the right index
  • From: David Rowley
• Re: postgresql unix socket connections
  • From: Tom Lane
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Jeff Janes
• Re: postgresql unix socket connections
  • From: Jeff Janes
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Tom Lane
• RE: select query does not pick up the right index
  • From: Abadie Lana
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• postgresql unix socket connections
  • From: Mariel Cherkassky
• Re: select query does not pick up the right index
  • From: Justin Pryzby
• RE: select query does not pick up the right index
  • From: Abadie Lana
• Re: select query does not pick up the right index
  • From: Justin Pryzby
• RE: select query does not pick up the right index
  • From: Abadie Lana
• RE: select query does not pick up the right index
  • From: Abadie Lana
• RE: select query does not pick up the right index
  • From: Abadie Lana
• Re: select query does not pick up the right index
  • From: Justin Pryzby
• Re: select query does not pick up the right index
  • From: David Rowley
• RE: select query does not pick up the right index
  • From: Abadie Lana
• RE: select query does not pick up the right index
  • From: Abadie Lana
• Re: select query does not pick up the right index
  • From: David Rowley
• RE: select query does not pick up the right index
  • From: Abadie Lana
• Re: select query does not pick up the right index
  • From: David Rowley
• RE: select query does not pick up the right index
  • From: Abadie Lana
• RE: select query does not pick up the right index
  • From: Abadie Lana
• Re: select query does not pick up the right index
  • From: David Rowley
• Re: select query does not pick up the right index
  • From: Justin Pryzby
• select query does not pick up the right index
  • From: Abadie Lana
• Re: Need help with optimising simple query
  • From: Jim Finnerty
• Re: Need help with optimising simple query
  • From: Jim Finnerty
• Re: Query Performance Issue
  • From: David Rowley
• Re: Query Performance Issue
  • From: Jeff Janes
• Re: Gained %20 performance after disabling bitmapscan
  • From: Jim Finnerty
• Re: Optimizer choosing the wrong plan
  • From: Jeff Janes
• Re: Optimizer choosing the wrong plan
  • From: Jim Finnerty
• Re: Query Performance Issue
  • From: Jim Finnerty
• Re: Query Performance Issue
  • From: Justin Pryzby
• Re: Query Performance Issue
  • From: David Rowley
• Re: Query Performance Issue
  • From: Justin Pryzby
• Re: Query Performance Issue
  • From: Alexey Bashtanov
• Re: psql cli tool and connection pooling
  • From: Sebastiaan Mannem
• Re: PostgreSQL Read IOPS limit per connection
  • From: Justin Pryzby
• Re: PostgreSQL Read IOPS limit per connection
  • From: Jeff Janes
• Re: PostgreSQL Read IOPS limit per connection
  • From: Haroldo Kerry
• Query Performance Issue
  • From: neslişah demirci
• Re: PostgreSQL Read IOPS limit per connection
  • From: Justin Pryzby
• PostgreSQL Read IOPS limit per connection
  • From: Haroldo Kerry
• Re: SQL Perfomance during autovacuum
  • From: Jeff Janes
• psql cli tool and connection pooling
  • From: DJ Coertzen
• Re: database crash during pgbench run
  • From: Merlin Moncure
• Re: pgbench results arent accurate
  • From: Merlin Moncure
• Re: Why Postgres doesn't use TID scan?
  • From: Rick Otten
• Re: Why Postgres doesn't use TID scan?
  • From: Vladimir Ryabtsev
• Re: Why Postgres doesn't use TID scan?
  • From: Andrew Gierth
• Re: Why Postgres doesn't use TID scan?
  • From: Vladimir Ryabtsev
• Re: Why Postgres doesn't use TID scan?
  • From: Andrew Gierth
• Re: Increasing parallelism of queries while using file fdw and partitions
  • From: Patrick Mulrooney
• Re: Increasing parallelism of queries while using file fdw and partitions
  • From: Justin Pryzby
• Re: SQL Perfomance during autovacuum
  • From: David Rowley
• SQL Perfomance during autovacuum
  • From: anand086
• Increasing parallelism of queries while using file fdw and partitions
  • From: Patrick Mulrooney
• Re: Why Postgres doesn't use TID scan?
  • From: Alvaro Herrera
• Re: pgbench results arent accurate
  • From: Mark Kirkwood
• Re: Why Postgres doesn't use TID scan?
  • From: Vladimir Ryabtsev
• Re: Why Postgres doesn't use TID scan?
  • From: Tom Lane
• Re: Why Postgres doesn't use TID scan?
  • From: Vladimir Ryabtsev
• Re: Why Postgres doesn't use TID scan?
  • From: Tom Lane
• Why Postgres doesn't use TID scan?
  • From: Vladimir Ryabtsev
• Re: pgbench results arent accurate
  • From: Mariel Cherkassky
• Re: pgbench results arent accurate
  • From: Mark Kirkwood
• RE: pgbench results arent accurate
  • From: Greg Clough
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Nicolas Paris
• pgbench results arent accurate
  • From: Mariel Cherkassky
• RE: database crash during pgbench run
  • From: Greg Clough
• Re: Database size 1T but unclear why
  • From: Justin Pryzby
• Re: database crash during pgbench run
  • From: Tom Lane
• Re: database crash during pgbench run
  • From: Tom Lane
• database crash during pgbench run
  • From: Mariel Cherkassky
• Re: Database size 1T but unclear why
  • From: Justin Pryzby
• Re: Database size 1T but unclear why
  • From: Rick Otten
• Re: amazon aroura config - seriously overcommited defaults? (May be Off Topic)
  • From: Square Bob
• Database size 1T but unclear why
  • From: Mariel Cherkassky
• Re: amazon aroura config - seriously overcommited defaults? (May be Off Topic)
  • From: Andrew Dunstan
• Re: amazon aroura config - seriously overcommited defaults? (May be Off Topic)
  • From: Andres Freund
• Re: amazon aroura config - seriously overcommited defaults? (May be Off Topic)
  • From: Rob Sargent
• Re: amazon aroura config - seriously overcommited defaults? (May be Off Topic)
  • From: Andres Freund
• Re: amazon aroura config - seriously overcommited defaults? (May be Off Topic)
  • From: Jeremy Schneider
• Re: amazon aroura config - seriously overcommited defaults? (May be Off Topic)
  • From: Bob Lunney
• Fwd: amazon aroura config - seriously overcommited defaults? (May be Off Topic)
  • From: Square Bob
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Ashutosh Bapat
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Ashutosh Bapat
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Alvaro Herrera
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Alvaro Herrera
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Amit Langote
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Amit Langote
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Amit Langote
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Amit Langote
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Alvaro Herrera
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Alvaro Herrera
• Re: Slow Bitmap Index Scan
  • From: Alan Hodgson
• Re: Slow Bitmap Index Scan
  • From: Scott Rankin
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Pavel Stehule
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Sanyo Moura
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Oleg Bartunov
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Sanyo Moura
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Justin Pryzby
• Re: Slow Bitmap Index Scan
  • From: Scott Rankin
• Re: Slow Bitmap Index Scan
  • From: Justin Pryzby
• Slow Bitmap Index Scan
  • From: Scott Rankin
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Justin Pryzby
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: David Rowley
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Justin Pryzby
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Sanyo Moura
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Justin Pryzby
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Sanyo Moura
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Justin Pryzby
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Justin Pryzby
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Sanyo Moura
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Sanyo Moura
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Jeff Janes
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Sanyo Moura
• Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Tom Lane
• Query with high planning time at version 11.1 compared versions 10.5 and 11.0
  • From: Sanyo Moura
• Re: dsa_allocate() faliure
  • From: Alvaro Herrera
• Re: autovacuum run but last_autovacuum is empty
  • From: Tom Lane
• Re: dsa_allocate() faliure
  • From: Jakub Glapa
• Re: Optimizer choosing the wrong plan
  • From: Jeff Janes
• Re: dsa_allocate() faliure
  • From: Justin Pryzby
• Re: autovacuum run but last_autovacuum is empty
  • From: Mariel Cherkassky
• Re: dsa_allocate() faliure
  • From: Jakub Glapa
• Re: dsa_allocate() faliure
  • From: Jakub Glapa
• Re: autovacuum run but last_autovacuum is empty
  • From: Tom Lane
• autovacuum run but last_autovacuum is empty
  • From: Mariel Cherkassky
• Optimizer choosing the wrong plan
  • From: Viswanath
• Re: explain analyze faster then query
  • From: Justin Pryzby
• Re: explain analyze faster then query
  • From: Mariel Cherkassky
• Re: explain analyze faster then query
  • From: Justin Pryzby
• explain analyze faster then query
  • From: Mariel Cherkassky
• Re: Performance impact of updating target columns with unchanged values ON CONFLICT
  • From: Abi Noda
• Re: Performance impact of updating target columns with unchanged values ON CONFLICT
  • From: Abi Noda
• Re: dsa_allocate() faliure
  • From: Justin Pryzby
• Re: dsa_allocate() faliure
  • From: Jakub Glapa
• Re: Performance impact of updating target columns with unchanged values ON CONFLICT
  • From: Justin Pryzby
• Re: Performance impact of updating target columns with unchanged values ON CONFLICT
  • From: Abi Noda
• Performance impact of updating target columns with unchanged values ON CONFLICT
  • From: Abi Noda
• Re: dsa_allocate() faliure
  • From: Justin Pryzby
• Re: dsa_allocate() faliure
  • From: Jakub Glapa
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Thomas Kellerer
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Stephen Frost
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Merlin Moncure
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Stephen Frost
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Merlin Moncure
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Stephen Frost
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Merlin Moncure
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Fabio Pardi
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Stephen Frost
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Fabio Pardi
• Re: autovacuum is running but pg_stat_all_tables empty
  • From: Laurenz Albe
• autovacuum is running but pg_stat_all_tables empty
  • From: Mariel Cherkassky
• Re: PostgreSQL VS MongoDB: a use case comparison
  • From: Stephen Frost
• PostgreSQL VS MongoDB: a use case comparison
  • From: Fabio Pardi
• Re: checkpoint occurs very often when vacuum full running
  • From: Mariel Cherkassky
• Re: checkpoint occurs very often when vacuum full running
  • From: Justin Pryzby
• Re: checkpoint occurs very often when vacuum full running
  • From: Sergei Kornilov
• Re: checkpoint occurs very often when vacuum full running
  • From: Mariel Cherkassky
• Re: checkpoint occurs very often when vacuum full running
  • From: Sergei Kornilov
• checkpoint occurs very often when vacuum full running
  • From: Mariel Cherkassky
• Re: dsa_allocate() faliure
  • From: Jakub Glapa
• Re: NOT IN vs. NOT EXISTS performance
  • From: Lincoln Swaine-Moore
• Re: NOT IN vs. NOT EXISTS performance
  • From: Merlin Moncure
• Re: NOT IN vs. NOT EXISTS performance
  • From: David Rowley
• NOT IN vs. NOT EXISTS performance
  • From: Lincoln Swaine-Moore
• Re: Fwd: Query with high planning time compared to execution time
  • From: Richard Lee
• Re: Fwd: Query with high planning time compared to execution time
  • From: Justin Pryzby
• Re: Fwd: Query with high planning time compared to execution time
  • From: Richard Lee
• Re: Fwd: Query with high planning time compared to execution time
  • From: Justin Pryzby
• Re: Fwd: Query with high planning time compared to execution time
  • From: Richard Lee
• Re: Fwd: Query with high planning time compared to execution time
  • From: legrand legrand
• Re: Fwd: Query with high planning time compared to execution time
  • From: Tomas Vondra
• Fwd: Query with high planning time compared to execution time
  • From: Richard Lee
• Re: SCRAM question
  • From: Michael Paquier
• Re: High CPU Usage of "SET ROLE"
  • From: Jeff Janes
• Re: High CPU Usage of "SET ROLE"
  • From: Tom Lane
• Re: High CPU Usage of "SET ROLE"
  • From: Ulf Lohbrügge
• Re: SCRAM question
  • From: Joshua D. Drake
• SCRAM question
  • From: MichaelDBA
• Re: Indexes on UUID - Fragmentation Issue
  • From: Uday Bhaskar V
• Re: Indexes on UUID - Fragmentation Issue
  • From: MichaelDBA
• Re: Indexes on UUID - Fragmentation Issue
  • From: Andreas Karlsson
• Re: Indexes on UUID - Fragmentation Issue
  • From: Merlin Moncure
• Indexes on UUID - Fragmentation Issue
  • From: Uday Bhaskar V
• Re: DELETE / UPDATE from partition not optimized (11.0)
  • From: Justin Pryzby
• Re: Gained %20 performance after disabling bitmapscan
  • From: Jeff Janes
• Re: DELETE / UPDATE from partition not optimized (11.0)
  • From: Justin Pryzby
• DELETE / UPDATE from partition not optimized (11.0)
  • From: Dave E Martin
• Re: High CPU Usage of "SET ROLE"
  • From: Tom Lane
• High CPU Usage of "SET ROLE"
  • From: Ulf Lohbrügge
• Ynt: Gained %20 performance after disabling bitmapscan
  • From: Yavuz Selim Sertoglu
• Ynt: Gained %20 performance after disabling bitmapscan
  • From: Yavuz Selim Sertoglu
• Ynt: Gained %20 performance after disabling bitmapscan
  • From: Yavuz Selim Sertoglu
• Re: Gained %20 performance after disabling bitmapscan
  • From: Jeff Janes
• Re: Gained %20 performance after disabling bitmapscan
  • From: Vladimir Ryabtsev
• Re: Gained %20 performance after disabling bitmapscan
  • From: Tom Lane
• Re: Gained %20 performance after disabling bitmapscan
  • From: Justin Pryzby
• Gained %20 performance after disabling bitmapscan
  • From: Yavuz Selim Sertoglu
• Re: One big table or split data? Writing data. From disk point of view. With a good storage (GBs/s, writing speed)
  • From: Sam R.
• Re: Import csv in PostgreSQL
  • From: Gabi D
• Import csv in PostgreSQL
  • From: Dinesh Chandra 12108
• One big table or split data? Writing data. From disk point of view. With a good storage (GBs/s, writing speed)
  • From: Sam R.
• Re: does work_mem is used on temp tables?
  • From: Mariel Cherkassky
• Re: does work_mem is used on temp tables?
  • From: Andrew Gierth
• does work_mem is used on temp tables?
  • From: Mariel Cherkassky
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: understand query on partition table
  • From: Samed YILDIRIM
• understand query on partition table
  • From: Mariel Cherkassky
• Re: Partial index plan/cardinality costing
  • From: Justin Pryzby
• Re: Partial index plan/cardinality costing
  • From: James Coleman
• Re: Why the index is not used ?
  • From: Paul McGarry
• Re: Why the index is not used ?
  • From: Tomas Vondra
• RE: Why the index is not used ?
  • From: ROS Didier
• RE: Why the index is not used ?
  • From: ROS Didier
• RE: Why the index is not used ?
  • From: ROS Didier
• RE: Why the index is not used ?
  • From: ROS Didier
• RE: Why the index is not used ?
  • From: ROS Didier
• RE: Why the index is not used ?
  • From: ROS Didier
• Re: Why the index is not used ?
  • From: Paul McGarry
• Re: Why the index is not used ?
  • From: Tomas Vondra
• Re: Why the index is not used ?
  • From: Vladimir Ryabtsev
• Re: Why the index is not used ?
  • From: Vladimir Ryabtsev
• RE: Why the index is not used ?
  • From: Kumar, Virendra
• RE: Why the index is not used ?
  • From: ROS Didier
• Re: Why the index is not used ?
  • From: Francisco Olarte
• RE: Why the index is not used ?
  • From: ROS Didier
• RE: Why the index is not used ?
  • From: ROS Didier
• Re: Why the index is not used ?
  • From: Paul McGarry
• Re: Why the index is not used ?
  • From: Vladimir Ryabtsev
• Re: Why the index is not used ?
  • From: Pavel Stehule
• Why the index is not used ?
  • From: ROS Didier
• Re: dsa_allocate() faliure
  • From: Thomas Munro
• Re: Why could different data in a table be processed with different performance?
  • From: Fabio Pardi
• Re: psql: fe_sendauth: no password supplied
  • From: Justin Pryzby
• psql: fe_sendauth: no password supplied
  • From: Daulat Ram
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: Fabio Pardi
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: David Rowley
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Sam R.
• Re: SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Justin Pryzby
• Re: SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Vladimir Ryabtsev
• Re: SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Tom Lane
• Re: SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Vladimir Ryabtsev
• Re: SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Arjun Ranade
• Re: SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Justin Pryzby
• Re: SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Arjun Ranade
• Re: SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Justin Pryzby
• Re: SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Arjun Ranade
• Re: SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Tom Lane
• SELECT statement returns in 10seconds, but INSERT/CREATE TABLE AS with same SELECT takes 7 minutes
  • From: Arjun Ranade
• Re: Why could different data in a table be processed with different performance?
  • From: Fabio Pardi
• reference regarding write load during different stages of checkpoint
  • From: Justin Pryzby
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: David Rowley
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: link to Slow_Query_Questions from wiki/Main Page
  • From: Alvaro Herrera
• Re: link to Slow_Query_Questions from wiki/Main Page
  • From: Justin Pryzby
• Re: Why could different data in a table be processed with different performance?
  • From: Fabio Pardi
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Sam R.
• Re: Why could different data in a table be processed with different performance?
  • From: Gasper Zejn
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: Justin Pryzby
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: Justin Pryzby
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: Justin Pryzby
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Explain is slow with tables having many columns
  • From: Andres Freund
• Re: Explain is slow with tables having many columns
  • From: Andres Freund
• Re: Explain is slow with tables having many columns
  • From: legrand legrand
• Re: Explain is slow with tables having many columns
  • From: Justin Pryzby
• Explain is slow with tables having many columns
  • From: legrand legrand
• Re: Why could different data in a table be processed with different performance?
  • From: Fabio Pardi
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: didier
• Re: Multi-second pauses blocking even trivial activity
  • From: Andreas Kretschmer
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Multi-second pauses blocking even trivial activity
  • From: Patrick Molgaard
• Re: Why could different data in a table be processed with different performance?
  • From: Fabio Pardi
• Re: Why could different data in a table be processed with different performance?
  • From: Fabio Pardi
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: Laurenz Albe
• Re: Why could different data in a table be processed with different performance?
  • From: Justin Pryzby
• Re: Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: Why could different data in a table be processed with different performance?
  • From: Justin Pryzby
• Why could different data in a table be processed with different performance?
  • From: Vladimir Ryabtsev
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: David Rowley
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Wei Shan
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Sam R.
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Jeff Janes
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Sam R.
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Sam R.
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: David Rowley
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Kaixi Luo
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: David Rowley
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Sam R.
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Sam R.
• Re: To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Sergei Kornilov
• Re: How to see/calculate size of index in memory?
  • From: Sergei Kornilov
• To keep indexes in memory, is large enough effective_cache_size enough?
  • From: Sam R.
• How to see/calculate size of index in memory?
  • From: Sam R.
• Re: Why the sql is not executed in parallel mode
  • From: Thomas Munro
• Why the sql is not executed in parallel mode
  • From: jimmy
• Re: Select count(*) on a 2B Rows Tables Takes ~20 Hours
  • From: Schneider, Jeremy
• Re: LEFT JOIN LATERAL optimisation at plan time
  • From: Tom Lane
• pg_pub_decrypt: 10x performance hit with gpg v2
  • From: Felix A. Kater
• Performance problems with Thai language
  • From: Andrey Zhidenkov
• LEFT JOIN LATERAL optimisation at plan time
  • From: Nicolas Paris
• Re: Select count(*) on a 2B Rows Tables Takes ~20 Hours
  • From: Laurenz Albe
• Re: Select count(*) on a 2B Rows Tables Takes ~20 Hours
  • From: Fred Habash
• Big image tables maintenance
  • From: still Learner
• Re: How Do You Associate a Query With its Invoking Procedure?
  • From: Fred Habash
• Advice on machine specs for growth
  • From: Rory Campbell-Lange
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: padusuma
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: Tim Cross
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: padusuma
• Re: How Do You Associate a Query With its Invoking Procedure?
  • From: Patrick Molgaard
• Re: How Do You Associate a Query With its Invoking Procedure?
  • From: Roman Konoval
• Re: How Do You Associate a Query With its Invoking Procedure?
  • From: Rick Otten
• Re: How Do You Associate a Query With its Invoking Procedure?
  • From: David G. Johnston
• Re: How Do You Associate a Query With its Invoking Procedure?
  • From: Fred Habash
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: Tim Cross
• How Do You Associate a Query With its Invoking Procedure?
  • From: Fd Habash
• Re: Select count(*) on a 2B Rows Tables Takes ~20 Hours
  • From: Andres Freund
• RE: Select count(*) on a 2B Rows Tables Takes ~20 Hours
  • From: Fd Habash
• Re: Select count(*) on a 2B Rows Tables Takes ~20 Hours
  • From: Tom Lane
• Re: Select count(*) on a 2B Rows Tables Takes ~20 Hours
  • From: Justin Pryzby
• Select count(*) on a 2B Rows Tables Takes ~20 Hours
  • From: Fd Habash
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: padusuma
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: padusuma
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: Tim Cross
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: padusuma
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: Sergei Kornilov
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: padusuma
• Re: Multi-second pauses blocking even trivial activity
  • From: Patrick Molgaard
• Re: Multi-second pauses blocking even trivial activity
  • From: Patrick Molgaard
• Re: Performance of INSERT into temporary tables using psqlODBC driver
  • From: Tim Cross
• Performance of INSERT into temporary tables using psqlODBC driver
  • From: padusuma
• GIN Index has O(N^2) complexity for array overlap operator?
  • From: Felix Geisendörfer
• Re: Multi-second pauses blocking even trivial activity
  • From: Jeff Janes
• Re: Multi-second pauses blocking even trivial activity
  • From: Joshua D. Drake
• Re: Multi-second pauses blocking even trivial activity
  • From: Andreas Kretschmer
• Re: Multi-second pauses blocking even trivial activity
  • From: Patrick Molgaard
• Partial index plan/cardinality costing
  • From: James Coleman
• Re: Multi-second pauses blocking even trivial activity
  • From: Jeff Janes
• Multi-second pauses blocking even trivial activity
  • From: Patrick Molgaard
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Dinesh Kumar
• Re: query gets very slow when :jsonb ?& operator is used
  • From: Jeff Janes
• query gets very slow when :jsonb ?& operator is used
  • From: davidjesse091
• Re: Guideline To Resolve LWLock:SubtransControlLock
  • From: Jeremy Schneider
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Jeff Janes
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Jeff Janes
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Dinesh Kumar
• Re: Query is slow when run for first time; subsequent execution is fast
  • From: Jeff Janes
• Re: Inconsistent query times and spiky CPU with GIN tsvector search
  • From: Laurenz Albe
• Inconsistent query times and spiky CPU with GIN tsvector search
  • From: Scott Rankin
• RE: Query is slow when run for first time; subsequent execution is fast
  • From: jimmy
• Re: trying to delete most of the table by range of date col
  • From: Mariel Cherkassky
• Re: trying to delete most of the table by range of date col
  • From: Jeff Janes
• Re: trying to delete most of the table by range of date col
  • From: Carrie Berlin
• Re: trying to delete most of the table by range of date col
  • From: Mariel Cherkassky
• Re: trying to delete most of the table by range of date col
  • From: Carrie Berlin
• Re: trying to delete most of the table by range of date col
  • From: Mariel Cherkassky
• Re: trying to delete most of the table by range of date col
  • From: Justin Pryzby
• Re: trying to delete most of the table by range of date col
  • From: Mariel Cherkassky
• Re: trying to delete most of the table by range of date col
  • From: Sergei Kornilov
• Re: trying to delete most of the table by range of date col
  • From: Mariel Cherkassky
• Re: trying to delete most of the table by range of date col
  • From: Andreas Kretschmer
• Re: trying to delete most of the table by range of date col
  • From: Justin Pryzby
• trying to delete most of the table by range of date col
  • From: Mariel Cherkassky
• Re: Extremely slow when query uses GIST exclusion index
  • From: Andreas Kretschmer
• Re: Extremely slow when query uses GIST exclusion index
  • From: David
• Re: Extremely slow when query uses GIST exclusion index
  • From: Andreas Kretschmer
• Re: Extremely slow when query uses GIST exclusion index
  • From: Andreas Kretschmer
• Re: dsa_allocate() faliure
  • From: Sand Stone
• Extremely slow when query uses GIST exclusion index
  • From: David
• Re: dsa_allocate() faliure
  • From: Sand Stone
• RE: Guideline To Resolve LWLock:SubtransControlLock
  • From: Fd Habash
• RE: Guideline To Resolve LWLock:SubtransControlLock
  • From: Fd Habash
• Re: Guideline To Resolve LWLock:SubtransControlLock
  • From: Jeremy Schneider
• Re: Guideline To Resolve LWLock:SubtransControlLock
  • From: Alvaro Herrera
• Re: Guideline To Resolve LWLock:SubtransControlLock
  • From: Fred Habash
• Re: Guideline To Resolve LWLock:SubtransControlLock
  • From: Alvaro Herrera
• Re: Guideline To Resolve LWLock:SubtransControlLock
  • From: Fred Habash
• Re: Bi-modal streaming replication throughput
  • From: Andres Freund
• Re: Bi-modal streaming replication throughput
  • From: Alexis Lê-Quôc
• Re: Guideline To Resolve LWLock:SubtransControlLock
  • From: Alvaro Herrera
• Guideline To Resolve LWLock:SubtransControlLock
  • From: Fred Habash
• Re: dsa_allocate() faliure
  • From: Thomas Munro
• Re: dsa_allocate() faliure
  • From: Sand Stone
• Re: Fwd: increase insert into local table from remote oracle table preformance
  • From: legrand legrand
• RE: Calculating how much redo log space has been used
  • From: Reza Taheri
• Re: increase insert into local table from remote oracle table preformance
  • From: Daniel Blanch Bataller
• Re: Fwd: increase insert into local table from remote oracle table preformance
  • From: Mariel Cherkassky
• Re: Fwd: increase insert into local table from remote oracle table preformance
  • From: legrand legrand
• Re: Calculating how much redo log space has been used
  • From: Andres Freund
• Calculating how much redo log space has been used
  • From: Reza Taheri
• Re: Bi-modal streaming replication throughput
  • From: Andres Freund
• Re: Bi-modal streaming replication throughput
  • From: Andres Freund
• Re: Bi-modal streaming replication throughput
  • From: Jeff Janes
• Bi-modal streaming replication throughput
  • From: Alexis Lê-Quôc
• Re: Fwd: increase insert into local table from remote oracle table preformance
  • From: Mariel Cherkassky
• Re: Fwd: increase insert into local table from remote oracle table preformance
  • From: legrand legrand
• Fwd: increase insert into local table from remote oracle table preformance
  • From: Mariel Cherkassky
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Jeff Janes
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Andres Freund
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Jeff Janes
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Andres Freund
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Andres Freund
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Jeff Janes
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Andres Freund
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Pavel Stehule
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Jeff Janes
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Pavel Stehule
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: Tom Lane
• Re: Performance difference in accessing differrent columns in a Postgres Table
  • From: David Rowley
• Performance difference in accessing differrent columns in a Postgres Table
  • From: Dinesh Kumar
• Re: Query with "ILIKE ALL" does not use the index
  • From: Nicolas Even
• Re: Query with "ILIKE ALL" does not use the index
  • From: Nicolas Even
• Re: Query with "ILIKE ALL" does not use the index
  • From: Matthew Hall
• Re: Query with "ILIKE ALL" does not use the index
  • From: Tom Lane
• Query with "ILIKE ALL" does not use the index
  • From: Nicolas Even
• Re: Automated bottleneck detection
  • From: MichaelDBA
• Automated bottleneck detection
  • From: Thomas Güttler
• Re: Profile what the production server is doing
  • From: Julien Rouhaud
• Re: Profile what the production server is doing
  • From: Flo Rance
• Re: Profile what the production server is doing
  • From: Thomas Güttler
• Re: Profile what the production server is doing
  • From: Thomas Güttler
• Re: Profile what the production server is doing
  • From: Thomas Güttler
• Re: Profile what the production server is doing
  • From: Flo Rance
• Re: Profile what the production server is doing
  • From: Baron Schwartz
• Re: Profile what the production server is doing
  • From: Julien Rouhaud
• Profile what the production server is doing
  • From: Thomas Güttler
• Re: Why HDD performance is better than SSD in this case
  • From: Mark Kirkwood
• Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM)
  • From: Andres Freund
• Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM)
  • From: Robert Haas
• Re: Why HDD performance is better than SSD in this case
  • From: Mark Kirkwood
• Re: Why HDD performance is better than SSD in this case
  • From: Neto pr
• Re: Why HDD performance is better than SSD in this case
  • From: Mark Kirkwood
• Re: Why HDD performance is better than SSD in this case
  • From: Mark Kirkwood
• Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM)
  • From: Andres Freund
• Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM)
  • From: Robert Haas
• Re: Why HDD performance is better than SSD in this case
  • From: Imre Samu
• Re: Why HDD performance is better than SSD in this case
  • From: George Neuner
• Re: Why HDD performance is better than SSD in this case
  • From: Mark Kirkwood
• Re: Why HDD performance is better than SSD in this case
  • From: Nicolas Charles
• Re: Why HDD performance is better than SSD in this case
  • From: Fabio Pardi
• Re: Why HDD performance is better than SSD in this case
  • From: Neto pr
• Re: Why HDD performance is better than SSD in this case
  • From: Neto pr
• Re: Why HDD performance is better than SSD in this case
  • From: Neto pr
• Re: Why HDD performance is better than SSD in this case
  • From: Mark Kirkwood
• Re: Why HDD performance is better than SSD in this case
  • From: Mark Kirkwood
• Re: Improving Performance of Query ~ Filter by A, Sort by B
  • From: Jeff Janes
• Re: Special bloom index of INT, BIGINT, BIT, VARBIT for bitwise operation
  • From: Tomas Vondra
• Re: Why HDD performance is better than SSD in this case
  • From: Fabio Pardi
• Re: Why HDD performance is better than SSD in this case
  • From: Nicolas Charles
• Re: Why HDD performance is better than SSD in this case
  • From: Nicolas Charles
• Re: Why HDD performance is better than SSD in this case
  • From: Neto pr
• Re: Why HDD performance is better than SSD in this case
  • From: Neto pr
• Re: Why HDD performance is better than SSD in this case
  • From: Fabio Pardi
• Re: Why HDD performance is better than SSD in this case
  • From: Robert Zenz
• Re: Why HDD performance is better than SSD in this case
  • From: Nicolas Charles
• Re: Why HDD performance is better than SSD in this case
  • From: Jeff Janes
• Re: Why HDD performance is better than SSD in this case
  • From: Neto pr
• Re: Why HDD performance is better than SSD in this case
  • From: Neto pr
• Re: HDD vs SSD without explanation
  • From: Neto pr
• Re: Why HDD performance is better than SSD in this case
  • From: Fabio Pardi
• Re: Why HDD performance is better than SSD in this case
  • From: Robert Zenz
• Re: Why HDD performance is better than SSD in this case
  • From: Mark Kirkwood
• Re: Why HDD performance is better than SSD in this case
  • From: winston cheung
• Re: Why HDD performance is better than SSD in this case
  • From: Benjamin Scherrey
• Why HDD performance is better than SSD in this case
  • From: Neto pr
• Re: Improving Performance of Query ~ Filter by A, Sort by B
  • From: Lincoln Swaine-Moore
• Re: Improving Performance of Query ~ Filter by A, Sort by B
  • From: Jeff Janes
• Re: performance statistics monitoring without spamming logs
  • From: Julien Rouhaud
• Re: performance statistics monitoring without spamming logs
  • From: Adrien NAYRAT
• Re: performance statistics monitoring without spamming logs
  • From: Adrien NAYRAT
• Re: performance statistics monitoring without spamming logs
  • From: Lukas Fittl
• Re: High concurrency but simple updating causes deadlock
  • From: Roman Konoval
• High concurrency but simple updating causes deadlock
  • From: =?gb18030?b?t+M=?=
• Suggestion to optimize performance of the PLSQL procedure.
  • From: Dinesh Chandra 12108
• Re: Improving Performance of Query ~ Filter by A, Sort by B
  • From: Tom Lane
• Re: Improving Performance of Query ~ Filter by A, Sort by B
  • From: Lincoln Swaine-Moore
• Re: Improving Performance of Query ~ Filter by A, Sort by B
  • From: legrand legrand
• Special bloom index of INT, BIGINT, BIT, VARBIT for bitwise operation
  • From: Takao Magoori
• Re: performance statistics monitoring without spamming logs
  • From: Justin Pryzby
• performance statistics monitoring without spamming logs
  • From: Patrick Hemmer
• Improving Performance of Query ~ Filter by A, Sort by B
  • From: Lincoln Swaine-Moore
• Re: Need help with optimising simple query
  • From: Nandakumar M
• Re: Need help with optimising simple query
  • From: Tom Lane
• Need help with optimising simple query
  • From: Nandakumar M
• Re: where can I download the binaries of plpython extension
  • From: Mariel Cherkassky
• Re: where can I download the binaries of plpython extension
  • From: Justin Pryzby
• Re: Problems with installing pgwatch2 without docker
  • From: Andrew Dunstan
• Re: where can I download the binaries of plpython extension
  • From: Mariel Cherkassky
• Problems with installing pgwatch2 without docker
  • From: Mariel Cherkassky
• Re: where can I download the binaries of plpython extension
  • From: Justin Pryzby
• Re: where can I download the binaries of plpython extension
  • From: Mariel Cherkassky
• Re: where can I download the binaries of plpython extension
  • From: Justin Pryzby
• Re: where can I download the binaries of plpython extension
  • From: Tom Lane
• Re: where can I download the binaries of plpython extension
  • From: Mariel Cherkassky
• Re: where can I download the binaries of plpython extension
  • From: Justin Pryzby
• Re: where can I download the binaries of plpython extension
  • From: Mariel Cherkassky
• Re: where can I download the binaries of plpython extension
  • From: Justin Pryzby
• where can I download the binaries of plpython extension
  • From: Mariel Cherkassky
• Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM)
  • From: Andres Freund
• Re: Trigger overhead/performance and alternatives?
  • From: Peter Eisentraut
• Re: tcp_keepalives
  • From: Justin Pryzby
• tcp_keepalives
  • From: José Mello Júnior
• Trigger overhead/performance and alternatives?
  • From: AJG
• Re: Bug in PostgreSQL
  • From: Andres Freund
• Re: Bug in PostgreSQL
  • From: Laurenz Albe
• Re: Queue table that quickly grows causes query planner to choose poor plan
  • From: David Wheeler
• Re: Queue table that quickly grows causes query planner to choose poor plan
  • From: Tom Lane
• Re: Queue table that quickly grows causes query planner to choose poor plan
  • From: Justin Pryzby
• Re: Bug in PostgreSQL
  • From: Joseph Curtin
• Re: Bug in PostgreSQL
  • From: Steve Crawford
• Bug in PostgreSQL
  • From: Rambabu V
• Queue table that quickly grows causes query planner to choose poor plan
  • From: David Wheeler
• Re: Slow join
  • From: Roman Kushnir
• Re: Slow join
  • From: Laurenz Albe
• Re: "set primary keys..." is missing when using hight values for transactions / scaling factor with pgbench
  • From: Elvir Kurić
• Re: "set primary keys..." is missing when using hight values for transactions / scaling factor with pgbench
  • From: David Rowley
• "set primary keys..." is missing when using hight values for transactions / scaling factor with pgbench
  • From: Elvir Kurić
• Re: Slow join
  • From: Roman Kushnir
• Re: Slow join
  • From: Justin Pryzby
• Slow join
  • From: Roman Kushnir
• Re: Slow query when pg_trgm is in inner lopp
  • From: Sasa Vilic
• Re: Slow query when pg_trgm is in inner lopp
  • From: Jeff Janes
• Re: Slow query when pg_trgm is in inner lopp
  • From: Sasa Vilic
• Re: Slow query when pg_trgm is in inner lopp
  • From: Matthew Hall
• Slow query when pg_trgm is in inner lopp
  • From: Sasa Vilic
• Re: Dissuade the use of exclusion constraint index
  • From: Adam Brusselback
• Re: Small query plan change, big performance difference
  • From: Michael Sacket
• Re: Small query plan change, big performance difference
  • From: Adam Brusselback
• Small query plan change, big performance difference
  • From: Michael Sacket
• Re: Dissuade the use of exclusion constraint index
  • From: Adam Brusselback
• Re: pg_upgrade 10.2
  • From: Jerry Sievers
• Re: pg_upgrade 10.2
  • From: Adrian Klaver
• RE: pg_upgrade 10.2
  • From: Murthy Nunna
• Re: pg_upgrade 10.2
  • From: Jerry Sievers
• RE: pg_upgrade 10.2
  • From: Murthy Nunna
• Re: pg_upgrade 10.2
  • From: Adrian Klaver
• RE: pg_upgrade 10.2
  • From: Murthy Nunna
• Re: pg_upgrade 10.2
  • From: Adrian Klaver
• RE: pg_upgrade 10.2
  • From: Murthy Nunna
• Re: pg_upgrade 10.2
  • From: Adrian Klaver
• pg_upgrade 10.2
  • From: Murthy Nunna
• Re: Client Server performance & UDS
  • From: e-blokos
• RE: Simple Query Elapsed Time ~ 3 hrs Using Bitmap Index/Heap Scan
  • From: Fd Habash
• Re: Simple Query Elapsed Time ~ 3 hrs Using Bitmap Index/Heap Scan
  • From: Matthew Hall
• Re: Simple Query Elapsed Time ~ 3 hrs Using Bitmap Index/Heap Scan
  • From: Tom Lane
• Re: Simple Query Elapsed Time ~ 3 hrs Using Bitmap Index/Heap Scan
  • From: Sergei Kornilov
• Simple Query Elapsed Time ~ 3 hrs Using Bitmap Index/Heap Scan
  • From: Fred Habash
• Re: Sort is generating rows
  • From: Nicolas Seinlet
• Re: Sort is generating rows
  • From: Jeff Janes
• Sort is generating rows
  • From: Nicolas Seinlet
• Re: Possible optimisation: push down SORT and LIMIT nodes
  • From: Justin Pryzby
• Re: Possible optimisation: push down SORT and LIMIT nodes
  • From: Justin Pryzby
• Possible optimisation: push down SORT and LIMIT nodes
  • From: Christopher Wilson
• Re: propose web form for submission of performance problems
  • From: Thomas Kellerer
• Re: propose web form for submission of performance problems
  • From: Justin Pryzby
• Re: propose web form for submission of performance problems
  • From: Craig James
• propose web form for submission of performance problems
  • From: Justin Pryzby
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: Justin Pryzby
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: Justin Pryzby
• Re: dsa_allocate() faliure
  • From: Sand Stone
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: Justin Pryzby
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: mlunnon
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: dsa_allocate() faliure
  • From: Thomas Munro
• Re: dsa_allocate() faliure
  • From: Sand Stone
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: Pavan Teja
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: Justin Pryzby
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: Justin Pryzby
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: mlunnon
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: David G. Johnston
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: Abbas
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: David G. Johnston
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: Abbas
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: mlunnon
• Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
  • From: pavan95
• Re: Help with tuning slow query
  • From: Justin Pryzby
• Help with tuning slow query
  • From: Kotapati, Anil
• Re: Latest advice on SSD?
  • From: Mark Kirkwood
• Re: Latest advice on SSD?
  • From: Evgeniy Shishkin
• Sv: Re: Sv: Sv: Re: Latest advice on SSD?
  • From: Andreas Joseph Krogh
• Sv: Re: Sv: Sv: Re: Latest advice on SSD?
  • From: Andreas Joseph Krogh
• Re: Sv: Sv: Re: Latest advice on SSD?
  • From: Mark Kirkwood
• Sv: Sv: Re: Latest advice on SSD?
  • From: Andreas Joseph Krogh
• Sv: Re: Latest advice on SSD?
  • From: Andreas Joseph Krogh
• Re: Time bucketing query performance
  • From: Justin Pryzby
• Time bucketing query performance
  • From: Julian Wilson
• Re: help in analysis of execution plans
  • From: David Rowley
• Re: help in analysis of execution plans
  • From: Neto pr
• help in analysis of execution plans
  • From: Neto pr
• Why doesn't the second query use the index for sorting?
  • From: Alf Lervåg
• Re: Performance issues while running select sql query
  • From: Kaushal Shriyan
• Re: Performance issues while running select sql query
  • From: Justin Pryzby
• Performance issues while running select sql query
  • From: David G. Johnston
• Re: Performance issues while running select sql query
  • From: Kaushal Shriyan
• Re: Performance issues while running select sql query
  • From: Kaushal Shriyan
• Re: Performance issues while running select sql query
  • From: Justin Pryzby
• Performance issues while running select sql query
  • From: Kaushal Shriyan
• Re: SeqScan vs. IndexScan
  • From: Tom Lane
• SeqScan vs. IndexScan
  • From: Vitaliy Garnashevich
• Re: pg_upgrade help
  • From: Sergei Kornilov
• RE: Data migration from postgres 8.4 to 9.4
  • From: Ahmed, Nawaz
• RE: Installing PostgreSQL 9.5 in centos 6 using YUM
  • From: Ahmed, Nawaz
• pg_upgrade help
  • From: Akshay Ballarpure
• Citext Performance
  • From: Deepak Somaiya
• Re: Unexplainable execution time difference between two test functions...one using IF (SELECT COUNT(*) FROM...) and the other using IF EXISTS (SELECT 1 FROM...)
  • From: Tomas Vondra
• Re: Unexplainable execution time difference between two test functions...one using IF (SELECT COUNT(*) FROM...) and the other using IF EXISTS (SELECT 1 FROM...)
  • From: Tomas Vondra