pgsql-performance  

Messages by Thread

• [PERFORM] Run one query and execution time is very different Metatrader EA
• [PERFORM] Performance decrease after upgrade to 9.6.1 Gabriela Serventi
  • Re: [PERFORM] Performance decrease after upgrade to 9.6.1 Tom Lane
  • Re: [PERFORM] Performance decrease after upgrade to 9.6.1 Gabriela Serventi
• [PERFORM] Sql Query :: Any advice ? Henrik Ekenberg
  • Re: [PERFORM] Sql Query :: Any advice ? vinny
  • Re: [PERFORM] Sql Query :: Any advice ? Henrik Ekenberg
  • Re: [PERFORM] Sql Query :: Any advice ? vinny
  • Re: [PERFORM] Sql Query :: Any advice ? Henrik
• [PERFORM] Why is the optimiser choosing a sub-optimal plan? Stephen Cresswell
  • Re: [PERFORM] Why is the optimiser choosing a sub-optimal plan? Tom Lane
• [PERFORM] Query planner chooses index scan backward instead of better index option Seckin Pulatkan
  • Re: [PERFORM] Query planner chooses index scan backward instead of better index option Jeff Janes
  • Re: [PERFORM] Query planner chooses index scan backward instead of better index option Seckin Pulatkan
  • Re: [PERFORM] Query planner chooses index scan backward instead of better index option Seckin Pulatkan
• [PERFORM] Some tuning suggestions on a Red Hat 6.7 - PG 9.5.3 production environment Pietro Pugni
  • Re: [PERFORM] Some tuning suggestions on a Red Hat 6.7 - PG 9.5.3 production environment domenico febbo
  • Re: [PERFORM] Some tuning suggestions on a Red Hat 6.7 - PG 9.5.3 production environment Pietro Pugni
  • Re: [PERFORM] Some tuning suggestions on a Red Hat 6.7 - PG 9.5.3 production environment Merlin Moncure
  • Re: [PERFORM] Some tuning suggestions on a Red Hat 6.7 - PG 9.5.3 production environment Jeff Janes
• [PERFORM] Any advice tuning this query ? Henrik Ekenberg
  • Re: [PERFORM] Any advice tuning this query ? Devrim Gündüz
  • Re: [PERFORM] Any advice tuning this query ? Andreas Karlsson
  • Re: [PERFORM] Any advice tuning this query ? Jeff Janes
• [PERFORM] Inlining of functions (doing LIKE on an array) l...@laurent-hasson.com
  • Re: [PERFORM] Inlining of functions (doing LIKE on an array) Marc Mamin
  • Re: [PERFORM] Inlining of functions (doing LIKE on an array) l...@laurent-hasson.com
  • Re: [PERFORM] Inlining of functions (doing LIKE on an array) Tom Lane
  • Re: [PERFORM] Inlining of functions (doing LIKE on an array) l...@laurent-hasson.com
  • Re: [PERFORM] Inlining of functions (doing LIKE on an array) Tom Lane
  • Re: [PERFORM] Inlining of functions (doing LIKE on an array) l...@laurent-hasson.com
  • Re: [PERFORM] Inlining of functions (doing LIKE on an array) Jeff Janes
• [PERFORM] Tuning one Recurcive CTE Henrik Ekenberg
  • Re: [PERFORM] Tuning one Recurcive CTE Andreas Joseph Krogh
  • Re: [PERFORM] Tuning one Recurcive CTE Henrik Ekenberg
  • Re: [PERFORM] Tuning one Recurcive CTE Andreas Joseph Krogh
• [PERFORM] Query much slower after upgrade to 9.6.1 Adam Brusselback
  • Re: [PERFORM] Query much slower after upgrade to 9.6.1 Adam Brusselback
  • Re: [PERFORM] Query much slower after upgrade to 9.6.1 Tom Lane
  • Re: [PERFORM] Query much slower after upgrade to 9.6.1 Adam Brusselback
  • Re: [PERFORM] Query much slower after upgrade to 9.6.1 Tom Lane
  • Re: [PERFORM] Query much slower after upgrade to 9.6.1 Adam Brusselback
• [PERFORM] Hot migration of tables YueLi
• [PERFORM] archive_command too slow. Joao Junior
  • Re: [PERFORM] archive_command too slow. Jeff Janes
  • Re: [PERFORM] archive_command too slow. Claudio Freire
  • Re: [PERFORM] archive_command too slow. Stephen Frost
• [PERFORM] no MCV list of tiny table with unique columns Justin Pryzby
  • Re: [PERFORM] no MCV list of tiny table with unique columns Tom Lane
  • Re: [PERFORM] no MCV list of tiny table with unique columns Justin Pryzby
  • Re: [PERFORM] no MCV list of tiny table with unique columns Tom Lane
  • Re: [PERFORM] no MCV list of tiny table with unique columns Justin Pryzby
