Postgres Performance Date Index

• Thread Index

• Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Mario Splivalo
• Re: Bad plan for nested loop + limit
  • From: Alexander Staubo
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Josh Berkus
• Re: Very specialised query
  • From: Marc Mamin
• Re: I have a fusion IO drive available for testing
  • From: David Rees
• Re: Very specialised query
  • From: Dimitri Fontaine
• Re: Very specialised query
  • From: Tom Lane
• Re: I have a fusion IO drive available for testing
  • From: Jeff
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: I have a fusion IO drive available for testing
  • From: david
• Re: I have a fusion IO drive available for testing
  • From: Jeff
• Re: Very specialised query
  • From: Віталій Тимчишин
• Re: Very specialised query
  • From: Tom Lane
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Very specialised query
  • From: Tom Lane
• Re: Very specialised query
  • From: Kevin Grittner
• Very specialised query
  • From: Matthew Wakeling
• Re: I have a fusion IO drive available for testing
  • From: Kenny Gorman
• Re: I have a fusion IO drive available for testing
  • From: Luke Lonergan
• I have a fusion IO drive available for testing
  • From: Dave Cramer
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Bryan Murphy
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Tom Lane
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Bryan Murphy
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Tom Lane
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Bryan Murphy
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Josh Berkus
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Bryan Murphy
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Robert Haas
• Re: Raid 10 chunksize
  • From: Jerry Champlin
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Bryan Murphy
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Bryan Murphy
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: marcin mank
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Josh Berkus
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• Re: Raid 10 chunksize
  • From: David Rees
• Re: Raid 10 chunksize
  • From: Scott Carey
• Raid 10 chunksize
  • From: Mark Kirkwood
• Re: High CPU Utilization
  • From: Scott Carey
• Re: High CPU Utilization
  • From: Scott Marlowe
• Re: High CPU Utilization
  • From: Ron
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Bryan Murphy
• Re: Help Me Understand Why I'm Getting a Bad Query Plan
  • From: Bryan Murphy
• Re: High CPU Utilization
  • From: Scott Marlowe
• Re: High CPU Utilization
  • From: Greg Smith
• Re: High CPU Utilization
  • From: Joe Uhl
• Re: Why creating GIN table index is so slow than inserting data into empty table with the same index?
  • From: Tom Lane
• Re: Why creating GIN table index is so slow than inserting data into empty table with the same index?
  • From: Heikki Linnakangas
• Re: LIMIT confuses the planner
  • From: Kouber Saparev
• Re: Why creating GIN table index is so slow than inserting data into empty table with the same index?
  • From: Tom Lane
• Why creating GIN table index is so slow than inserting data into empty table with the same index?
  • From: Sergey Burladyan
• Re: multiple threads inserting into the same table
  • From: Tom Lane
• Re: multiple threads inserting into the same table
  • From: Tom Lane
• Re: multiple threads inserting into the same table
  • From: Brian Cox
• Re: multiple threads inserting into the same table
  • From: Brian Cox
• Re: multiple threads inserting into the same table
  • From: Scott Marlowe
• Re: multiple threads inserting into the same table
  • From: Brian Cox
• Re: multiple threads inserting into the same table
  • From: Tom Lane
• Re: Need help with one query
  • From: Anne Rosset
• Re: multiple threads inserting into the same table
  • From: David Wilson
• multiple threads inserting into the same table
  • From: Brian Cox
• Re: Need help with one query
  • From: Robert Haas
• Re: Need help with one query
  • From: Anne Rosset
• Re: Slower query after psql changed it's execution plan
  • From: Tom Lane
• Re: Slower query after psql changed it's execution plan
  • From: Kevin Grittner
• Slower query after psql changed it's execution plan
  • From: Romuald Brunet
• Re: "iowait" bug?
  • From: Greg Smith
• Re: LIMIT confuses the planner
  • From: Tom Lane
• Re: LIMIT confuses the planner
  • From: marcin mank
• Re: LIMIT confuses the planner
  • From: marcin mank
• Re: "iowait" bug?
  • From: Laurent Wandrebeck
• Re: LIMIT confuses the planner
  • From: Tom Lane
• Re: "iowait" bug?
  • From: Greg Smith
• Re: "iowait" bug?
  • From: Laurent Laborde
• Re: "iowait" bug?
  • From: Laurent Wandrebeck
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Simon Riggs
• "iowait" bug?
  • From: M. Edward (Ed) Borasky
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Robert Haas
• Re: Need help with one query
  • From: Robert Haas
