• Text Size: Normal / Large
• Donate
• Contact

Section Navigation

• Community
• Mailing Lists
  • Subscribe
  • User lists
    • pgsql-admin
    • pgsql-advocacy
    • pgsql-announce
    • pgsql-bugs
    • pgsql-docs
    • pgsql-cygwin
    • pgsql-general
    • pgsql-interfaces
    • pgsql-jdbc
    • pgsql-jobs
    • pgsql-novice
    • pgsql-odbc
    • pgsql -performance
    • pgsql-php
    • pgsql-ports
    • pgsql-sql
  • Developer lists
  • Regional lists
  • Project lists
  • User groups
  • Inactive lists
• IRC
• In The Real World
• International Sites
• Propaganda
• Resources
• Weekly News

pgsql-performance 2006-04 Thread Index (2/4)

• Main Index
• [Prev Page]
• [Next Page]

• Recovery will take 10 hours Brendan Duddridge
• Re: Recovery will take 10 hours Tom Lane
• Re: Recovery will take 10 hours Brendan Duddridge
• Re: Recovery will take 10 hours Tom Lane
• Re: Recovery will take 10 hours Brendan Duddridge
• Re: Recovery will take 10 hours Tom Lane
• Re: Recovery will take 10 hours Brendan Duddridge
• Re: Recovery will take 10 hours Brendan Duddridge
• Message not available
• Re: Recovery will take 10 hours Brendan Duddridge
• Re: Recovery will take 10 hours Gavin Sherry
• Re: Recovery will take 10 hours Luke Lonergan
• Re: Recovery will take 10 hours Jeff Frost
• Re: Recovery will take 10 hours Brendan Duddridge
• Re: Recovery will take 10 hours Brendan Duddridge
• Re: Recovery will take 10 hours Jeff Frost
• Re: Recovery will take 10 hours Tom Lane
• Re: Recovery will take 10 hours Brendan Duddridge
• Re: Recovery will take 10 hours Simon Riggs
• Re: Recovery will take 10 hours Brendan Duddridge
• Re: Recovery will take 10 hours Markus Schaber
• Re: Recovery will take 10 hours Simon Riggs
• Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
• Re: Hardware: HP StorageWorks MSA 1500 Mark Lewis
• Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
• <Possible follow-ups>
• Re: Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
• Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood
• Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
• Re: Hardware: HP StorageWorks MSA 1500 mlartz(at)gmail(dot)com
• Re: Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
• Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood
• Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
• Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood
• Slow deletes in 8.1 when FKs are involved Will Reese
• Re: Slow deletes in 8.1 when FKs are involved Stef T
• Re: Slow deletes in 8.1 when FKs are involved Will Reese
• <Possible follow-ups>
• Slow deletes in 8.1 when FKs are involved Will Reese
• Re: Slow deletes in 8.1 when FKs are involved Tom Lane
• Re: Slow deletes in 8.1 when FKs are involved Will Reese
• Re: Slow deletes in 8.1 when FKs are involved Jim C. Nasby
• Performance decrease Radovan Antloga
• Re: Performance decrease Tom Lane
• Re: Performance decrease Radovan Antloga
• Re: Performance decrease Jim C. Nasby
• Re: Performance decrease Guido Neitzer
• IBM pSeries - overrated bucket of crud? Gavin Hamill
• Identical query on two machines, different plans.... Mario Splivalo
• Re: Identical query on two machines, different plans.... Csaba Nagy
• Re: Identical query on two machines, different plans.... Mario Splivalo
• Re: Identical query on two machines, different plans.... Csaba Nagy
• Quick Performance Poll Simon Dale
• Re: Quick Performance Poll Jim Buttafuoco
• Re: Quick Performance Poll Luke Lonergan
• Re: Quick Performance Poll Jim Buttafuoco
• Re: Quick Performance Poll Luke Lonergan
• Re: Quick Performance Poll Jim Buttafuoco
• Re: Quick Performance Poll Markus Schaber
• Re: Quick Performance Poll Luke Lonergan
• Re: Quick Performance Poll Milen Kulev
• Re: Quick Performance Poll Luke Lonergan
• Re: Quick Performance Poll Milen Kulev
• Re: Quick Performance Poll Jim C. Nasby
• Perfrmance Problems (7.4.6) Doron Baranes
• Re: Perfrmance Problems (7.4.6) Ruben Rubio Rey
• <Possible follow-ups>
• Re: Perfrmance Problems (7.4.6) Doron Baranes
• Re: Perfrmance Problems (7.4.6) Ruben Rubio Rey
• Introducing a new linux readahead framework Wu Fengguang
• <Possible follow-ups>
• Introducing a new linux readahead framework Wu Fengguang
• Re: Introducing a new linux readahead framework Jim C. Nasby
• Re: Introducing a new linux readahead framework Wu Fengguang
• Re: Introducing a new linux readahead framework Markus Schaber
• Re: Introducing a new linux readahead framework Wu Fengguang
• Re: Introducing a new linux readahead framework Jim C. Nasby
• Re: Introducing a new linux readahead framework Wu Fengguang
• Re: Introducing a new linux readahead framework Michael Stone
• Re: Introducing a new linux readahead framework Michael Stone
• Re: Introducing a new linux readahead framework Steve Poe
• Re: Introducing a new linux readahead framework Jim C. Nasby
• Re: [Bizgres-general] Introducing a new linux Luke Lonergan
• Re: [Bizgres-general] Introducing a new linux Michael Stone
• Planner doesn't chose Index - (slow select) patrick keshishian
• Re: Planner doesn't chose Index - (slow select) Tom Lane
• Re: Planner doesn't chose Index - (slow select) patrick keshishian
• Multicolumn order by Theo Kramer
• Re: Multicolumn order by Tom Lane
• Re: Multicolumn order by Theo Kramer
• Re: Multicolumn order by Theo Kramer
• Re: Multicolumn order by Jim C. Nasby
• Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• Re: Problem with LIKE-Performance Dave Dutcher
• Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• Re: Problem with LIKE-Performance Guido Neitzer
• Re: Problem with LIKE-Performance REISS Thomas DSIC DESP
• Re: Problem with LIKE-Performance Tom Lane
• Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• Re: Problem with LIKE-Performance Tom Lane
• Re: [bulk] Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• Re: [bulk] Re: Problem with LIKE-Performance Richard Huxton
• Re: [bulk] Re: [bulk] Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• <Possible follow-ups>
• Re: Problem with LIKE-Performance Hakan Kocaman
• Re: [bulk] RE: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• SELECT FOR UPDATE performance is bad Mario Splivalo
• Re: SELECT FOR UPDATE performance is bad Tom Lane
• Message not available
  • Re: SELECT FOR UPDATE performance is bad Tom Lane
  • Re: SELECT FOR UPDATE performance is bad PFC
  • Re: SELECT FOR UPDATE performance is bad Christopher Kings-Lynne
  • Re: SELECT FOR UPDATE performance is bad Mario Splivalo
  • Re: SELECT FOR UPDATE performance is bad Jim C. Nasby
  • Re: SELECT FOR UPDATE performance is bad Mario Splivalo
