Postgres Performance Date Index

• Thread Index

• Re: insert/update tps slow with indices on table > 1M rows
  • From: andrew klassen
• Re: insert/update tps slow with indices on table > 1M rows
  • From: PFC
• Re: query performance question
  • From: PFC
• insert/update tps slow with indices on table > 1M rows
  • From: andrew klassen
• Re: query performance question
  • From: tv
• Re: query performance question
  • From: Marcin Citowicki
• Re: query performance question
  • From: hubert depesz lubaczewski
• query performance question
  • From: Marcin Citowicki
• Re: getting estimated cost to agree with actual
  • From: Scott Marlowe
• Re: getting estimated cost to agree with actual
  • From: Gregory Stark
• Re: getting estimated cost to agree with actual
  • From: Scott Marlowe
• getting estimated cost to agree with actual
  • From: Justin
• Re: Outer joins and equivalence
  • From: Simon Riggs
• Re: Outer joins and equivalence
  • From: Simon Riggs
• Re: 2GB or not 2GB
  • From: Simon Riggs
• Re: 2GB or not 2GB
  • From: Gregory Stark
• Re: 2GB or not 2GB
  • From: Josh Berkus
• Re: Statistics issue
  • From: Tom Lane
• Re: 2GB or not 2GB
  • From: Simon Riggs
• Statistics issue
  • From: Vlad Arkhipov
• Re: ProcArrayLock (The Saga continues)
  • From: Gregory Stark
• ProcArrayLock (The Saga continues)
  • From: Jignesh K. Shah
• Re: 2GB or not 2GB
  • From: Magnus Hagander
• Re: Adding "LIMIT 1" kills performance.
  • From: Tom Lane
• Re: Adding "LIMIT 1" kills performance.
  • From: Chris Shoemaker
• OVERLAPS is slow
  • From: Chris Browne
• Re: Adding "LIMIT 1" kills performance.
  • From: Shane Ambler
• Adding "LIMIT 1" kills performance.
  • From: Chris Shoemaker
• Re: 2GB or not 2GB
  • From: Joshua D. Drake
• Re: IN() statement values order makes 2x performance hit
  • From: Alexey Kupershtokh
• Re: IN() statement values order makes 2x performance hit
  • From: Oleg Bartunov
• IN() statement values order makes 2x performance hit
  • From: Alexey Kupershtokh
• Re: 2GB or not 2GB
  • From: Jignesh K. Shah
• Re: 2GB or not 2GB
  • From: Jignesh K. Shah
• Re: 2GB or not 2GB
  • From: Greg Smith
• Re: 2GB or not 2GB
  • From: Gregory Stark
• Re: 2GB or not 2GB
  • From: Steve Crawford
• 2GB or not 2GB
  • From: Josh Berkus
• Re: Creating large database of MD5 hash values
  • From: Tom Lane
• Re: Creating large database of MD5 hash values
  • From: Bruce Momjian
• Re: GEQO Benchmark
  • From: Tarcizio Bini
• Re: GEQO Benchmark
  • From: Simon Riggs
• Re: GEQO Benchmark
  • From: Tarcizio Bini
• Re: GEQO Benchmark
  • From: Tom Lane
• GEQO Benchmark
  • From: tarcizioab
• Re: Outer joins and equivalence
  • From: Simon Riggs
• Re: Outer joins and equivalence
  • From: Matthew Wakeling
• Re: Outer joins and equivalence
  • From: Tom Lane
• Re: I/O on select count(*)
  • From: Simon Riggs
• Outer joins and equivalence
  • From: Simon Riggs
• Re: [GENERAL] select query takes 13 seconds to run with index
  • From: hubert depesz lubaczewski
• Re: [GENERAL] select query takes 13 seconds to run with index
  • From: mark
• Re: [GENERAL] select query takes 13 seconds to run with index
  • From: hubert depesz lubaczewski
• Re: [GENERAL] select query takes 13 seconds to run with index
  • From: PFC
• Re: [GENERAL] select query takes 13 seconds to run with index
  • From: mark
• Re: [GENERAL] select query takes 13 seconds to run with index
  • From: mark
• Re: RAID controllers for Postgresql on large setups
  • From: Marinos Yannikos
• Re: Symbolic Links to Tablespaces
  • From: Heikki Linnakangas
• Re: Symbolic Links to Tablespaces
  • From: Tino Wildenhain
• Re: Symbolic Links to Tablespaces
  • From: Heikki Linnakangas
• Re: Symbolic Links to Tablespaces
  • From: A. Kretschmer
• Re: Symbolic Links to Tablespaces
  • From: Campbell, Lance
• Re: I/O on select count(*)
  • From: Tom Lane
• Re: Symbolic Links to Tablespaces
  • From: Tom Lane
• Re: "Big O" notation for postgres?
  • From: H. Hall
• Symbolic Links to Tablespaces
  • From: Campbell, Lance
• Re: I/O on select count(*)
  • From: Heikki Linnakangas
• Re: Posible planner improvement?
  • From: ITAGAKI Takahiro
• Re: Quad Xeon or Quad Opteron?
  • From: Jeffrey Baker
• Re: I/O on select count(*)
  • From: Decibel!
• Re: I/O on select count(*)
  • From: Decibel!
• Re: Posible planner improvement?
  • From: Decibel!
• Re: shared_buffers performance
  • From: Decibel!
• Re: Creating large database of MD5 hash values
  • From: Decibel!
• Re: Quad Xeon or Quad Opteron?
  • From: Andrzej Zawadzki
• Re: Quad Xeon or Quad Opteron?
  • From: Andrzej Zawadzki
• Re: index performance on large tables with update and insert
  • From: Magnus Hagander