• Re: Need help with one query
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Full statement logging problematic on larger machines?
  • From: Frank Joerdens
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Alvaro Herrera
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Alvaro Herrera
• Re: High CPU Utilization
  • From: Joe Uhl
• Re: High CPU Utilization
  • From: Scott Marlowe
• Re: High CPU Utilization
  • From: Joe Uhl
• Re: High CPU Utilization
  • From: Scott Marlowe
• Re: Need help with one query
  • From: Anne Rosset
• Re: High CPU Utilization
  • From: Joe Uhl
• Re: Full statement logging problematic on larger machines?
  • From: Frank Joerdens
• Re: Need help with one query
  • From: Alvaro Herrera
• Re: Need help with one query
  • From: Robert Haas
• Re: Full statement logging problematic on larger machines?
  • From: Frank Joerdens
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: current transaction in productive database
  • From: Euler Taveira de Oliveira
• Re: current transaction in productive database
  • From: Greg Smith
• Re: Need help with one query
  • From: Anne Rosset
• Re: current transaction in productive database
  • From: Jeff
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Alvaro Herrera
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Matthew Wakeling
• Re: Need help with one query
  • From: Tom Lane
• Re: Prepared statement does not exist
  • From: Glyn Astill
• current transaction in productive database
  • From: ml@xxxxxxxxx
• Re: Need help with one query
  • From: Richard Huxton
• Re: Prepared statement does not exist
  • From: Nimesh Satam
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Robert Haas
• Re: Postgres benchmarking with pgbench
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Bruce Momjian
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Postgres benchmarking with pgbench
  • From: Scott Carey
• Re: Postgres benchmarking with pgbench
  • From: Scott Marlowe
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Postgres benchmarking with pgbench
  • From: ml@xxxxxxxxx
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Robert Haas
• Need help with one query
  • From: Anne Rosset
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Bruce Momjian
• Re: Extremely slow intarray index creation and inserts.
  • From: Oleg Bartunov
• Re: Extremely slow intarray index creation and inserts.
  • From: Oleg Bartunov
• Re: Extremely slow intarray index creation and inserts.
  • From: Tom Lane
• Re: Prepared statement does not exist
  • From: Glyn Astill
• Prepared statement does not exist
  • From: Nimesh Satam
• Re: Extremely slow intarray index creation and inserts.
  • From: Oleg Bartunov
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Simon Riggs
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Simon Riggs
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Robert Haas
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: Extremely slow intarray index creation and inserts.
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Extremely slow intarray index creation and inserts.
  • From: Ron Mayer
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Matthew Wakeling
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• parallelizing slow queries for multiple cores (PostgreSQL + Gearman)
  • From: henk de wit
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Matthew Wakeling
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Simon Riggs
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Matthew Wakeling
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Heikki Linnakangas
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Matthew Wakeling
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Gregory Stark
• Re: Performance of archive logging in a PITR restore
  • From: Heikki Linnakangas
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Simon Riggs
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Simon Riggs
• Re: Extremely slow intarray index creation and inserts.
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Simon Riggs
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Simon Riggs
• Re: parallelizing slow queries for multiple cores (PostgreSQL + Gearman)
  • From: Greg Smith
• parallelizing slow queries for multiple cores (PostgreSQL + Gearman)
  • From: Marinos Yannikos
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Extremely slow intarray index creation and inserts.
  • From: Ron Mayer
• Extremely slow intarray index creation and inserts.
  • From: Ron Mayer
• Confused ! when insert with Preimary key, Freebsd 7.1 is slower thrice times then Debian5
  • From: luo roger
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Simon Riggs
• Re: Postgres benchmarking with pgbench
  • From: Scott Marlowe
• Re: High CPU Utilization
  • From: Greg Smith
• Re: Postgres benchmarking with pgbench
  • From: Greg Smith
• Re: High CPU Utilization
  • From: Greg Smith
• Re: High CPU Utilization
  • From: Gregory Stark
• Re: Postgres benchmarking with pgbench
  • From: Gregory Stark
• Re: High CPU Utilization
  • From: Scott Marlowe
• Re: High CPU Utilization
  • From: Joe Uhl
• Re: High CPU Utilization
  • From: Greg Smith
• Re: High CPU Utilization
  • From: Joe Uhl
• Re: High CPU Utilization
  • From: Alan Hodgson
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: [ADMIN] deployment query
  • From: Scott Marlowe
• High CPU Utilization
  • From: Joe Uhl
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Kevin Grittner
• Re: Postgres benchmarking with pgbench
  • From: Greg Smith
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Matthew Wakeling
• Re: Performance of archive logging in a PITR restore
  • From: Joshua D. Drake