• creating of temporary table takes very long Sriram Dandapani
• Re: creating of temporary table takes very long Tom Lane
• <Possible follow-ups>
• Re: creating of temporary table takes very long Sriram Dandapani
• Re: creating of temporary table takes very long Sriram Dandapani
• Re: creating of temporary table takes very long Sriram Dandapani
• Re: creating of temporary table takes very long Tom Lane
• Re: creating of temporary table takes very long Sriram Dandapani
• Re: creating of temporary table takes very long Jim C. Nasby
• Re: creating of temporary table takes very long Tom Lane
• slow cursor Sriram Dandapani
• Re: slow cursor Luckys
• Migration study, step 2: rewriting queries Mikael Carneholm
• Re: Migration study, step 2: rewriting queries Tom Lane
• <Possible follow-ups>
• Re: Migration study, step 2: rewriting queries Mikael Carneholm
• Re: Migration study, step 2: rewriting queries Tom Lane
• merge>hash>loop Ian Westmacott
• Re: merge>hash>loop Tom Lane
• Re: merge>hash>loop Ian Westmacott
• Re: merge>hash>loop Tom Lane
• Re: merge>hash>loop Markus Schaber
• Re: merge>hash>loop Jim C. Nasby
• Re: merge>hash>loop Tom Lane
• Re: merge>hash>loop Jim C. Nasby
• Re: merge>hash>loop Mark Kirkwood
• Re: merge>hash>loop Jim C. Nasby
• Re: merge>hash>loop Tom Lane
• Re: merge>hash>loop Mark Kirkwood
• Re: merge>hash>loop Jim C. Nasby
• Re: merge>hash>loop Tom Lane
• Re: merge>hash>loop Jim C. Nasby
• Re: merge>hash>loop Tom Lane
• pg_toast size Julien Drouard
• Re: pg_toast size Jim C. Nasby
• Blocks read for index scans Jim Nasby
• Re: Blocks read for index scans Tom Lane
• Re: Blocks read for index scans Jim C. Nasby
• Re: Blocks read for index scans Tom Lane
• Re: Blocks read for index scans Jim C. Nasby
• Re: Blocks read for index scans Terje Elde
• Re: Blocks read for index scans Jim C. Nasby
• Re: Blocks read for index scans Terje Elde
• Re: Blocks read for index scans Jim C. Nasby
• Re: Blocks read for index scans Mark Kirkwood
• <Possible follow-ups>
• Re: Blocks read for index scans Jim Nasby
• Slow query - possible bug? Gavin Hamill
• Re: Slow query - possible bug? chris smith
• Re: Slow query - possible bug? Gavin Hamill
• Re: Slow query - possible bug? Richard Huxton
• Re: Slow query - possible bug? Tom Lane
• Re: Slow query - possible bug? Gavin Hamill
• Re: Slow query - possible bug? Tom Lane
• Re: Slow query - possible bug? Gavin Hamill
• Re: Slow query - possible bug? Tom Lane
• Re: Slow query - possible bug? Gavin Hamill
• index is not used if I include a function that returns current time in my query Cris Carampa
• Re: index is not used if I include a function that returns current time in my query Jim C. Nasby
• <Possible follow-ups>
• index is not used if I include a function that returns current time in my query Cristian Veronesi
• Re: index is not used if I include a function that returns current time in my query Tom Lane
• pg 7.4.x - pg_restore impossibly slow patrick keshishian
• Re: pg 7.4.x - pg_restore impossibly slow Tom Lane
• Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
• Re: pg 7.4.x - pg_restore impossibly slow Tom Lane
• Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
• Re: pg 7.4.x - pg_restore impossibly slow Jim C. Nasby
• Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
• Inserts optimization? Francisco Reyes
• Re: Inserts optimization? Chris
• Re: Inserts optimization? Tom Lane
• Re: Inserts optimization? Francisco Reyes
• Re: Inserts optimization? Jim C. Nasby
• Re: Inserts optimization? Francisco Reyes
• Re: Inserts optimization? Michael Stone

---

• Main Index
• [Prev Page]
• [Next Page]

---

Mail converted by MHonArc