Postgres Performance Date Index

• Thread Index

• Re: Why isn't an index scan being used?
  • From: Abi Noda
• Re: Why isn't an index scan being used?
  • From: David Rowley
• Why isn't an index scan being used?
  • From: Abi Noda
• Re: index on jsonb col with 2D array inside the json
  • From: Mariel Cherkassky
• Re: index on jsonb col with 2D array inside the json
  • From: Michael Lewis
• Re: index on jsonb col with 2D array inside the json
  • From: Mariel Cherkassky
• Re: index on jsonb col with 2D array inside the json
  • From: Michael Lewis
• index on jsonb col with 2D array inside the json
  • From: Mariel Cherkassky
• Re: Performance regressions found using sqlfuzz
  • From: Jung, Jinho
• Re: How can sort performance be so different
  • From: Bob Jolliffe
• Re: dsa_allocate() faliure
  • From: Jakub Glapa
• Re: dsa_allocate() faliure
  • From: Justin Pryzby
• Re: Performance regressions found using sqlfuzz
  • From: Tom Lane
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Justin Pryzby
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Mariel Cherkassky
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Benedict Holland
• Re: Performance regressions found using sqlfuzz
  • From: Andres Freund
• Re: Performance regressions found using sqlfuzz
  • From: Andrew Gierth
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: suganthi Sekar
• Re: Performance regressions found using sqlfuzz
  • From: Jung, Jinho
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Alvaro Herrera
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Laurenz Albe
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Michael Lewis
• Re: JIT overhead slowdown
  • From: Justin Pryzby
• Re: Q on SQL Performance tuning
  • From: Greg Stark
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Michael Lewis
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Michael Lewis
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Michael Lewis
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: partition pruning
  • From: Justin Pryzby
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: suganthi Sekar
• Re: partition pruning
  • From: suganthi Sekar
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Michael Lewis
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Justin Pryzby
• Re: partition pruning
  • From: Laurenz Albe
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: suganthi Sekar
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: suganthi Sekar
• Re: server hardware tuning.
  • From: suganthi Sekar
• Re: constraint exclusion with ineq condition (Re: server hardware tuning.)
  • From: Justin Pryzby
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Mariel Cherkassky
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Alvaro Herrera
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Mariel Cherkassky
• Re: ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Alvaro Herrera
• ERROR: unrecognized parameter "autovacuum_analyze_scale_factor"
  • From: Mariel Cherkassky
• Re: understanding max_wal_size,wal_keep_segments and checkpoints
  • From: Laurenz Albe
• Re: understanding max_wal_size,wal_keep_segments and checkpoints
  • From: Mariel Cherkassky
• Re: understanding max_wal_size,wal_keep_segments and checkpoints
  • From: Laurenz Albe
• understanding max_wal_size,wal_keep_segments and checkpoints
  • From: Mariel Cherkassky
• Re: Bloom index cost model seems to be wrong
  • From: Jeff Janes
• Re: Bloom index cost model seems to be wrong
  • From: Tom Lane
• Re: Bloom index cost model seems to be wrong
  • From: Jeff Janes
• Re: Performance regressions found using sqlfuzz
  • From: Jeff Janes
• Re: Bloom index cost model seems to be wrong
  • From: Jeff Janes
• Re: Bloom index cost model seems to be wrong
  • From: Tom Lane
• Bloom index cost model seems to be wrong
  • From: Thomas Kellerer
• Re: Performance regressions found using sqlfuzz
  • From: Christoph Berg
• Performance regressions found using sqlfuzz
  • From: Jung, Jinho
• Re: Partitioning Optimizer Questions and Issues
  • From: keith anderson
• Re:
  • From: Tumasgiu Rossini
• Re: slow to run query 5000 times
  • From: Ricardo Martin Gomez
• Re: slow to run query 5000 times
  • From: Andres Freund
• Re: slow to run query 5000 times
  • From: Justin Pryzby
• [no subject]
  • From: Evandro Abreu
• Re: Partitioning Optimizer Questions and Issues
  • From: Justin Pryzby
• Partitioning Optimizer Questions and Issues
  • From: keith anderson
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Jeff Janes
• Managing High Availability in PostgreSQL – Part I
  • From: Kristi Anderson
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Transaction size and Wal2Json
  • From: Mai Peng
• Re: Transaction size and Wal2Json
  • From: Peter Eisentraut
• Re: autovacuum big table taking hours and sometimes seconds
  • From: David Rowley
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Jeff Janes
• Re: autovacuum big table taking hours and sometimes seconds
  • From: MichaelDBA
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Jeff Janes
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: dangal
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: autovacuum big table taking hours and sometimes seconds
  • From: David Rowley
• Re: autovacuum big table taking hours and sometimes seconds
  • From: Laurenz Albe