• IBM ServRAID-MR10M / LSI1078ROC advice
  • From: Kevin Grittner
• index performance on large tables with update and insert
  • From: Jessica Richard
• Re: Quad Xeon or Quad Opteron?
  • From: Reid Thompson
• Re: Quad Xeon or Quad Opteron?
  • From: Knight, Doug
• Re: Quad Xeon or Quad Opteron?
  • From: Adam Tauno Williams
• Re: Quad Xeon or Quad Opteron?
  • From: Craig Ringer
• Quad Xeon or Quad Opteron?
  • From: Andrzej Zawadzki
• join/from_collapse_limit and geqo_threshold default values
  • From: Vlad Arkhipov
• Re: I/O on select count(*)
  • From: Luke Lonergan
• Re: "Big O" notation for postgres?
  • From: Gregory Stark
• Re: Index creation time and distribution
  • From: Guillaume Smet
• Re: Index creation time and distribution
  • From: Tom Lane
• Re: Index creation time and distribution
  • From: Guillaume Smet
• Re: Index creation time and distribution
  • From: Scott Marlowe
• Re: Index creation time and distribution
  • From: Matthew Wakeling
• Re: Index creation time and distribution
  • From: Guillaume Smet
• Re: Index creation time and distribution
  • From: Tom Lane
• Index creation time and distribution
  • From: Guillaume Smet
• Re: Varchar pkey instead of integer
  • From: Robins Tharakan
• Re: "Big O" notation for postgres?
  • From: H. Hall
• Re: "append" takes a lot of time in a query
  • From: Scott Marlowe
• Re: Posible planner improvement?
  • From: Albert Cervera Areny
• Re: "Big O" notation for postgres?
  • From: PFC
• Re: Posible planner improvement?
  • From: PFC
• Re: "Big O" notation for postgres?
  • From: Richard Huxton
• Re: "Big O" notation for postgres?
  • From: Jonah H. Harris
• "Big O" notation for postgres?
  • From: H. Hall
• Re: Posible planner improvement?
  • From: Richard Huxton
• Re: Posible planner improvement?
  • From: Luke Lonergan
• Re: Posible planner improvement?
  • From: Albert Cervera Areny
• Re: Posible planner improvement?
  • From: Albert Cervera Areny
• Re: Posible planner improvement?
  • From: Mark Mielke
• Re: Posible planner improvement?
  • From: Albert Cervera Areny
• Re: Posible planner improvement?
  • From: Richard Huxton
• Re: "append" takes a lot of time in a query
  • From: Frank Dekervel
• Posible planner improvement?
  • From: Albert Cervera Areny
• Re: Varchar pkey instead of integer
  • From: J. Andrew Rogers
• Re: Varchar pkey instead of integer
  • From: Craig Ringer
• Re: Varchar pkey instead of integer
  • From: Shane Ambler
• Re: Varchar pkey instead of integer
  • From: Craig Ringer
• Re: Varchar pkey instead of integer
  • From: Joshua D. Drake
• Varchar pkey instead of integer
  • From: Robins Tharakan
• Re: improving performance for a delete
  • From: PFC
• Re: improving performance for a delete
  • From: kevin kempter
• improving performance for a delete
  • From: kevin kempter
• Re: slow update
  • From: Scott Marlowe
• Re: Author Wanted
  • From: Bill Moran
• Author Wanted
  • From: Markus Feilner
• Re: slow update
  • From: A. Kretschmer
• slow update
  • From: kevin kempter
• Re: I/O on select count(*)
  • From: PFC
• Re: I/O on select count(*)
  • From: Tom Lane
• Re: I/O on select count(*)
  • From: Greg Smith
• Re: I/O on select count(*)
  • From: Tom Lane
• Re: I/O on select count(*)
  • From: Bruce Momjian
• Re: I/O on select count(*)
  • From: Matthew Wakeling
• Re: Strange behavior: pgbench and new Linux kernels
  • From: Greg Smith
• Re: I/O on select count(*)
  • From: Greg Smith
• Re: I/O on select count(*)
  • From: Jeremy Harris
• Re: I/O on select count(*)
  • From: Tom Lane
• Re: Regexps - never completing join.
  • From: Scott Marlowe
• Re: Regexps - never completing join.
  • From: Rusty Conover
• Re: Please ignore ...
  • From: Alvaro Herrera
• Re: I/O on select count(*)
  • From: Alvaro Herrera
• Re: Regexps - never completing join.
  • From: Scott Marlowe
• Re: I/O on select count(*)
  • From: Alvaro Herrera
• Re: very slow left join
  • From: Craig Ringer
• Re: very slow left join
  • From: Ben
• Re: very slow left join
  • From: Scott Marlowe
• Re: I/O on select count(*)
  • From: Simon Riggs
• Re: very slow left join
  • From: Ben
• Re: very slow left join
  • From: Scott Marlowe
• Re: I/O on select count(*)
  • From: Greg Smith
• very slow left join
  • From: Ben
• Re: which ext3 fs type should I use for postgresql
  • From: Joshua D. Drake
• Re: which ext3 fs type should I use for postgresql
  • From: Scott Marlowe
• Re: which ext3 fs type should I use for postgresql
  • From: david
• Re: Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: kevin kempter
• Re: Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: Luke Lonergan
• Re: Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: Richard Huxton
• Re: Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: Richard Huxton
• Re: Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: kevin kempter
• Re: Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: Richard Huxton
• Re: Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: Simon Riggs
• Re: Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: kevin kempter
• Re: Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: kevin kempter
• Re: Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: Claus Guttesen
• Join runs for > 10 hours and then fills up >1.3TB of disk space
  • From: kevin kempter
