Postgres Performance Date Index

• Thread Index

• Re: Really dumb planner decision
  • From: Tom Lane
• Re: Really dumb planner decision
  • From: Merlin Moncure
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Merlin Moncure
• Re: Really dumb planner decision
  • From: Matthew Wakeling
• Re: Really dumb planner decision
  • From: Robert Haas
• Re: Really dumb planner decision
  • From: Matthew Wakeling
• Re: Really dumb planner decision
  • From: Matthew Wakeling
• Re: Really dumb planner decision
  • From: Grzegorz Jaśkiewicz
• Re: Really dumb planner decision
  • From: Grzegorz Jaśkiewicz
• Really dumb planner decision
  • From: Matthew Wakeling
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Grzegorz Jaśkiewicz
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Lists
• Re: error updating a very large table
  • From: Simon Riggs
• Re: error updating a very large table
  • From: Tom Lane
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Matthew Wakeling
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Matthew Wakeling
• need information
  • From: Peeyush
• Re: error updating a very large table
  • From: Grzegorz Jaśkiewicz
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Stephen Frost
• error updating a very large table
  • From: Brian Cox
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Tom Lane
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Craig Ringer
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Stephen Frost
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Matthew Wakeling
• Re: difficulties with time based queries
  • From: Nikolas Everett
• Re: INSERT times - same storage space but more fields -> much slower inserts
  • From: Stephen Frost
• Re: Nested query performance issue
  • From: Merlin Moncure
• Re: Nested query performance issue
  • From: Glenn Maynard
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Matthew Wakeling
• Re: Nested query performance issue
  • From: Matthew Wakeling
• Re: difficulties with time based queries
  • From: PFC
• INSERT times - same storage space but more fields -> much slower inserts
  • From: Craig Ringer
• Re: Postgres 8.x on Windows Server in production
  • From: Justin Pitts
• Re: Postgres 8.x on Windows Server in production
  • From: Grzegorz Jaśkiewicz
• Re: Postgres 8.x on Windows Server in production
  • From: Scott Marlowe
• Re: linux deadline i/o elevator tuning
  • From: Kevin Grittner
• Re: linux deadline i/o elevator tuning
  • From: Jeff
• Re: Postgres 8.x on Windows Server in production
  • From: Ognjen Blagojevic
• Re: 2.6.26 kernel and PostgreSQL
  • From: Glyn Astill
• Re: 2.6.26 kernel and PostgreSQL
  • From: Greg Smith
• Re: Postgres 8.x on Windows Server in production
  • From: Scott Marlowe
• Re: Postgres 8.x on Windows Server in production
  • From: Rainer Mager
• Re: Postgres 8.x on Windows Server in production
  • From: Scott Marlowe
• Re: Postgres 8.x on Windows Server in production
  • From: Rainer Mager
• Re: Using IOZone to simulate DB access patterns
  • From: Scott Carey
• Re: Using IOZone to simulate DB access patterns
  • From: Mark Wong
• Re: Using IOZone to simulate DB access patterns
  • From: M. Edward (Ed) Borasky
• Re: 2.6.26 kernel and PostgreSQL
  • From: Glyn Astill
• Re: Postgres 8.x on Windows Server in production
  • From: Grzegorz Jaśkiewicz
• Re: 2.6.26 kernel and PostgreSQL
  • From: Kevin Grittner
• 2.6.26 kernel and PostgreSQL
  • From: Glyn Astill
• Re: determining the locks that will be held by a query
  • From: Kevin Grittner
• Re: Using IOZone to simulate DB access patterns
  • From: Greg Smith
• determining the locks that will be held by a query
  • From: Brian Cox
• Re: Using IOZone to simulate DB access patterns
  • From: Scott Carey
• Re: Postgres 8.x on Windows Server in production
  • From: Josh Berkus
• Re: Using IOZone to simulate DB access patterns
  • From: Greg Smith
• Re: plpgsql arrays
  • From: Tom Lane
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Josh Berkus
• Re: Using IOZone to simulate DB access patterns
  • From: Scott Carey
• Re: Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Tom Lane
• Re: Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: Using IOZone to simulate DB access patterns
  • From: Scott Carey
• Re: Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Josh Berkus
• Re: Using IOZone to simulate DB access patterns
  • From: Joshua D. Drake
• Re: Shouldn't the planner have a higher cost for reverse index scans?
  • From: Tom Lane
• Re: Nested query performance issue
  • From: Tom Lane
• Postgres 8.x on Windows Server in production
  • From: Ognjen Blagojevic
• Re: linux deadline i/o elevator tuning
  • From: Albe Laurenz *EXTERN*
• Shouldn't the planner have a higher cost for reverse index scans?
  • From: Josh Berkus
• Re: Using IOZone to simulate DB access patterns
  • From: Mark Kirkwood
• Re: Nested query performance issue
  • From: Glenn Maynard