• Performance of archive logging in a PITR restore
  • From: Mark Steben
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Kevin Grittner
• Re: Postgres benchmarking with pgbench
  • From: Gregory Stark
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Gregory Stark
• Re: Postgres benchmarking with pgbench
  • From: Greg Smith
• Postgres benchmarking with pgbench
  • From: ml@xxxxxxxxx
• deployment query
  • From: Nagalingam, Karthikeyan
• Re: Query much slower when run from postgres function
  • From: Віталій Тимчишин
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Query performance over a large proportion of data
  • From: Matteo Beccati
• Re: Proposal of tunable fix for scalability of 8.4
  • From: decibel
• Re: Proposal of tunable fix for scalability of 8.4
  • From: decibel
• Re: Proposal of tunable fix for scalability of 8.4
  • From: decibel
• Re: Proposal of tunable fix for scalability of 8.4
  • From: decibel
• Re: Query performance over a large proportion of data
  • From: decibel
• Re: Query much slower when run from postgres function
  • From: decibel
• Re: Query much slower when run from postgres function
  • From: decibel
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Simon Riggs
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Heikki Linnakangas
• Re: Proposal of tunable fix for scalability of 8.4
  • From: david
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Gregory Stark
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Robert Haas
• Re: Hash Join performance
  • From: Vamsidhar Thummala
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Gregory Stark
• Re: Hash Join performance
  • From: Tom Lane
• Re: Hash Join performance
  • From: Vamsidhar Thummala
• Re: Hash Join performance
  • From: Tom Lane
• Hash Join performance
  • From: Vamsidhar Thummala
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Kevin Grittner
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Greg Smith
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Kevin Grittner
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Kevin Grittner
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Alan Stange
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Gregory Stark
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Gregory Stark
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Gregory Stark
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Gregory Stark
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Gregory Stark
• 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Full statement logging problematic on larger machines?
  • From: Laurent Laborde
• Re: Full statement logging problematic on larger machines?
  • From: sathiya psql
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Greg Smith
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Greg Smith
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Robert Haas
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Full statement logging problematic on larger machines?
  • From: Laurent Laborde
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Greg Smith
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Kevin Grittner
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Alvaro Herrera
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Ron
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Entry point for Postgresql Performance
  • From: Rajesh Kumar Mallah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Gregory Stark
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Kevin Grittner
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Grzegorz Jaśkiewicz
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Kevin Grittner
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Kevin Grittner
• Re: Full statement logging problematic on larger machines?
  • From: Dimitri Fontaine
• Re: Full statement logging problematic on larger machines?
  • From: Frank Joerdens
• Re: Entry point for Postgresql Performance
  • From: Ashish Karalkar
• Entry point for Postgresql Performance
  • From: Nagalingam, Karthikeyan
• Re: Full statement logging problematic on larger machines?
  • From: Guillaume Smet
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Scott Carey
• Re: Full statement logging problematic on larger machines?
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Tom Lane
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Full statement logging problematic on larger machines?
  • From: Guillaume Smet
• Re: Full statement logging problematic on larger machines?
  • From: Frank Joerdens
• Re: Proposal of tunable fix for scalability of 8.4
  • From: Kevin Grittner
• Proposal of tunable fix for scalability of 8.4
  • From: Jignesh K. Shah
• Re: Full statement logging problematic on larger machines?
  • From: Tom Lane
• Re: random_page_cost vs ssd?
  • From: Scott Carey
• Re: Full statement logging problematic on larger machines?
  • From: Scott Marlowe
• Re: random_page_cost vs ssd?
  • From: Kevin Grittner
• Re: random_page_cost vs ssd?
  • From: hubert depesz lubaczewski
• Re: random_page_cost vs ssd?
  • From: Scott Carey
• Full statement logging problematic on larger machines?
  • From: Frank Joerdens
• Re: random_page_cost vs ssd?
  • From: Andrej
• Re: random_page_cost vs ssd?
  • From: Scott Carey
• Re: random_page_cost vs ssd?
  • From: Grzegorz Jaśkiewicz
• random_page_cost vs ssd?
  • From: Jeff
• Re: Query performance over a large proportion of data
  • From: Scott Marlowe
• Re: Query performance over a large proportion of data
  • From: Steve McLellan
• Re: Query performance over a large proportion of data
  • From: Steve McLellan
• Re: Query performance over a large proportion of data
  • From: Steve McLellan
• Re: Query performance over a large proportion of data
  • From: Tom Lane