• Re: I/O on select count(*)
  • From: Kevin Grittner
• Re: I/O on select count(*)
  • From: Gregory Stark
• Re: I/O on select count(*)
  • From: James Mansion
• Re: I/O on select count(*)
  • From: Robert Lor
• Re: Update performance degrades over time
  • From: Subbiah Stalin-XCGF84
• Re: I/O on select count(*)
  • From: Tom Lane
• Re: I/O on select count(*)
  • From: Robert Lor
• Re: Update performance degrades over time
  • From: Subbiah Stalin-XCGF84
• Re: I/O on select count(*)
  • From: Tom Lane
• Re: which ext3 fs type should I use for postgresql
  • From: Guillaume Cottenceau
• Re: I/O on select count(*)
  • From: Alvaro Herrera
• Re: I/O on select count(*)
  • From: Alvaro Herrera
• Re: which ext3 fs type should I use for postgresql
  • From: Joshua D. Drake
• Re: which ext3 fs type should I use for postgresql
  • From: Guillaume Cottenceau
• Re: which ext3 fs type should I use for postgresql
  • From: Matthew Wakeling
• Re: I/O on select count(*)
  • From: Matthew Wakeling
• Re: I/O on select count(*)
  • From: Heikki Linnakangas
• Re: I/O on select count(*)
  • From: Heikki Linnakangas
• Re: which ext3 fs type should I use for postgresql
  • From: Guillaume Cottenceau
• Re: which ext3 fs type should I use for postgresql
  • From: Craig James
• Re: I/O on select count(*)
  • From: Tom Lane
• Re: I/O on select count(*)
  • From: Alvaro Herrera
• Re: Update performance degrades over time
  • From: Jeffrey Baker
• Re: I/O on select count(*)
  • From: Ron Mayer
• Re: I/O on select count(*)
  • From: Matthew Wakeling
• Re: I/O on select count(*)
  • From: Jan de Visser
• Re: I/O on select count(*)
  • From: Matthew Wakeling
• Re: I/O on select count(*)
  • From: Heikki Linnakangas
• Re: I/O on select count(*)
  • From: Matthew Wakeling
• Re: which ext3 fs type should I use for postgresql
  • From: Matthew Wakeling
• Re: which ext3 fs type should I use for postgresql
  • From: david
• Re: which ext3 fs type should I use for postgresql
  • From: Matthew Wakeling
• which ext3 fs type should I use for postgresql
  • From: Philippe Amelant
• Re: I/O on select count(*)
  • From: Tom Lane
• Re: I/O on select count(*)
  • From: Tom Lane
• Re: I/O on select count(*)
  • From: Tino Wildenhain
• Re: I/O on select count(*)
  • From: Joshua D. Drake
• Re: I/O on select count(*)
  • From: Greg Smith
• Re: I/O on select count(*)
  • From: Luke Lonergan
• Re: I/O on select count(*)
  • From: Pavan Deolasee
• Re: I/O on select count(*)
  • From: Jan de Visser
• Re: I/O on select count(*)
  • From: Greg Smith
• Re: I/O on select count(*)
  • From: Alvaro Herrera
• Re: I/O on select count(*)
  • From: Greg Smith
• Update performance degrades over time
  • From: Subbiah Stalin-XCGF84
• poor row estimates with multi-column joins
  • From: Robert Treat
• Re: I/O on select count(*)
  • From: Kevin Grittner
• Re: I/O on select count(*)
  • From: Doug Eck
• Re: I/O on select count(*)
  • From: Merlin Moncure
• I/O on select count(*)
  • From: Doug Eck
• Re: Regexps - never completing join.
  • From: Rusty Conover
• Re: postgres overall performance seems to degrade when large SELECT are requested
  • From: PFC
• postgres overall performance seems to degrade when large SELECT are requested
  • From: Valentin Bogdanov
• Re: can I move sort to first outer join ?
  • From: PFC
• Re: Regexps - never completing join.
  • From: Rusty Conover
• Regexps - never completing join.
  • From: Rusty Conover
• Re: Problem with 11 M records table
  • From: Ramasubramanian G
• can I move sort to first outer join ?
  • From: fernando castano
• Re: RAID controllers for Postgresql on large setups
  • From: PFC
• Re: RAID controllers for Postgresql on large setups
  • From: James Mansion
• Re: Problem with 11 M records table
  • From: Scott Marlowe
• Re: Problem with 11 M records table
  • From: Craig James
• Re: Problem with 11 M records table
  • From: Craig James
• Re: Problem with 11 M records table
  • From: salman
• Re: Problem with 11 M records table
  • From: Bill Moran
• Problem with 11 M records table
  • From: idc danny
• Re: RAID controllers for Postgresql on large setups
  • From: Vivek Khera
• Re: RAID controllers for Postgresql on large setups
  • From: Vivek Khera
• Re: Installation Steps to migrate to Postgres 8.3.1
  • From: Scott Marlowe
• Re: Installation Steps to migrate to Postgres 8.3.1
  • From: Knight, Doug
• Re: RAID controllers for Postgresql on large setups
  • From: Merlin Moncure
• Re: RAID controllers for Postgresql on large setups
  • From: Francisco Reyes
• Re: RAID controllers for Postgresql on large setups
  • From: PFC
• Re: Installation Steps to migrate to Postgres 8.3.1
  • From: Scott Marlowe
• Re: RAID controllers for Postgresql on large setups
  • From: Scott Marlowe
• Re: Installation Steps to migrate to Postgres 8.3.1
  • From: Claus Guttesen
• Installation Steps to migrate to Postgres 8.3.1
  • From: Gauri Kanekar