• autovacuum big table taking hours and sometimes seconds
  • From: Mariel Cherkassky
• Re: How can sort performance be so different
  • From: Laurenz Albe
• Re: How can sort performance be so different
  • From: Merlin Moncure
• Re: dsa_allocate() faliure
  • From: Justin Pryzby
• RE: dsa_allocate() faliure
  • From: Arne Roland
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Sv: Re: Fw: server hardware tuning.
  • From: Andreas Joseph Krogh
• Re: Fw: server hardware tuning.
  • From: Prince Pathria
• Fw: server hardware tuning.
  • From: suganthi Sekar
• Re: dsa_allocate() faliure
  • From: Thomas Munro
• Re: dsa_allocate() faliure
  • From: Jakub Glapa
• Re: dsa_allocate() faliure
  • From: Justin Pryzby
• RE: dsa_allocate() faliure
  • From: Arne Roland
• Re: How can sort performance be so different
  • From: Bob Jolliffe
• Re: Setting effective_cache size
  • From: Laurenz Albe
• Re: Setting effective_cache size
  • From: Nandakumar M
• Setting effective_cache size
  • From: Nandakumar M
• Re: How can sort performance be so different
  • From: Peter Geoghegan
• Re: pgstattupple vs pg_total_relation_size
  • From: Tom Lane
• Re: pgstattupple vs pg_total_relation_size
  • From: Mariel Cherkassky
• Re: pgstattupple vs pg_total_relation_size
  • From: Jehan-Guillaume (ioguix) de Rorthais
• Re: pgstattupple vs pg_total_relation_size
  • From: Tumasgiu Rossini
• Re: How can sort performance be so different
  • From: Bob Jolliffe
• pgstattupple vs pg_total_relation_size
  • From: Mariel Cherkassky
• Re: dsa_allocate() faliure
  • From: Fabio Isabettini
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: ERROR: found xmin from before relfrozenxid
  • From: Alvaro Herrera
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: Will higher shared_buffers improve tpcb-like benchmarks?
  • From: Saurabh Nanda
• Re: dsa_allocate() faliure
  • From: Thomas Munro
• Re: How can sort performance be so different
  • From: Tom Lane
• Re: Interpreting shared_buffers setting
  • From: Jerry Sievers
• Re: How can sort performance be so different
  • From: Saurabh Nanda
• Re: How can sort performance be so different
  • From: Pavel Stehule
• Re: Interpreting shared_buffers setting
  • From: Jerry Sievers
• How can sort performance be so different
  • From: Bob Jolliffe
• Re: Will higher shared_buffers improve tpcb-like benchmarks?
  • From: Saurabh Nanda
• Re: Will higher shared_buffers improve tpcb-like benchmarks?
  • From: Jeff Janes
• Re: pg_locks - what is a virtualxid locktype
  • From: Alvaro Herrera
• Re: Interpreting shared_buffers setting
  • From: Bob Jolliffe
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Jeff Janes
• Re: Interpreting shared_buffers setting
  • From: Andrew Gierth
• Re: Interpreting shared_buffers setting
  • From: Thomas Markus
• Interpreting shared_buffers setting
  • From: Bob Jolliffe
• Re: Will higher shared_buffers improve tpcb-like benchmarks?
  • From: Joe Mirabal
• Re: dsa_allocate() faliure
  • From: Fabio Isabettini
• Will higher shared_buffers improve tpcb-like benchmarks?
  • From: Saurabh Nanda
• Re: pg_locks - what is a virtualxid locktype
  • From: Shreeyansh Dba
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Nicolas Charles
• pg_locks - what is a virtualxid locktype
  • From: Mariel Cherkassky
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: dsa_allocate() faliure
  • From: Thomas Munro
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• RE: dsa_allocate() faliure
  • From: Arne Roland
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Nicolas Charles
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: upgrade from 9.6 to 10/11
  • From: Justin Pryzby
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Nicolas Charles
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: upgrade from 9.6 to 10/11
  • From: Laurenz Albe
• upgrade from 9.6 to 10/11
  • From: Mariel Cherkassky
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Jeff Janes
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Jeff Janes
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Justin Pryzby
• Re: Q on SQL Performance tuning
  • From: Justin Pryzby
• Re: Q on SQL Performance tuning
  • From: legrand legrand
• Q on SQL Performance tuning
  • From: Bhupathi, Kaushik (CORP)
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: ERROR: found xmin from before relfrozenxid
  • From: Adrien NAYRAT
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: ERROR: found xmin from before relfrozenxid
  • From: Adrien NAYRAT
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: Tom Lane
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: Tom Lane
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: Zero throughput on a query on a very large table.
  • From: Tom Lane
• Re: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• RE: Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: ERROR: found xmin from before relfrozenxid
  • From: Adrien NAYRAT