• [PERFORM] Perf decreased although server is better Benjamin Toueg
  • Re: [PERFORM] Perf decreased although server is better Tomas Vondra
  • Re: [PERFORM] Perf decreased although server is better Kevin Grittner
  • Re: [PERFORM] Perf decreased although server is better Rick Otten
  • Re: [PERFORM] Perf decreased although server is better Benjamin Toueg
  • Re: [PERFORM] Perf decreased although server is better Kevin Grittner
  • Re: [PERFORM] Perf decreased although server is better Benjamin Toueg
  • Re: [PERFORM] Perf decreased although server is better Will Platnick
  • Re: [PERFORM] Perf decreased although server is better Rick Otten
  • Re: [PERFORM] Perf decreased although server is better Kevin Grittner
  • Re: [PERFORM] Perf decreased although server is better Benjamin Toueg
• [PERFORM] Refresh materialized view vs recreate Антон Мазунин
  • Re: [PERFORM] Refresh materialized view vs recreate Kevin Grittner
• Re: [PERFORM] Tuning Checkpoints Tomas Vondra
• [PERFORM] Big Memory Boxes and pgtune Warner, Gary, Jr
  • Re: [PERFORM] Big Memory Boxes and pgtune Kevin Grittner
  • Re: [PERFORM] Big Memory Boxes and pgtune Joshua D. Drake
  • Re: [PERFORM] Big Memory Boxes and pgtune Jim Nasby
  • Re: [PERFORM] Big Memory Boxes and pgtune Scott Marlowe
• [PERFORM] limit 1 on view never finishes Craig James
  • Re: [PERFORM] limit 1 on view never finishes Jim Nasby
• [PERFORM] query slowdown after 9.0 -> 9.4 migration Filip Rembiałkowski
  • Re: [PERFORM] query slowdown after 9.0 -> 9.4 migration Tomas Vondra
  • Re: [PERFORM] query slowdown after 9.0 -> 9.4 migration Andreas Kretschmer
  • Re: [PERFORM] query slowdown after 9.0 -> 9.4 migration Filip Rembiałkowski
  • Re: [PERFORM] query slowdown after 9.0 -> 9.4 migration Jim Nasby
• [PERFORM] Fast insert, but slow join and updates for table with 4 billion rows Lars Aksel Opsahl
  • Re: [PERFORM] Fast insert, but slow join and updates for table with 4 billion rows Tom Lane
  • Re: [PERFORM] Fast insert, but slow join and updates for table with 4 billion rows Lars Aksel Opsahl
  • Re: [PERFORM] Fast insert, but slow join and updates for table with 4 billion rows Scott Marlowe
  • Re: [PERFORM] Fast insert, but slow join and updates for table with 4 billion rows Lars Aksel Opsahl
  • Re: [PERFORM] Fast insert, but slow join and updates for table with 4 billion rows Lars Aksel Opsahl
• [PERFORM] Performance of a nested loop, whose inner loop uses an index scan. negora
  • Re: [PERFORM] Performance of a nested loop, whose inner loop uses an index scan. Matheus de Oliveira
  • Re: [PERFORM] Performance of a nested loop, whose inner loop uses an index scan. negora
• [PERFORM] Should I generate strings in Postgres of Python? Bobby Mozumder
  • Re: [PERFORM] Should I generate strings in Postgres of Python? Sam Gendler
• [PERFORM] Hibernate generated query slow compared to 'equivalent' hand written one Kyle Moser
  • Re: [PERFORM] Hibernate generated query slow compared to 'equivalent' hand written one Tom Lane
  • Re: [PERFORM] Hibernate generated query slow compared to 'equivalent' hand written one Kyle Moser
  • Re: [PERFORM] Hibernate generated query slow compared to 'equivalent' hand written one Tom Lane
• [PERFORM] pg_basebackup running slow Swapnil Vaze
  • Re: [PERFORM] pg_basebackup running slow Samir Magar
  • Re: [PERFORM] pg_basebackup running slow Michael Paquier
  • Re: [PERFORM] pg_basebackup running slow Stephen Frost
• [PERFORM] Delay in converting logs from ready state to done state Samir Magar
  • Re: [PERFORM] Delay in converting logs from ready state to done state Julien Rouhaud
  • Fwd: [PERFORM] Delay in converting logs from ready state to done state Samir Magar
• [PERFORM] Why query plan is different? Andrzej Zawadzki
  • Re: [PERFORM] Why query plan is different? Pavel Stehule
  • Re: [PERFORM] Why query plan is different? Andrzej Zawadzki
  • Re: [PERFORM] Why query plan is different? Andrzej Zawadzki
  • Re: [PERFORM] Why query plan is different? Pavel Stehule
  • Re: [PERFORM] Why query plan is different? Andrzej Zawadzki
  • Re: [PERFORM] Why query plan is different? Pavel Stehule