• Re: RAID controllers for Postgresql on large setups
  • From: Greg Smith
• Re: RAID controllers for Postgresql on large setups
  • From: Joshua D. Drake
• Re: RAID controllers for Postgresql on large setups
  • From: Joshua D. Drake
• Re: RAID controllers for Postgresql on large setups
  • From: Chris Ruprecht
• Re: Partitioning: INSERT 0 0 but want INSERT 0 1
  • From: Nikolas Everett
• Re: RAID controllers for Postgresql on large setups
  • From: Francisco Reyes
• Re: RAID controllers for Postgresql on large setups
  • From: Joshua D. Drake
• RAID controllers for Postgresql on large setups
  • From: Francisco Reyes
• Re: Partitioning: INSERT 0 0 but want INSERT 0 1
  • From: Neil Peter Braggio
• Partitioning: INSERT 0 0 but want INSERT 0 1
  • From: Nikolas Everett
• Re: Re: Query Optimization with Kruskal’s Algorithm
  • From: Michael Glaesemann
• Re: Re: Re: Re: Query Optimization with Kruskal’s Algorithm
  • From: Tom Lane
• Re: Re: Re: Query Optimization with Kruskal’s Algorithm
  • From: Jonah H. Harris
• Re: Re: Re: Query Optimization with Kruskal’s Algorithm
  • From: Tom Lane
• Re: Re: Query Optimization with Kruskal’s Algorithm
  • From: Jonah H. Harris
• Re: Query Optimization with Kruskal’s Algorithm
  • From: Rauan Maemirov
• Re: plan difference between set-returning function with ROWS within IN() and a plain join
  • From: Merlin Moncure
• Re: "append" takes a lot of time in a query
  • From: Tom Lane
• "append" takes a lot of time in a query
  • From: Frank Dekervel
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Scott Marlowe
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Antoine Baudoux
• Re: Creating indexes
  • From: Rauan Maemirov
• Re: Creating indexes
  • From: PFC
• Re: Creating a foreign key
  • From: PFC
• Re: Creating indexes
  • From: Asche
• Re: Creating indexes
  • From: Alan Hodgson
• Creating indexes
  • From: Rauan Maemirov
• Re: Creating a foreign key
  • From: Campbell, Lance
• Re: Creating a foreign key
  • From: Shaun Thomas
• Re: Creating a foreign key
  • From: Joshua D. Drake
• Creating a foreign key
  • From: Campbell, Lance
• Re: [GENERAL] Ubuntu question
  • From: Justin
• Re: [GENERAL] Ubuntu question
  • From: Justin
• Re: Query Optimization with Kruskal’s Algorithm
  • From: Alexander Staubo
• Query Optimization with Kruskal’s Algorithm
  • From: Tarcizio Bini
• Re: Possible Redundancy/Performance Solution
  • From: Dennis Muhlestein
• Re: RAID 10 Benchmark with different I/O schedulers
  • From: Matthew Wakeling
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Matthew Wakeling
• Re: RAID 10 Benchmark with different I/O schedulers
  • From: Albe Laurenz *EXTERN*
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Antoine Baudoux
• Re: pgfouine - commit details?
  • From: Josh Cole
• Re: Possible Redundancy/Performance Solution
  • From: Greg Smith
• Re: Possible Redundancy/Performance Solution
  • From: Scott Marlowe
• Re: Seqscan problem
  • From: Vlad Arkhipov
• Re: pgfouine - commit details?
  • From: Guillaume Smet
• Re: Possible Redundancy/Performance Solution
  • From: Dennis Muhlestein
• pgfouine - commit details?
  • From: Josh Cole
• Re: RAID 10 Benchmark with different I/O schedulers
  • From: Craig James
• Re: Possible Redundancy/Performance Solution
  • From: Greg Smith
• Re: RAID 10 Benchmark with different I/O schedulers
  • From: Greg Smith
• Re: Possible Redundancy/Performance Solution
  • From: Dennis Muhlestein
• Re: RAID 10 Benchmark with different I/O schedulers
  • From: Craig James
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Shaun Thomas
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Shaun Thomas
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Heikki Linnakangas
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Heikki Linnakangas
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Tom Lane
• Re: need to speed up query
  • From: Justin
• Re: Possible Redundancy/Performance Solution
  • From: Greg Smith
• Re: What constitutes a complex query
  • From: Scott Marlowe
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Antoine Baudoux
• Re: What constitutes a complex query
  • From: Justin
• Re: need to speed up query
  • From: Justin
• Possible Redundancy/Performance Solution
  • From: Dennis Muhlestein
• Re: What constitutes a complex query
  • From: Richard Broersma
• Re: What constitutes a complex query
  • From: Steve Atkins
• Re: need to speed up query
  • From: Shaun Thomas
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Shaun Thomas
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Antoine Baudoux
• Re: What constitutes a complex query
  • From: Scott Marlowe
• Re: need to speed up query
  • From: PFC
• Re: What constitutes a complex query
  • From: Craig James
• What constitutes a complex query
  • From: Justin
• Re: multiple joins + Order by + LIMIT query performance issue
  • From: Guillaume Smet
• multiple joins + Order by + LIMIT query performance issue
  • From: Antoine Baudoux
• Re: plan difference between set-returning function with ROWS within IN() and a plain join
  • From: Frank van Vugt
• Re: Seqscan problem
  • From: Tom Lane
• Re: plan difference between set-returning function with ROWS within IN() and a plain join
  • From: Tom Lane
• Re: need to speed up query
  • From: Justin
• Re: RAID 10 Benchmark with different I/O schedulers (was: Performance increase with elevator=deadline)
  • From: Jeff