• Re: Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: difficulties with time based queries
  • From: Tom Lane
• Re: difficulties with time based queries
  • From: Rainer Mager
• Re: Nested query performance issue
  • From: Greg Smith
• Re: Nested query performance issue
  • From: Glenn Maynard
• Re: Nested query performance issue
  • From: Glenn Maynard
• Re: linux deadline i/o elevator tuning
  • From: Scott Carey
• Re: linux deadline i/o elevator tuning
  • From: Mark Wong
• Re: linux deadline i/o elevator tuning
  • From: Kevin Grittner
• Re: linux deadline i/o elevator tuning
  • From: Mark Wong
• Re: linux deadline i/o elevator tuning
  • From: Arjen van der Meijden
• Re: linux deadline i/o elevator tuning
  • From: Grzegorz Jaśkiewicz
• Re: linux deadline i/o elevator tuning
  • From: Matthew Wakeling
• Re: linux deadline i/o elevator tuning
  • From: Kevin Grittner
• Re: linux deadline i/o elevator tuning
  • From: Kevin Grittner
• Re: linux deadline i/o elevator tuning
  • From: Grzegorz Jaśkiewicz
• Re: linux deadline i/o elevator tuning
  • From: Matthew Wakeling
• Re: linux deadline i/o elevator tuning
  • From: Grzegorz Jaśkiewicz
• Re: linux deadline i/o elevator tuning
  • From: Kevin Grittner
• linux deadline i/o elevator tuning
  • From: Mark Wong
• Re: Best replication solution?
  • From: Jeff
• Re: Nested query performance issue
  • From: Heikki Linnakangas
• Re: Nested query performance issue
  • From: Віталій Тимчишин
• Re: difficulties with time based queries
  • From: Rainer Mager
• Re: Nested query performance issue
  • From: Glenn Maynard
• Re: Nested query performance issue
  • From: Віталій Тимчишин
• Nested query performance issue
  • From: Glenn Maynard
• Re: Best replication solution?
  • From: Dimitri Fontaine
• Re: Best replication solution?
  • From: Jeff
• Re: bad query plans for ~ "^string" (and like "string%") (8.3.6)
  • From: Tom Lane
• Re: bad query plans for ~ "^string" (and like "string%") (8.3.6)
  • From: Robert Haas
• Re: bad query plans for ~ "^string" (and like "string%") (8.3.6)
  • From: Marinos Yannikos
• bad query plans for ~ "^string" (and like "string%") (8.3.6)
  • From: Marinos Yannikos
• Re: Best replication solution?
  • From: Marinos Yannikos
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: Best replication solution?
  • From: Mark Kirkwood
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Bruce Momjian
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Merlin Moncure
• determining the locks that will be held by a query
  • From: Brian Cox
• Re: Best replication solution?
  • From: Andrew Sullivan
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: Best replication solution?
  • From: Andrew Sullivan
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: justin
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: justin
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: Best replication solution?
  • From: Mark Kirkwood
• Re: Best replication solution?
  • From: Ivan Voras
• Re: Best replication solution?
  • From: Dimitri Fontaine
• Re: Best replication solution?
  • From: Lists
• Re: Best replication solution?
  • From: Lists
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Scott Marlowe
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Mario Splivalo
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Scott Marlowe
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Mario Splivalo
• Re: plpgsql arrays
  • From: Robert Haas
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Scott Marlowe
• Re: probelm with alter table add constraint......
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: Best replication solution?
  • From: Andrew Sullivan
• Re: difficulties with time based queries
  • From: Matthew Wakeling
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Mario Splivalo
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: probelm with alter table add constraint......
  • From: Albe Laurenz
• Re: probelm with alter table add constraint......
  • From: Robert Haas
• Re: difficulties with time based queries
  • From: Robert Haas
• Re: Best replication solution?
  • From: Heikki Linnakangas
• probelm with alter table add constraint......
  • From: roopasatish
• Re: difficulties with time based queries
  • From: Rainer Mager
• Re: Best replication solution?
  • From: Greg Sabino Mullane
• Re: difficulties with time based queries
  • From: Tom Lane
• Re: difficulties with time based queries
  • From: Rainer Mager
• Re: difficulties with time based queries
  • From: Tom Lane
• Re: difficulties with time based queries
  • From: PFC
• Re: difficulties with time based queries
  • From: David Wilson
• difficulties with time based queries
  • From: Rainer Mager
• Re: Best replication solution?
  • From: Lists
• Best replication solution?
  • From: Lists
• Re: Question on pgbench output
  • From: Tom Lane
• Re: Question on pgbench output
  • From: David Kerr
• Re: Question on pgbench output
  • From: Tom Lane
• Re: Question on pgbench output
  • From: Simon Riggs
• Re: Question on pgbench output
  • From: David Kerr
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Greg Smith
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Josh Berkus
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Greg Smith
• Re: Using IOZone to simulate DB access patterns
  • From: henk de wit