• Re: Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: Zero throughput on a query on a very large table.
  • From: David Rowley
• Re: Zero throughput on a query on a very large table.
  • From: Tom Lane
• Re: Zero throughput on a query on a very large table.
  • From: Andreas Kretschmer
• Zero throughput on a query on a very large table.
  • From: ldh@xxxxxxxxxxxxxxxxxx
• Re: SELECT performance drop
  • From: Jan Nielsen
• RE: dsa_allocate() faliure
  • From: Arne Roland
• Re: SELECT performance drop
  • From: Jan Nielsen
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: Parallel stats in execution plans
  • From: David Rowley
• Re: Parallel stats in execution plans
  • From: David Conlin
• Re: ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: SELECT performance drop
  • From: Laurenz Albe
• Re: ERROR: found xmin from before relfrozenxid
  • From: Jerry Sievers
• RE:SELECT performance drop
  • From: legrand legrand
• Benchmarking: How to identify bottleneck (limiting factor) and achieve "linear scalability"?
  • From: Saurabh Nanda
• Re: SELECT performance drop
  • From: Jan Nielsen
• ERROR: found xmin from before relfrozenxid
  • From: Mariel Cherkassky
• Re: SELECT performance drop
  • From: Jim Finnerty
• Re: SELECT performance drop
  • From: Jan Nielsen
• Re: SELECT performance drop
  • From: legrand legrand
• ANALYZE accuracy problems for n_distinct, and a solution
  • From: Jim Finnerty
• Re: SELECT performance drop
  • From: Jan Nielsen
• SELECT performance drop
  • From: Jan Nielsen
• RE: Memory and hard ware calculation :
  • From: Rangaraj G
• Re: Very long query planning times for database with lots of partitions
  • From: Mickael van der Beek
• RE: Very long query planning times for database with lots of partitions
  • From: Steven Winfield
• Re: Very long query planning times for database with lots of partitions
  • From: Justin Pryzby
• Very long query planning times for database with lots of partitions
  • From: Mickael van der Beek
• Re: Memory and hard ware calculation :
  • From: Fabio Pardi
• Re: Memory and hard ware calculation :
  • From: Cleiton Luiz Domazak
• Memory and hard ware calculation :
  • From: Rangaraj G
• Re: JIT overhead slowdown
  • From: Luis Carril
• Re: JIT overhead slowdown
  • From: Andres Freund
• JIT overhead slowdown
  • From: Luis Carril
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Alvaro Herrera
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Alvaro Herrera
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Alvaro Herrera
• Re: autovacuum doesnt run on the pg_toast_id table
  • From: Justin Pryzby
• autovacuum doesnt run on the pg_toast_id table
  • From: Mariel Cherkassky
• Re: No matching tables have ever been vacuumed
  • From: Laurenz Albe
• Parallel stats in execution plans
  • From: David Conlin
• No matching tables have ever been vacuumed
  • From: Daulat Ram
• Re: Detect missing combined indexes (automatically)
  • From: Julien Rouhaud
• Re: Detect missing combined indexes (automatically)
  • From: Thomas Güttler
• Re: Detect missing combined indexes (automatically)
  • From: Julien Rouhaud
• Re: Detect missing combined indexes (automatically)
  • From: Thomas Kellerer
• Re: Detect missing combined indexes (automatically)
  • From: Jim Finnerty
• Re: does dml operations load the blocks to the shared buffers ?
  • From: Guillaume Lelarge
• Detect missing combined indexes (automatically)
  • From: Thomas Güttler
• Re: does dml operations load the blocks to the shared buffers ?
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Ken Tanzer
• Re: PostgreSQL Read IOPS limit per connection
  • From: Mark Hogg
• Re: does dml operations load the blocks to the shared buffers ?
  • From: Guillaume Lelarge
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• does dml operations load the blocks to the shared buffers ?
  • From: Mariel Cherkassky
• Re: PostgreSQL Read IOPS limit per connection
  • From: Merlin Moncure
• Re: PostgreSQL Read IOPS limit per connection
  • From: Haroldo Kerry
• Re: select query does not pick up the right index
  • From: Abadie Lana
• Re: PostgreSQL Read IOPS limit per connection
  • From: Merlin Moncure
• Re: select query does not pick up the right index
  • From: David Rowley
• Re: postgresql unix socket connections
  • From: Tom Lane
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Jeff Janes
• Re: postgresql unix socket connections
  • From: Jeff Janes
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• Re: postgresql unix socket connections
  • From: Tom Lane
• RE: select query does not pick up the right index
  • From: Abadie Lana
• Re: postgresql unix socket connections
  • From: Mariel Cherkassky
• postgresql unix socket connections
  • From: Mariel Cherkassky
• 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