• Re: plan difference between set-returning function with ROWS within IN() and a plain join
  • From: Frank van Vugt
• Seqscan problem
  • From: Vlad Arkhipov
• Re: plan difference between set-returning function with ROWS within IN() and a plain join
  • From: PFC
• plan difference between set-returning function with ROWS within IN() and a plain join
  • From: Frank van Vugt
• Re: need to speed up query
  • From: PFC
• Re: need to speed up query
  • From: Justin
• Re: need to speed up query
  • From: Justin
• Re: need to speed up query
  • From: Gregory Williamson
• Re: RAID 10 Benchmark with different I/O schedulers (was: Performance increase with elevator=deadline)
  • From: Greg Smith
• Re: need to speed up query
  • From: Scott Marlowe
• Re: RAID 10 Benchmark with different I/O schedulers (was: Performance increase with elevator=deadline)
  • From: Scott Marlowe
• need to speed up query
  • From: Justin
• Re: Very slow INFORMATION_SCHEMA
  • From: Tom Lane
• RAID 10 Benchmark with different I/O schedulers (was: Performance increase with elevator=deadline)
  • From: Craig James
• Re: Backup causing poor performance - suggestions
  • From: Scott Marlowe
• Re: Backup causing poor performance - suggestions
  • From: Greg Smith
• Re: Backup causing poor performance - suggestions
  • From: Greg Smith
• Re: Backup causing poor performance - suggestions
  • From: Scott Marlowe
• Re: Backup causing poor performance - suggestions
  • From: Simon Riggs
• Re: Backup causing poor performance - suggestions
  • From: Scott Marlowe
• Re: Backup causing poor performance - suggestions
  • From: Craig James
• Re: Backup causing poor performance - suggestions
  • From: Scott Marlowe
• Re: Backup causing poor performance - suggestions
  • From: Campbell, Lance
• Re: Backup causing poor performance - suggestions
  • From: Scott Marlowe
• Backup causing poor performance - suggestions
  • From: Campbell, Lance
• Re: Very slow INFORMATION_SCHEMA
  • From: Mario Weilguni
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: Shane Ambler
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: Zoltan Boszormenyi
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: Hannes Dorbath
• Re: Fastest way / best practice to calculate "next birthdays"
  • From: Joshua D. Drake
• Fastest way / best practice to calculate "next birthdays"
  • From: Hannes Dorbath
• Re: pgPool query cache
  • From: Hannes Dorbath
• Re: Vacuum statistics
  • From: Mark Kirkwood
• Re: Vacuum statistics
  • From: Francisco Reyes
• Re: two memory-consuming postgres processes
  • From: Merlin Moncure
• Re: two memory-consuming postgres processes
  • From: Matthew Wakeling
• Re: two memory-consuming postgres processes
  • From: Alexy Khrabrov
• Re: two memory-consuming postgres processes
  • From: Kevin Grittner
• Re: Very slow INFORMATION_SCHEMA
  • From: Tom Lane
• Re: two memory-consuming postgres processes
  • From: Kevin Grittner
• Re: two memory-consuming postgres processes
  • From: Alexy Khrabrov
• Very slow INFORMATION_SCHEMA
  • From: Ernesto
• Re: two memory-consuming postgres processes
  • From: PFC
• Re: two memory-consuming postgres processes
  • From: Greg Smith
• Re: two memory-consuming postgres processes
  • From: Alexy Khrabrov
• Re: two memory-consuming postgres processes
  • From: Craig James
• Re: two memory-consuming postgres processes
  • From: Alexy Khrabrov
• Re: two memory-consuming postgres processes
  • From: Scott Marlowe
• Re: two memory-consuming postgres processes
  • From: Alexy Khrabrov
• Re: two memory-consuming postgres processes
  • From: Alexy Khrabrov
• Re: two memory-consuming postgres processes
  • From: Alexy Khrabrov
• Re: two memory-consuming postgres processes
  • From: Greg Smith
• Re: two memory-consuming postgres processes
  • From: Tom Lane
• Re: two memory-consuming postgres processes
  • From: Scott Marlowe
• Re: two memory-consuming postgres processes
  • From: Alexy Khrabrov
• Re: two memory-consuming postgres processes
  • From: Scott Marlowe
• two memory-consuming postgres processes
  • From: Alexy Khrabrov
• Re: Pros and Cons of 8.3.1
  • From: Kevin Grittner
• Re: Pros and Cons of 8.3.1
  • From: Kevin Grittner
• Re: Pros and Cons of 8.3.1
  • From: Kevin Grittner
• Re: Pros and Cons of 8.3.1
  • From: Joshua D. Drake
• Re: Pros and Cons of 8.3.1
  • From: Justin
• Re: Please ignore ...
  • From: Alvaro Herrera
• Re: Vacuum statistics
  • From: chirag . dave
• Re: Pros and Cons of 8.3.1
  • From: Claus Guttesen
• Pros and Cons of 8.3.1
  • From: Gauri Kanekar
• Re: Benchmarks WAS: Sun Talks about MySQL
  • From: Jignesh K. Shah
• Re: Please ignore ...
  • From: D'Arcy J.M. Cain
• Re: Postgres replication
  • From: Fujii Masao
• Re: Please ignore ...
  • From: Tino Wildenhain
• Re: Please ignore ...
  • From: Greg Smith
• Re: Please ignore ...
  • From: Justin
• Re: Please ignore ...
  • From: D'Arcy J.M. Cain
• Re: Understanding histograms
  • From: Tom Lane
• Please ignore ...
  • From: Marc G. Fournier
• Re: Max shared_buffers
  • From: Craig Ringer