• Re: Query performance over a large proportion of data
  • From: Tom Lane
• Re: Query performance over a large proportion of data
  • From: Scott Marlowe
• Re: Query performance over a large proportion of data
  • From: Kevin Grittner
• Re: Query performance over a large proportion of data
  • From: Scott Marlowe
• Query performance over a large proportion of data
  • From: Steve McLellan
• Re: When does sequential performance matter in PG?
  • From: Scott Carey
• Re: When does sequential performance matter in PG?
  • From: Greg Smith
• Re: Query much slower when run from postgres function
  • From: Tom Lane
• Re: When does sequential performance matter in PG?
  • From: henk de wit
• Re: Query much slower when run from postgres function
  • From: Frank Ch. Eigler
• Re: When does sequential performance matter in PG?
  • From: Matthew Wakeling
• When does sequential performance matter in PG?
  • From: henk de wit
• Re: [JDBC] Query much slower when run from postgres function
  • From: Scott Carey
• Re: DBT Presentation Location?
  • From: Mark Wong
• Re: Query much slower when run from postgres function
  • From: Tom Lane
• Re: Query much slower when run from postgres function
  • From: Mario Splivalo
• Re: [JDBC] Query much slower when run from postgres function
  • From: Scott Carey
• Re: [JDBC] Query much slower when run from postgres function
  • From: James Mansion
• Re: [JDBC] Query much slower when run from postgres function
  • From: Dave Cramer
• Re: Query much slower when run from postgres function
  • From: Tom Lane
• Re: Query much slower when run from postgres function
  • From: Mario Splivalo
• Re: Query much slower when run from postgres function
  • From: Mario Splivalo
• Re: [JDBC] Query much slower when run from postgres function
  • From: Tom Lane
• Re: [JDBC] Query much slower when run from postgres function
  • From: Andreas Wenk
• Re: [JDBC] Query much slower when run from postgres function
  • From: Guillaume Smet
• Re: Query much slower when run from postgres function
  • From: Guillaume Cottenceau
• Re: Query much slower when run from postgres function
  • From: Tom Lane
• DBT Presentation Location?
  • From: Lee Hughes
• Query much slower when run from postgres function
  • From: Mario Splivalo
• Re: Postgres 8.3, four times slower queries?
  • From: Aaron Guyon
• Re: Index scan plan estimates way off.
  • From: Robert Haas
• Re: Index scan plan estimates way off.
  • From: Jonathan Hseu
• Re: Postgres 8.3, four times slower queries?
  • From: Aaron Guyon
• Re: Postgres 8.3, four times slower queries?
  • From: Robert Haas
• Re: Postgres 8.3, four times slower queries?
  • From: Kevin Grittner
• Re: Index scan plan estimates way off.
  • From: Tom Lane
• Re: Postgres 8.3, four times slower queries?
  • From: Aaron Guyon
• Index scan plan estimates way off.
  • From: Jonathan Hseu
• Re: Postgres 8.3, four times slower queries?
  • From: Robert Haas
• Re: Postgres 8.3, four times slower queries?
  • From: Robert Haas
• Re: Postgres 8.3, four times slower queries?
  • From: Aaron Guyon
• Re: Postgres 8.3, four times slower queries?
  • From: Aaron Guyon
• Re: Postgres 8.3, four times slower queries?
  • From: Aaron Guyon
• Re: work_mem in high transaction rate database
  • From: Scott Marlowe
• Re: work_mem in high transaction rate database
  • From: Scott Carey
• Long Running Commits
  • From: Brad Nicholson
• Re: work_mem in high transaction rate database
  • From: Flavio Henrique Araque Gurgel
• Re: work_mem in high transaction rate database
  • From: Dimitri Fontaine
• Re: work_mem in high transaction rate database
  • From: Akos Gabriel
• Re: work_mem in high transaction rate database
  • From: Scott Marlowe
• work_mem in high transaction rate database
  • From: Flavio Henrique Araque Gurgel
• Re: Postgres 8.3, four times slower queries?
  • From: Tom Lane