• Re: Using IOZone to simulate DB access patterns
  • From: Jesper Krogh
• Re: Using IOZone to simulate DB access patterns
  • From: henk de wit
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Question on pgbench output
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: david
• Re: Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: Question on pgbench output
  • From: David Kerr
• Re: Question on pgbench output
  • From: David Kerr
• Using IOZone to simulate DB access patterns
  • From: Josh Berkus
• Re: Question on pgbench output
  • From: Tom Lane
• Re: Question on pgbench output
  • From: Tom Lane
• Re: Question on pgbench output
  • From: Greg Smith
• Re: Question on pgbench output
  • From: Scott Marlowe
• Re: Question on pgbench output
  • From: David Kerr
• Re: Question on pgbench output
  • From: Tom Lane
• Question on pgbench output
  • From: David Kerr
• Re: plpgsql arrays
  • From: Nathan Boley
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Alvaro Herrera
• Re: plpgsql arrays
  • From: Simon Riggs
• Re: Rewriting using rules for performance
  • From: Merlin Moncure
• Re: Rewriting using rules for performance
  • From: Merlin Moncure
• Re: plpgsql arrays
  • From: Merlin Moncure
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Merlin Moncure
• Re: plpgsql arrays
  • From: Merlin Moncure
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Tom Lane
• Re: plpgsql arrays
  • From: Matthew Wakeling
• Re: Rewriting using rules for performance
  • From: Matthew Wakeling
• Re: plpgsql arrays
  • From: Robert Haas
• Re: Rewriting using rules for performance
  • From: Robert Haas
• plpgsql arrays
  • From: Matthew Wakeling
• Rewriting using rules for performance
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Raid 10 chunksize
  • From: Hannes Dorbath
• Re: Raid 10 chunksize
  • From: Ron Mayer
• Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
  • From: Bruce Momjian
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: Raid 10 chunksize
  • From: Merlin Moncure
• Re: Raid 10 chunksize
  • From: Scott Carey
• Re: How to get parallel restore in PG 8.4 to work?
  • From: henk de wit
• Re: Raid 10 chunksize
  • From: James Mansion
• Re: Raid 10 chunksize
  • From: Merlin Moncure
• Re: Very specialised query
  • From: Craig Ringer
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• Re: Raid 10 chunksize
  • From: david
• 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: Scott Carey
• Re: self join revisited
  • From: Robert Haas
• Re: Raid 10 chunksize
  • From: david
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: Raid 10 chunksize
  • From: david
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: self join revisited
  • From: Rikard Pavelic
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• Re: Raid 10 chunksize
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: self join revisited
  • From: Tom Lane
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• Re: Raid 10 chunksize
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• Re: Raid 10 chunksize
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: self join revisited
  • From: Matthew Wakeling
• Re: Raid 10 chunksize
  • From: Scott Marlowe
• self join revisited
  • From: Rikard Pavelic
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: Raid 10 chunksize
  • From: Greg Smith
• Re: Raid 10 chunksize
  • From: Stef Telford
• Re: PostgreSQL
  • From: Robert Haas
• Re: How to get parallel restore in PG 8.4 to work?
  • From: Tom Lane
• Re: How to get parallel restore in PG 8.4 to work?
  • From: henk de wit
• PostgreSQL
  • From: Mahu Vasile
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Raid 10 chunksize
  • From: Mark Kirkwood
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Greg Smith
• Re: How to get parallel restore in PG 8.4 to work?
  • From: Tom Lane
• How to get parallel restore in PG 8.4 to work?
  • From: henk de wit
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Kevin Grittner
• Re: Very specialised query
  • From: Віталій Тимчишин
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: I have a fusion IO drive available for testing
  • From: Chris Browne
• Re: I have a fusion IO drive available for testing
  • From: Craig James
• Re: I have a fusion IO drive available for testing
  • From: Dave Cramer
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Trying to track down weird query stalls
  • From: Scott Carey
• Re: Trying to track down weird query stalls
  • From: Alvaro Herrera
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Alvaro Herrera
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Alvaro Herrera
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Alvaro Herrera
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Robert Haas
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Scott Marlowe
• Re: Trying to track down weird query stalls
  • From: Scott Marlowe
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Robert Haas
• Re: Trying to track down weird query stalls
  • From: dan
• Re: Trying to track down weird query stalls
  • From: Robert Haas
• Re: Very specialised query
  • From: Віталій Тимчишин
• Trying to track down weird query stalls
  • From: dan
• Re: Very specialised query
  • From: Marc Mamin
• Re: Very specialised query
  • From: Віталій Тимчишин
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Scott Marlowe
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Very specialised query
  • From: Matthew Wakeling
• Re: Very specialised query
  • From: Marc Mamin
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Mario Splivalo
• Re: Forcing seq_scan off for large table joined with tiny table yeilds improved performance
  • From: Tom Lane
• 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