• Re: Max shared_buffers
  • From: Scott Marlowe
• [Fwd: Re: Max shared_buffers]
  • From: Justin
• Re: Max shared_buffers
  • From: Matthew
• Re: Max shared_buffers
  • From: Andrej Ricnik-Bay
• Re: Max shared_buffers
  • From: Scott Marlowe
• Re: Performance Implications of Using Exceptions
  • From: Robins Tharakan
• Re: Max shared_buffers
  • From: sathiya psql
• Re: Performance Implications of Using Exceptions
  • From: chemuduguntar@xxxxxxxxx
• Re: POSIX file updates
  • From: James Mansion
• Max shared_buffers
  • From: bitaoxiao
• Re: SSDs
  • From: Merlin Moncure
• Re: POSIX file updates
  • From: Greg Smith
• Re: POSIX file updates
  • From: Greg Smith
• Re: POSIX file updates
  • From: James Mansion
• Re: POSIX file updates
  • From: Andreas Kostyrka
• Re: Performance Implications of Using Exceptions
  • From: James Mansion
• Re: POSIX file updates
  • From: James Mansion
• Re: Cursors and different settings for default_statistics_target
  • From: Hell, Robert
• Re: SSDs
  • From: Arjen van der Meijden
• SSDs
  • From: James Mansion
• Re: Cursors and different settings for default_statistics_target
  • From: Tom Lane
• Re: Cursors and different settings for default_statistics_target
  • From: Hell, Robert
• Too many commands in a transaction
  • From: samantha mahindrakar
• Re: Cursors and different settings for default_statistics_target
  • From: Steinar H. Gunderson
• Re: Cursors and different settings for default_statistics_target
  • From: Tom Lane
• Re: Cursors and different settings for default_statistics_target
  • From: Hell, Robert
• Re: Cursors and different settings for default_statistics_target
  • From: Tom Lane
• Re: Cursors and different settings for default_statistics_target
  • From: Hell, Robert
• Insert time
  • From: Ioana Danes
• Re: Cursors and different settings for default_statistics_target
  • From: Tom Lane
• Re: check performance parameters
  • From: Matthew
• Cursors and different settings for default_statistics_target
  • From: Hell, Robert
• check performance parameters
  • From: Sabin Coanda
• Re: Bad prepare performance
  • From: Cédric Villemain
• Re: POSIX file updates
  • From: Tom Lane
• Re: Performance Implications of Using Exceptions
  • From: Tom Lane
• Re: Performance Implications of Using Exceptions
  • From: Robins Tharakan
• Re: Performance Implications of Using Exceptions
  • From: Ravi Chemudugunta
• Re: Performance Implications of Using Exceptions
  • From: Stephen Denne
• Re: Performance Implications of Using Exceptions
  • From: Stephen Frost
• Performance Implications of Using Exceptions
  • From: Ravi Chemudugunta
• Re: POSIX file updates
  • From: Greg Smith
• Re: POSIX file updates
  • From: James Mansion
• Re: POSIX file updates
  • From: James Mansion
• Re: POSIX file updates
  • From: James Mansion
• Re: POSIX file updates
  • From: Mark Mielke
• POSIX file updates
  • From: James Mansion
• optimizing query performance
  • From: Frits Hoogland
• Re: Bad prepare performance
  • From: Cédric Villemain
• Bad prepare performance
  • From: Martin Kjeldsen
• Re: Planning a new server - help needed
  • From: Guy Rouillier
• Re: Planning a new server - help needed
  • From: Craig Ringer
• Re: Planning a new server - help needed
  • From: Greg Smith
• Re: Planning a new server - help needed
  • From: Peter Eisentraut
• Re: Planning a new server - help needed
  • From: James Mansion
• Re: Planning a new server - help needed
  • From: PFC
• Re: Planning a new server - help needed
  • From: James Mansion
• Re: Planning a new server - help needed
  • From: Weinzierl Stefan
• Re: Planning a new server - help needed
  • From: Dan Harris
• Re: Planning a new server - help needed
  • From: Greg Smith
• Re: using like in a prepare doesnt' use the right index
  • From: Gavin Sherry
• Re: Planning a new server - help needed
  • From: Laszlo Nagy
• Re: Planning a new server - help needed
  • From: Reko Turja
• Re: Planning a new server - help needed
  • From: Claus Guttesen
• Planning a new server - help needed
  • From: Laszlo Nagy
• Re: vacuum in Postgresql 8.0.x slowing down the database
  • From: Vinubalaji Gopal
• using like in a prepare doesnt' use the right index
  • From: Dave Cramer
• Re: "Slow" query or just "Bad hardware"?
  • From: Alvaro Herrera
• Re: "Slow" query or just "Bad hardware"?
  • From: Luke Lonergan
• Re: postgresql is slow with larger table even it is in RAM
  • From: Luke Lonergan
• Re: "Slow" query or just "Bad hardware"?
  • From: Bill Moran
• Re: "Slow" query or just "Bad hardware"?
  • From: PFC
• Re: "Slow" query or just "Bad hardware"?
  • From: PFC
• Re: "Slow" query or just "Bad hardware"?
  • From: Matthew
• "Slow" query or just "Bad hardware"?
  • From: Jesper Krogh
• Re: how can a couple of expensive queries drag my system down?
  • From: Erik Jones
• Re: how can a couple of expensive queries drag my system down?
  • From: Scott Marlowe
• Re: how can a couple of expensive queries drag my system down?
  • From: Shane Ambler
• Re: postgresql is slow with larger table even it is in RAM
  • From: Peter Koczan
• Re: how can a couple of expensive queries drag my system down?
  • From: PFC