• Re: Problems with ordering (can't force query planner to use an index)
  • From: Tom Lane
• Re: Problems with ordering (can't force query planner to use an index)
  • From: Robert Haas
• Re: Problems with ordering (can't force query planner to use an index)
  • From: Sebastjan Trepca
• Re: Problems with ordering (can't force query planner to use an index)
  • From: Sebastjan Trepca
• Re: Postgres 8.3, four times slower queries?
  • From: Aaron Guyon
• Re: Problems with ordering (can't force query planner to use an index)
  • From: Sebastjan Trepca
• Re: Problems with ordering (can't force query planner to use an index)
  • From: Robert Haas
• Re: Postgres 8.3, four times slower queries?
  • From: david
• Re: Problems with ordering (can't force query planner to use an index)
  • From: David Wilson
• Re: Postgres 8.3, four times slower queries?
  • From: Aaron Guyon
• Re: Problems with ordering (can't force query planner to use an index)
  • From: Sebastjan Trepca
• Re: Problems with ordering (can't force query planner to use an index)
  • From: Robert Haas
• Problems with ordering (can't force query planner to use an index)
  • From: Sebastjan Trepca
• Substring search using "exists" with a space in the search term
  • From: Hans Liebenberg
• Re: Postgres 8.3, four times slower queries?
  • From: Tom Lane
• Postgres 8.3, four times slower queries?
  • From: Aaron Guyon
• Re: "slow" queries
  • From: Scott Marlowe
• Re: "slow" queries
  • From: Tim Bunce
• Re: "slow" queries
  • From: Brian Cox
• Re: "slow" queries
  • From: Tom Lane
• Re: "slow" queries
  • From: Brian Cox
• Re: "slow" queries
  • From: Tom Lane
• Re: "slow" queries
  • From: Robert Haas
• Re: "slow" queries
  • From: Scott Carey
• Re: "slow" queries
  • From: Brian Cox
• Re: "slow" queries
  • From: Tom Lane
• Re: "slow" queries
  • From: Cox, Brian
• Re: TCP network cost
  • From: Linos
• Re: TCP network cost
  • From: Magnus Hagander
• Re: TCP network cost
  • From: Tom Lane
• Re: TCP network cost
  • From: Linos
• Re: TCP network cost
  • From: Tom Lane
• Re: TCP network cost
  • From: Linos
• Re: TCP network cost
  • From: Tom Lane
• Re: TCP network cost
  • From: Linos
• Re: "slow" queries
  • From: Tom Lane
• Re: Bad plan for nested loop + limit
  • From: Robert Haas
• Re: "slow" queries
  • From: Robert Haas
• "slow" queries
  • From: Brian Cox
• Re: Bad plan for nested loop + limit
  • From: Alexander Staubo
• Re: Bad plan for nested loop + limit
  • From: Robert Haas
• Re: Bad plan for nested loop + limit
  • From: Alexander Staubo
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Steve Clark
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Scott Marlowe
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Kevin Grittner
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Akos Gabriel
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Claus Guttesen
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Robert Haas
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Scott Carey
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Kevin Grittner
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Kevin Grittner
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Akos Gabriel
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Scott Marlowe
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Robert Haas
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Claus Guttesen
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Robert Haas
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Scott Marlowe
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Robert Haas
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Rodrigo E. De León Plicet
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Scott Marlowe
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Robert Haas
• Re: PostgreSQL block size for SSD RAID setup?
  • From: Scott Carey
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Robert Haas
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: PostgreSQL block size for SSD RAID setup?
  • From: PFC
• Re: full text search - dictionary caching
  • From: Tom Lane
• Re: PostgreSQL block size for SSD RAID setup?
  • From: henk de wit
• Re: PostgreSQL block size for SSD RAID setup?
  • From: Gregory Stark
• PostgreSQL block size for SSD RAID setup?
  • From: henk de wit
• full text search - dictionary caching
  • From: Tomasz Myrta
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Robert Haas
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Claus Guttesen
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: LIMIT confuses the planner
  • From: Kouber Saparev
• Re: TCP network cost
  • From: Ross J. Reedstrom
• will 8.4 be able to optmize rank() windows ?
  • From: Grzegorz Jaśkiewicz
• Re: planner's midjudge number of rows resulting, despite pretty obvious join
  • From: Pavel Stehule
• planner's midjudge number of rows resulting, despite pretty obvious join
  • From: Grzegorz Jaśkiewicz
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Claus Guttesen
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Tom Lane
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Tom Lane
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Scott Marlowe
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Scott Marlowe
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Scott Marlowe
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: postgreSQL performance 8.2.6 vs 8.3.3
  • From: Scott Marlowe
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Guillaume Smet
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Scott Marlowe
• Re: Abnormal performance difference between Postgres and MySQL
  • From: Gregory Stark
• Abnormal performance difference between Postgres and MySQL
  • From: Farhan Husain
• Re: TCP network cost
  • From: Tom Lane
• Re: postgreSQL performance 8.2.6 vs 8.3.3
  • From: david
• Re: TCP network cost
  • From: Ross J. Reedstrom
• Re: TCP network cost
  • From: Ross J. Reedstrom
• Re: LIMIT confuses the planner
  • From: Kouber Saparev
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Sergio Lopez
• Re: LIMIT confuses the planner
  • From: Tom Lane
• Re: LIMIT confuses the planner
  • From: Kouber Saparev
• Re: LIMIT confuses the planner
  • From: Tom Lane
• Re: LIMIT confuses the planner
  • From: Robert Haas
• Re: LIMIT confuses the planner
  • From: Richard Huxton
• LIMIT confuses the planner
  • From: Kouber Saparev
• Re: dbt-2 tuning results with postgresql-8.3.5
  • From: Mark Wong
• Re: not in(subselect) in 8.4
  • From: Grzegorz Jaśkiewicz
• Re: not in(subselect) in 8.4
  • From: Robert Haas
• Re: not in(subselect) in 8.4
  • From: Tom Lane
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Jonah H. Harris
• Re: not in(subselect) in 8.4
  • From: Scott Carey
• Re: not in(subselect) in 8.4
  • From: Tom Lane
• Re: not in(subselect) in 8.4
  • From: Grzegorz Jaśkiewicz
• Re: not in(subselect) in 8.4
  • From: Tom Lane
• Re: Partial index usage
  • From: decibel
• Re: not in(subselect) in 8.4
  • From: Grzegorz Jaśkiewicz
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Denis Lussier
• Re: how the hdd read speed is related to the query execution speed.
  • From: Andreas Kretschmer
• how the hdd read speed is related to the query execution speed.
  • From: sathiya psql
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Sergio Lopez
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Sergio Lopez
• Re: not in(subselect) in 8.4
  • From: Rodrigo E. De León Plicet
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Mark Kirkwood
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Scott Marlowe
• Re: postgreSQL performance 8.2.6 vs 8.3.3
  • From: Scott Marlowe
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Robert Haas
• Re: postgreSQL performance 8.2.6 vs 8.3.3
  • From: David Rees
• Re: postgreSQL performance 8.2.6 vs 8.3.3
  • From: Kenneth Marshall
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Jonah H. Harris
• postgreSQL performance 8.2.6 vs 8.3.3
  • From: Battle Mage
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Merlin Moncure
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Jonah H. Harris
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Jonah H. Harris
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Jonah H. Harris
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Robert Haas
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Sergio Lopez
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Jonah H. Harris
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Sergio Lopez
• Re: Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Alan Hodgson
• Benchmark comparing PostgreSQL, MySQL and Oracle
  • From: Sergio Lopez
• Re: not in(subselect) in 8.4
  • From: Grzegorz Jaśkiewicz
• Re: not in(subselect) in 8.4
  • From: Tom Lane
• Re: SSD performance
  • From: Matthew Wakeling
• Re: not in(subselect) in 8.4
  • From: marcin mank
• Re: not in(subselect) in 8.4
  • From: Grzegorz Jaśkiewicz
• not in(subselect) in 8.4
  • From: Grzegorz Jaśkiewicz
• Re: TCP network cost
  • From: PFC
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Rajesh Kumar Mallah
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Scott Carey
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Scott Carey
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Scott Carey
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Grzegorz Jaśkiewicz
• Re: TCP network cost
  • From: Gregory Stark
• Re: Call of function inside trigger much slower than explicit function call
  • From: Alexander Gorban
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Rajesh Kumar Mallah
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Grzegorz Jaśkiewicz
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Scott Marlowe
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Rajesh Kumar Mallah
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Scott Marlowe
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Rajesh Kumar Mallah
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Rajesh Kumar Mallah
• Re: Call of function inside trigger much slower than explicit function call
  • From: ivo nascimento
• Re: TCP network cost
  • From: Aaron Turner
• Re: TCP network cost
  • From: Ross J. Reedstrom
• Re: TCP network cost
  • From: Ross J. Reedstrom
• Re: TCP network cost
  • From: Rusty Conover
• Re: TCP network cost
  • From: Ross J. Reedstrom
• Re: Call of function inside trigger much slower than explicit function call
  • From: Robert Haas
• Re: Query composite index range in an efficient way
  • From: Havasvölgyi Ottó
• Re: TCP network cost
  • From: Aaron Turner
• Re: Call of function inside trigger much slower than explicit function call
  • From: Alexander Gorban
• Re: Call of function inside trigger much slower than explicit function call
  • From: Robert Haas
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Scott Carey
• Call of function inside trigger much slower than explicit function call
  • From: Alexander Gorban
• Re: Query composite index range in an efficient way
  • From: Kevin Grittner
• Re: Query composite index range in an efficient way
  • From: Tom Lane
• Cannot interpret EXPLAIN
  • From: Jörg Kiegeland
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Rajesh Kumar Mallah
• Re: Query composite index range in an efficient way
  • From: Gregory Stark
• Re: Query composite index range in an efficient way
  • From: Matthew Wakeling
• Query composite index range in an efficient way
  • From: Havasvölgyi Ottó
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Matthew Wakeling
• Re: TCP network cost
  • From: david
• Re: TCP network cost
  • From: Rusty Conover
• TCP network cost
  • From: Ross J. Reedstrom
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Rajesh Kumar Mallah
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Rajesh Kumar Mallah
• Re: Partial index usage
  • From: Craig Ringer
• Re: I/O increase after upgrading to 8.3.5
  • From: Alexander Staubo
• Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
  • From: Gregory Stark
• Partial index usage
  • From: Laszlo Nagy
• Re: I/O increase after upgrading to 8.3.5
  • From: Greg Smith
• Re: I/O increase after upgrading to 8.3.5
  • From: Greg Smith
• Re: Bad plan for nested loop + limit
  • From: Alexander Staubo
• Re: Bad plan for nested loop + limit
  • From: David Wilson
• Bad plan for nested loop + limit
  • From: Alexander Staubo
• Re: Slow queries from information schema
  • From: Octavio Alvarez
• Re: I/O increase after upgrading to 8.3.5
  • From: Alexander Staubo
• Re: Slow queries from information schema
  • From: Tom Lane
• Re: I/O increase after upgrading to 8.3.5
  • From: Tom Lane
• Re: I/O increase after upgrading to 8.3.5
  • From: Alexander Staubo
• Re: I/O increase after upgrading to 8.3.5
  • From: Alexander Staubo
• Slow queries from information schema
  • From: Octavio Alvarez
• Retrieving data from PostgreSQL to .NET application – performance test – surprising results
  • From: Peter G.
• Re: scheduling autovacuum at lean hours only.
  • From: Rajesh Kumar Mallah
• Re: scheduling autovacuum at lean hours only.
  • From: Chris Browne
• Re: I/O increase after upgrading to 8.3.5
  • From: Craig Ringer
• Re: dissimilar drives in Raid10 , does it make difference ?
  • From: Craig Ringer
• Re: I/O increase after upgrading to 8.3.5
  • From: Kevin Grittner
• Re: [HACKERS] GIST versus GIN indexes for intarrays
  • From: Tom Lane
• Re: I/O increase after upgrading to 8.3.5
  • From: Alexander Staubo
• Re: I/O increase after upgrading to 8.3.5
  • From: Kevin Grittner
• Re: I/O increase after upgrading to 8.3.5
  • From: Alexander Staubo
• Re: I/O increase after upgrading to 8.3.5
  • From: Alexander Staubo
• Re: I/O increase after upgrading to 8.3.5
  • From: Kevin Grittner
• Re: dissimilar drives in Raid10 , does it make difference ?
  • From: Matthew Wakeling
• Re: [HACKERS] GIST versus GIN indexes for intarrays
  • From: Kenneth Marshall
• dissimilar drives in Raid10 , does it make difference ?
  • From: Rajesh Kumar Mallah
• I/O increase after upgrading to 8.3.5
  • From: Alexander Staubo
• Re: GIST versus GIN indexes for intarrays
  • From: Rusty Conover
• Re: col1 ILIKE 'foo%' not behaving the same as lower(col1) LIKE 'foo%'
  • From: milos d
• Re: GIST versus GIN indexes for intarrays
  • From: Tom Lane
• Re: GIST versus GIN indexes for intarrays
  • From: Rusty Conover
• Re: GIST versus GIN indexes for intarrays
  • From: Tom Lane
• GIST versus GIN indexes for intarrays
  • From: Rusty Conover
• Re: col1 ILIKE 'foo%' not behaving the same as lower(col1) LIKE 'foo%'
  • From: Scott Carey
• Re: col1 ILIKE 'foo%' not behaving the same as lower(col1) LIKE 'foo%'
  • From: Richard Huxton
• col1 ILIKE 'foo%' not behaving the same as lower(col1) LIKE 'foo%'
  • From: milos d
• Re: scheduling autovacuum at lean hours only.
  • From: Guillaume Cottenceau
• Re: scheduling autovacuum at lean hours only.
  • From: Rajesh Kumar Mallah
• Re: scheduling autovacuum at lean hours only.
  • From: Brad Nicholson
• Re: scheduling autovacuum at lean hours only.
  • From: Ben Chobot
• Re: scheduling autovacuum at lean hours only.
  • From: Rajesh Kumar Mallah
• Re: scheduling autovacuum at lean hours only.
  • From: Scott Carey
• Re: scheduling autovacuum at lean hours only.
  • From: Ben
• Re: scheduling autovacuum at lean hours only.
  • From: Grzegorz Jaśkiewicz
• Re: scheduling autovacuum at lean hours only.
  • From: Alvaro Herrera
• Re: scheduling autovacuum at lean hours only.
  • From: Rajesh Kumar Mallah
• Re: scheduling autovacuum at lean hours only.
  • From: Guillaume Cottenceau
• Re: scheduling autovacuum at lean hours only.
  • From: Glyn Astill
• scheduling autovacuum at lean hours only.
  • From: Rajesh Kumar Mallah
• Re: please help with the explain analyze plan
  • From: Rajesh Kumar Mallah
• Re: please help with the explain analyze plan
  • From: Rajesh Kumar Mallah
• Re: please help with the explain analyze plan
  • From: Glyn Astill
• please help with the explain analyze plan
  • From: Rajesh Kumar Mallah
• Re: View performance degraded between 8.1 and 8.3
  • From: Tom Lane
• View performance degraded between 8.1 and 8.3
  • From: Mark Roghelia
• Re: explanation of some configs
  • From: justin
• Re: explanation of some configs
  • From: Greg Smith
• Re: explanation of some configs
  • From: justin
• Re: explanation of some configs
  • From: Greg Smith
• Re: explanation of some configs
  • From: justin
• Re: query becomes fas on 'SET enable_hashjoin TO off;'
  • From: Rajesh Kumar Mallah
• Re: query becomes fas on 'SET enable_hashjoin TO off;'
  • From: Tom Lane
• Re: query slow only after reboot
  • From: Kevin Grittner
• Re: ERROR: Can't use an undefined value as an ARRAY reference at /usr/lib/perl5/site_perl/5.8.8/Test/Parser/Dbt2.pm line 521.
  • From: Rajesh Kumar Mallah
• Re: query becomes fas on 'SET enable_hashjoin TO off;'
  • From: Rajesh Kumar Mallah
• Re: query becomes fas on 'SET enable_hashjoin TO off;'
  • From: Robert Haas
• ERROR: Can't use an undefined value as an ARRAY reference at /usr/lib/perl5/site_perl/5.8.8/Test/Parser/Dbt2.pm line 521.
  • From: Rohan Pethkar
• Re: explanation of some configs
  • From: Matthew Wakeling
• query becomes fas on 'SET enable_hashjoin TO off;'
  • From: Rajesh Kumar Mallah
• Re: query slow only after reboot
  • From: Scott Carey
• Re: query slow only after reboot
  • From: Steve Crawford
• query slow only after reboot
  • From: Wei Yan
• Re: explanation of some configs
  • From: Robert Haas
• Re: explanation of some configs
  • From: justin
• Re: explanation of some configs
  • From: Matthew Wakeling
• Re: Postgres not willing to use an index?
  • From: Mario Splivalo
• Re: Postgres not willing to use an index?
  • From: Mario Splivalo
• Re: Postgres not willing to use an index?
  • From: Mario Splivalo
• Re: inheritance, and plans
  • From: Grzegorz Jaśkiewicz
• Re: inheritance, and plans
  • From: Andrew Gierth
• Re: inheritance, and plans
  • From: Tom Lane
• Re: inheritance, and plans
  • From: Andrew Gierth
• Re: inheritance, and plans
  • From: Grzegorz Jaśkiewicz
• Re: inheritance, and plans
  • From: Grzegorz Jaśkiewicz
• Re: inheritance, and plans
  • From: Tom Lane
• Re: inheritance, and plans
  • From: Grzegorz Jaśkiewicz
• Re: explanation of some configs
  • From: Robert Haas
• Re: explanation of some configs
  • From: justin
• Re: inheritance, and plans
  • From: Grzegorz Jaśkiewicz
• Re: inheritance, and plans
  • From: Grzegorz Jaśkiewicz
• Re: explanation of some configs
  • From: Thomas Finneid
• Re: Can't locate Test/Parser/Dbt2.pm in DBT2 tests
  • From: Mark Wong
• Re: Getting error while running DBT2 test for PostgreSQL
  • From: Mark Wong