• [PERFORM] Understanding BRIN index performance Ivan Voras
  • Re: [PERFORM] Understanding BRIN index performance Madusudanan.B.N
  • Re: [PERFORM] Understanding BRIN index performance Simon Riggs
  • Re: [PERFORM] Understanding BRIN index performance Ivan Voras
  • Re: [PERFORM] Understanding BRIN index performance Simon Riggs
  • Re: [PERFORM] Understanding BRIN index performance Ivan Voras
• [PERFORM] MYSQL Stats Joe Proietti
  • Re: [PERFORM] MYSQL Stats Joe Proietti
  • Re: [PERFORM] MYSQL Stats Gavin Flower
• [PERFORM] Failing Multi-Job Restores, Missing Indexes on Restore Cea Stapleton
  • Re: [PERFORM] Failing Multi-Job Restores, Missing Indexes on Restore Tom Lane
  • Re: [PERFORM] Failing Multi-Job Restores, Missing Indexes on Restore Cea Stapleton
  • Re: [PERFORM] Failing Multi-Job Restores, Missing Indexes on Restore Tom Lane
• [PERFORM] Unexpected expensive index scan Jake Nielsen
  • Re: [PERFORM] Unexpected expensive index scan Jake Nielsen
  • Re: [PERFORM] Unexpected expensive index scan Mike Sofen
  • Re: [PERFORM] Unexpected expensive index scan Jake Nielsen
  • Re: [PERFORM] Unexpected expensive index scan Jake Nielsen
  • Re: [PERFORM] Unexpected expensive index scan Jake Nielsen
  • Re: [PERFORM] Unexpected expensive index scan Tom Lane
  • Re: [PERFORM] Unexpected expensive index scan Jake Nielsen
  • Re: [PERFORM] Unexpected expensive index scan Jim Nasby
• [PERFORM] temporary table vs array performance dby...@163.com
  • Re: [PERFORM] [HACKERS] temporary table vs array performance David G. Johnston
  • Re: [PERFORM] [HACKERS] temporary table vs array performance Pavel Stehule
• [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables julyanto SUTANDANG
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables julyanto SUTANDANG
  • Re: [PERFORM] Millions of tables Stuart Bishop
  • Re: [PERFORM] Millions of tables Rick Otten
  • Re: [PERFORM] Millions of tables Mike Sofen
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Yves Dorfsman
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Stuart Bishop
  • Re: [PERFORM] Millions of tables Simon Riggs
  • Re: [PERFORM] Millions of tables Mike Sofen
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Gavin Flower
  • Re: [PERFORM] Millions of tables Jeff Janes
  • Re: [PERFORM] Millions of tables Álvaro Hernández Tortosa
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Jeff Janes
  • Re: [PERFORM] Millions of tables Tom Lane
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Mike Sofen
  • Re: [PERFORM] Millions of tables Mike Sofen
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Stephen Frost
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Stephen Frost
  • Re: [PERFORM] Millions of tables Craig James
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Vitalii Tymchyshyn
  • Re: [PERFORM] Millions of tables Richard Albright
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Terry Schmitt
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Alex Ignatov (postgrespro)
  • Re: [PERFORM] Millions of tables Jim Nasby
  • Re: [PERFORM] Millions of tables Greg Spiegelberg
  • Re: [PERFORM] Millions of tables Jim Nasby
  • Re: [PERFORM] Millions of tables Robert Klemme
  • Re: [PERFORM] Millions of tables Jeff Janes
• [PERFORM] Storing large documents - one table or partition by doc? Dev Nop
  • Re: [PERFORM] Storing large documents - one table or partition by doc? Mike Sofen
  • Re: [PERFORM] Storing large documents - one table or partition by doc? Jim Nasby
  • Re: [PERFORM] Storing large documents - one table or partition by doc? Jeff Janes
  • Re: [PERFORM] Storing large documents - one table or partition by doc? Dev Nop
  • Re: [PERFORM] Storing large documents - one table or partition by doc? Jim Nasby
  • Re: [PERFORM] Storing large documents - one table or partition by doc? Dev Nop
  • Re: [PERFORM] Storing large documents - one table or partition by doc? Jim Nasby
• [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Sven R. Kunze
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Madusudanan.B.N
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Jeff Janes
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Igor Neyman
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Igor Neyman
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Igor Neyman
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Sven R. Kunze
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Sven R. Kunze
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Pavel Stehule
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Sven R. Kunze
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Pavel Stehule
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Jeff Janes
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Jeff Janes
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Sven R. Kunze
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Jeff Janes
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Sven R. Kunze
  • Re: [PERFORM] Multiple-Table-Spanning Joins with ORs in WHERE Clause Sven R. Kunze
• Re: [PERFORM] Problem with performance using query with unnest after migrating from V9.1 to V9.2 and higher Jim Nasby

• Earlier messages
• Later messages