• Re: how can a couple of expensive queries drag my system down?
  • From: Scott Marlowe
• Re: how can a couple of expensive queries drag my system down?
  • From: Alan Hodgson
• Re: vacuum in Postgresql 8.0.x slowing down the database
  • From: Joshua D. Drake
• vacuum in Postgresql 8.0.x slowing down the database
  • From: Vinubalaji Gopal
• how can a couple of expensive queries drag my system down?
  • From: p prince
• Query Optimization
  • From: Gopinath Narasimhan
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: PFC
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: Craig Ringer
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: A. Kretschmer
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: Marinos Yannikos
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: Matthew
• Re: 1-/2-dimensional indexes for common columns, rationale?
  • From: A. Kretschmer
• 1-/2-dimensional indexes for common columns, rationale?
  • From: Marinos Yannikos
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Matthew
• Preparing statements on connection startup
  • From: PFC
• Re: postgresql is slow with larger table even it is in RAM
  • From: Chris Browne
• Re: postgresql is slow with larger table even it is in RAM
  • From: sathiya psql
• Re: postgresql is slow with larger table even it is in RAM
  • From: Luke Lonergan
• Re: postgresql is slow with larger table even it is in RAM
  • From: Bill Moran
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Bill Moran
• Re: PostgreSQL NetApp and NFS
  • From: Jurgen Haan
• Re: postgresql is slow with larger table even it is in RAM
  • From: sathiya psql
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Ivan Voras
• Re: postgresql is slow with larger table even it is in RAM
  • From: Bill Moran
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Craig Ringer
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: sathiya psql
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Craig Ringer
• Re: increasing shared buffer slow downs query performance.
  • From: Pavan Deolasee
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: sathiya psql
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Alvaro Herrera
• Re: postgresql is slow with larger table even it is in RAM
  • From: Alvaro Herrera
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: sathiya psql
• Re: what is the maximum number of rows in a table in postgresql 8.1
  • From: Harald Armin Massa
• what is the maximum number of rows in a table in postgresql 8.1
  • From: sathiya psql
• Re: postgresql is slow with larger table even it is in RAM
  • From: Craig Ringer
• Re: postgresql is slow with larger table even it is in RAM
  • From: hubert depesz lubaczewski
• Re: postgresql is slow with larger table even it is in RAM
  • From: sathiya psql
• postgresql is slow with larger table even it is in RAM
  • From: sathiya psql
• Re: Planning hot/live backups?
  • From: Matthew T. O'Connor
• Re: slow pg_connect()
  • From: Chris
• Re: waiting for harddisk
  • From: Scott Marlowe
• Re: Planning hot/live backups?
  • From: Miguel Arroz
• Re: Planning hot/live backups?
  • From: Steve Poe
• Re: Planning hot/live backups?
  • From: Matthew T. O'Connor
• Re: Planning hot/live backups?
  • From: Tom Lane
• Re: Planning hot/live backups?
  • From: paul rivers
• Re: Planning hot/live backups?
  • From: Matthew T. O'Connor
• Re: Planning hot/live backups?
  • From: Campbell, Lance
• Planning hot/live backups?
  • From: Steve Poe
• Re: Turn correlated in subquery into join
  • From: Tom Lane
• Re: waiting for harddisk
  • From: PFC
• waiting for harddisk
  • From: petchimuthu lingam
• Re: slow pg_connect()
  • From: Thomas Pundt
• Re: slow pg_connect()
  • From: Tommy Gildseth
• Re: increasing shared buffer slow downs query performance.
  • From: Andreas Kretschmer
• increasing shared buffer slow downs query performance.
  • From: petchimuthu lingam
• Re: slow pg_connect()
  • From: vincent
• Re: slow pg_connect()
  • From: Craig Ringer
• Re: slow pg_connect()
  • From: Craig Ringer
• Turn correlated in subquery into join
  • From: Dennis Bjorklund
• slow pg_connect()
  • From: firerox
• Re: Views and functions returning sets of records
  • From: Tom Lane
• Re: Views and functions returning sets of records
  • From: Giorgio Valoti
• Re: Views and functions returning sets of records
  • From: Andreas Kretschmer
• Re: Views and functions returning sets of records
  • From: Tom Lane
• Re: Views and functions returning sets of records
  • From: Andreas Kretschmer
• Views and functions returning sets of records
  • From: Giorgio Valoti
• Re: Having MANY MANY empty columns in database
  • From: sathiya psql
• Re: Having MANY MANY empty columns in database
  • From: Craig Ringer
• Having MANY MANY empty columns in database
  • From: sathiya psql
• Re: Linux/PostgreSQL scalability issue - problem with 8 cores
  • From: Bruce Momjian
• Re: PostgreSQL NetApp and NFS
  • From: Bruce Momjian
• Re: PG writes a lot to the disk
  • From: Bill Moran
• Re: PG writes a lot to the disk
  • From: Laurent Raufaste
• Re: PG writes a lot to the disk
  • From: Gregory Stark
• Re: PostgreSQL NetApp and NFS
  • From: Gregory Stark
• Re: PG writes a lot to the disk
  • From: Laurent Raufaste
• Re: PostgreSQL NetApp and NFS
  • From: Dawid Kuroczko
• Re: PostgreSQL NetApp and NFS
  • From: Tom Lane
• Re: PostgreSQL NetApp and NFS
  • From: Bruce Momjian
• Re: PostgreSQL NetApp and NFS
  • From: Woody Woodring
• Re: PostgreSQL NetApp and NFS
  • From: Tom Lane
• Re: PostgreSQL NetApp and NFS
  • From: Frits Hoogland
• Re: PostgreSQL NetApp and NFS
  • From: Bruce Momjian
• Re: PG writes a lot to the disk
  • From: Kris Jurka
• PostgreSQL NetApp and NFS
  • From: Chris Hoover
• Re: PG writes a lot to the disk
  • From: Tom Lane
• Re: PG writes a lot to the disk
  • From: Bill Moran
• Re: PG writes a lot to the disk
  • From: Albe Laurenz
• Re: PG writes a lot to the disk
  • From: Laurent Raufaste
• Re: Anyone using a SAN?
  • From: Peter Koczan
• Windows XP 64 bit
  • From: Campbell, Lance
• Re: PG writes a lot to the disk
  • From: Albe Laurenz
• Re: PG writes a lot to the disk
  • From: Greg Smith
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Bill Moran
• Re: PG writes a lot to the disk
  • From: Bill Moran
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Mark Steben
• Re: What is the best way to storage music files in Postgresql
  • From: Gregory Youngblood
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Alvaro Herrera
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Bill Moran
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Mark Steben
• PG writes a lot to the disk
  • From: Laurent Raufaste
• Re: What is the best way to storage music files in Postgresql
  • From: Gregory Youngblood
• Re: question on TRUNCATE vs VACUUM FULL
  • From: Chris
• Re: TB-sized databases
  • From: Ron Mayer
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: What is the best way to storage music files in Postgresql
  • From: Gregory Stark
• Re: Planner mis-estimation using nested loops followup
  • From: KC ESL
• Re: What is the best way to storage music files in Postgresql
  • From: david
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: Planner mis-estimation using nested loops followup
  • From: Stephen Denne
• question on TRUNCATE vs VACUUM FULL
  • From: Mark Steben
• Re: What is the best way to storage music files in Postgresql
  • From: Gregory Stark
• Re: What is the best way to storage music files in Postgresql
  • From: david
• Re: Planner mis-estimation using nested loops followup
  • From: Scott Marlowe
• Re: What is the best way to storage music files in Postgresql
  • From: david
• Re: What is the best way to storage music files in Postgresql
  • From: Andrej Ricnik-Bay
• Re: TB-sized databases
  • From: Ron Mayer
• Re: Planner mis-estimation using nested loops followup
  • From: Matthew
• Re: Planner mis-estimation using nested loops followup
  • From: Chris Kratz
• Re: Planner mis-estimation using nested loops followup
  • From: Joshua D. Drake
• Planner mis-estimation using nested loops followup
  • From: Chris Kratz
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Michael Stone
• Re: TB-sized databases
  • From: Tom Lane
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: What is the best way to storage music files in Postgresql
  • From: Andrej Ricnik-Bay
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: James Mansion
• Re: TB-sized databases
  • From: Ron Mayer
• Re: What is the best way to storage music files in Postgresql
  • From: Peter Koczan
• Re: performance tools
  • From: Franck Routier
• Re: TB-sized databases
  • From: Pablo Alcaraz
• Re: TB-sized databases
  • From: Bruce Momjian
• Re: TB-sized databases
  • From: Tom Lane
• Re: TB-sized databases
  • From: Bruce Momjian
• Re: performance tools
  • From: Andrej Ricnik-Bay
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Scott Marlowe
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Enrico Sirola
• Re: What is the best way to storage music files in Postgresql
  • From: Rich
• Re: What is the best way to storage music files in Postgresql
  • From: Rich
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Craig James
• Re: What is the best way to storage music files in Postgresql
  • From: Peter Koczan
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Dave Cramer
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: performance tools
  • From: Ben Chobot
• Re: performance tools
  • From: sathiya psql
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: performance tools
  • From: Mark Steben
• performance tools
  • From: sathiya psql
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Tino Wildenhain
• Re: Lots of "semop" calls under load
  • From: Albe Laurenz
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Craig Ringer
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Andrej Ricnik-Bay
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Scott Marlowe
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Dave Cramer
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Craig James
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Craig James
• Re: best way to run maintenance script
  • From: Peter Eisentraut
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Dave Cramer
• Re: What is the best way to storage music files in Postgresql
  • From: Craig Ringer
• Re: What is the best way to storage music files in Postgresql
  • From: Craig James
• What is the best way to storage music files in Postgresql
  • From: Rich
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Justin
• Re: best way to run maintenance script
  • From: Gregory Stark
• Re: best way to run maintenance script
  • From: Vinubalaji Gopal
• Re: best way to run maintenance script
  • From: Vinubalaji Gopal
• Re: best way to run maintenance script
  • From: Joshua D. Drake
• Re: best way to run maintenance script
  • From: Tom Lane
• Re: best way to run maintenance script
  • From: Vinubalaji Gopal
• Re: best way to run maintenance script
  • From: Joshua D. Drake
• best way to run maintenance script
  • From: Vinubalaji Gopal
• Re: Adaptec 5805 SAS Raid
  • From: Leigh Dyer
• Re: Anyone using a SAN?
  • From: Peter Koczan
• Re: The "many nulls" problem
  • From: Oleg Bartunov
• Re: The "many nulls" problem
  • From: Kynn Jones
• Re: The "many nulls" problem
  • From: Kynn Jones
• Re: The "many nulls" problem
  • From: Heikki Linnakangas
• Re: Hardware question for a DB server
  • From: Scott Marlowe
• Re: Hardware question for a DB server
  • From: Pascal Cohen
• Re: The "many nulls" problem
  • From: Oleg Bartunov
• The "many nulls" problem
  • From: Kynn Jones
• Adaptec 5805 SAS Raid
  • From: Glyn Astill
• Re: Lots of "semop" calls under load
  • From: Tom Lane
• Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • From: Michael Stone