Postgres Performance Date Index

• Thread Index

• Re: Dell Hardware Recommendations
  • From: Decibel!
• Dell Hardware Recommendations
  • From: Joe Uhl
• Re: Update table performance
  • From: Decibel!
• Re: mid 2007 "best bang for the buck" hardware opinions
  • From: Vivek Khera
• Re: When/if to Reindex
  • From: Steven Flatt
• Re: Update table performance
  • From: Trevor Talbot
• Re: Update table performance
  • From: Michael Stone
• Re: When/if to Reindex
  • From: Bill Moran
• Re: Update table performance
  • From: Merlin Moncure
• Re: mid 2007 "best bang for the buck" hardware opinions
  • From: justin
• Re: mid 2007 "best bang for the buck" hardware opinions
  • From: Scott Marlowe
• mid 2007 "best bang for the buck" hardware opinions
  • From: justin
• Re: When/if to Reindex
  • From: Tom Lane
• Re: How to ENABLE SQL capturing???
  • From: Bryan Murphy
• Re: When/if to Reindex
  • From: Decibel!
• Re: How to ENABLE SQL capturing???
  • From: Steinar H. Gunderson
• How to ENABLE SQL capturing???
  • From: smiley2211
• Re: When/if to Reindex
  • From: Bill Moran
• Re: When/if to Reindex
  • From: Steven Flatt
• Re: When/if to Reindex
  • From: Vivek Khera
• Re: Update table performance
  • From: Decibel!
• Re: Update table performance
  • From: Erik Jones
• Re: Update table performance
  • From: Heikki Linnakangas
• Re: Update table performance
  • From: Erik Jones
• Re: Update table performance
  • From: Mark Makarowsky
• Re: Update table performance
  • From: Decibel!
• Re: Update table performance
  • From: Scott Marlowe
• Re: Update table performance
  • From: Chris Browne
• Re: Update table performance
  • From: Decibel!
• Re: Update table performance
  • From: Alan Hodgson
• Re: Update table performance
  • From: Scott Marlowe
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Scott Marlowe
• Re: Update table performance
  • From: Richard Huxton
• Update table performance
  • From: Mark Makarowsky
• Re: [GENERAL] Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Tom Lane
• Re: [GENERAL] Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Henrik Zagerholm
• Re: Extreme slow select query 8.2.4
  • From: Henrik Zagerholm
• Re: Extreme slow select query 8.2.4
  • From: Heikki Linnakangas
• Re: TRUNCATE TABLE
  • From: Tom Lane
• Re: Default Performance between 8.0 and 8.1
  • From: Ted Jordan
• Re: Extreme slow select query 8.2.4
  • From: Henrik Zagerholm
• Re: [GENERAL] Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Tom Lane
• Re: Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Gregory Stark
• Re: Extreme slow select query 8.2.4
  • From: Tom Lane
• Re: Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Henrik Zagerholm
• Re: Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Gregory Stark
• Planner making wrong decisions 8.2.4. Insane cost calculations.
  • From: Henrik Zagerholm
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Sven Clement
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Heikki Linnakangas
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Ragnar
• Extreme slow select query 8.2.4
  • From: Henrik Zagerholm
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Sven Clement
• Re: TRUNCATE TABLE
  • From: Decibel!
• Re: Default Performance between 8.0 and 8.1
  • From: Merlin Moncure
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Heikki Linnakangas
• Re: TRUNCATE TABLE
  • From: Adriaan van Os
• Default Performance between 8.0 and 8.1
  • From: Ted Jordan
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Sven Clement
• RES: RES: RES: Improving select peformance
  • From: Carlos H. Reimer
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Tom Lane
• Re: cpu throttling
  • From: Decibel!
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Andrew Kroeger
• Re: CLOG Patch
  • From: Simon Riggs
• CLOG Patch
  • From: Jignesh K. Shah
• Re: Postgres optimizer
  • From: Mark Lewis
• Postgres optimizer
  • From: Mouhamadou Dia
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Josh Berkus
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Sven Clement
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Dan Langille
• Re: Performance problems with large telemetric datasets on 7.4.2
  • From: Mark Lewis
• Performance problems with large telemetric datasets on 7.4.2
  • From: Sven Clement
• Re: RES: RES: Improving select peformance
  • From: Tom Lane
• RES: RES: Improving select peformance
  • From: Carlos H. Reimer
• Re: Why are distinct and group by choosing different plans?
  • From: Tom Lane
• Re: Why are distinct and group by choosing different plans?
  • From: Gregory Stark
• Why are distinct and group by choosing different plans?
  • From: Ron Mayer
• Re: cpu throttling
  • From: Bryan Murphy
• Re: cpu throttling
  • From: Alan Hodgson
• cpu throttling
  • From: Bryan Murphy
• RES: RES: Improving select peformance
  • From: Carlos H. Reimer
• Re: Postgres configuration for 64 CPUs, 128 GB RAM...
  • From: Luke Lonergan
• Re: select on 1milion register = 6s
  • From: Jan Dittmer
• Re: RES: Improving select peformance
  • From: Alvaro Herrera
• RES: Improving select peformance
  • From: Carlos H. Reimer
• Re: TRUNCATE TABLE
  • From: Alvaro Herrera
• Re: TRUNCATE TABLE
  • From: Kevin Grittner
• Re: TRUNCATE TABLE
  • From: Adriaan van Os
• Re: Using EXECUTE in a function
  • From: Merlin Moncure
• Re: Postgres configuration for 64 CPUs, 128 GB RAM...
  • From: Dimitri
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: User concurrency thresholding: where do I look?
  • From: Josh Berkus
• Re: Semantics of PostgreSQL Server Log Stats
  • From: Bruce Momjian
• Re: deadlock detected when calling function (Callfunction_name)
  • From: Sachchida Ojha
• Re: disk filling up
  • From: Merlin Moncure
• Re: deadlock detected when calling function (Call function_name)
  • From: Alvaro Herrera
• Re: deadlock detected when calling function (Call function_name)
  • From: Sachchida Ojha
• Semantics of PostgreSQL Server Log Stats
  • From: Camilo Porto
• Using EXECUTE in a function
  • From: Andreas Tille
• Seq scan on join table despite index and high statistics
  • From: Henrik Zagerholm
• Re: Vacuum looping?
  • From: Decibel!
• Re: disk filling up
  • From: Tom Lane
• Query optimization....
  • From: Karl Denninger
• Re: Postgres configuration for 64 CPUs, 128 GB RAM...
  • From: Luke Lonergan
• Re: Postgres configuration for 64 CPUs, 128 GB RAM...
  • From: Dimitri
• Re: multicolumn index column order
  • From: Lew
• Re: Questions on Tags table schema
  • From: Ron Mayer
• Re: Slow query with backwards index scan
  • From: Nis Jørgensen
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: Slow query with backwards index scan
  • From: Tilmann Singer
• Re: Slow query with backwards index scan
  • From: Nis Jørgensen
• Re: Vacuum looping?
  • From: Steven Flatt
• Re: Questions on Tags table schema
  • From: Richard Huxton
• Re: Questions on Tags table schema
  • From: Richard Huxton
• Re: Questions on Tags table schema
  • From: Jay Kang
• Re: Questions on Tags table schema
  • From: Richard Huxton
• Re: Questions on Tags table schema
  • From: Richard Huxton
• Re: Questions on Tags table schema
  • From: Jay Kang
• Re: Questions on Tags table schema
  • From: Richard Huxton
• Re: RES: RES: select on 1milion register = 6s
  • From: Decibel!
• Re: RES: RES: select on 1milion register = 6s
  • From: Decibel!
• Re: select on 1milion register = 6s
  • From: Alvaro Herrera
• RES: RES: select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• Re: RES: select on 1milion register = 6s
  • From: Decibel!
• Questions on Tags table schema
  • From: Jay Kang
• Re: select on 1milion register = 6s
  • From: Scott Marlowe
• RES: select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• RES: select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• RES: RES: select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• Re: RES: select on 1milion register = 6s
  • From: Ragnar
• Re: Slow query with backwards index scan
  • From: Tilmann Singer
• Re: Slow query with backwards index scan
  • From: andrew
• RES: select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• Re: Slow query with backwards index scan
  • From: Jeremy Harris
• Re: Slow query with backwards index scan
  • From: Craig James
• Re: select on 1milion register = 6s
  • From: Hervé Piedvache
• Re: select on 1milion register = 6s
  • From: Craig James
• select on 1milion register = 6s
  • From: Bruno Rodrigues Siqueira
• Re: Slow query with backwards index scan
  • From: Tilmann Singer
• Re: Slow query with backwards index scan
  • From: andrew
• Re: Vacuum looping?
  • From: Jim C. Nasby
• Re: Vacuum looping?
  • From: Tom Lane
• Re: Slow query with backwards index scan
  • From: Tilmann Singer
• Vacuum looping?
  • From: Steven Flatt
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: Slow query with backwards index scan
  • From: Nis Jørgensen
• Re: How to use a trigger to write rows to a remote server
  • From: Merlin Moncure
• Slow query with backwards index scan
  • From: Tilmann Singer
• Re: disk filling up
  • From: Merlin Moncure
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: User concurrency thresholding: where do I look?
  • From: Simon Riggs
• Re: User concurrency thresholding: where do I look?
  • From: Simon Riggs
• Re: User concurrency thresholding: where do I look?
  • From: Alvaro Herrera
• Re: disk filling up
  • From: Yudhvir Singh Sidhu
• Re: disk filling up
  • From: Mark Kirkwood
• Re: update, truncate and vacuum
  • From: Dave Dutcher
• Re: Affect of Reindexing on Vacuum Times
  • From: Jim Nasby
• Re: update, truncate and vacuum
  • From: Luke Lonergan
• update, truncate and vacuum
  • From: Scott Feldstein
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: User concurrency thresholding: where do I look?
  • From: Simon Riggs
• Re: User concurrency thresholding: where do I look?
  • From: Robert Lor
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: performance of postgresql in replication using slony
  • From: Chris Browne
• Re: performance of postgresql in replication using slony
  • From: Jeff Davis
• Re: User concurrency thresholding: where do I look?
  • From: Simon Riggs
• Re: User concurrency thresholding: where do I look?
  • From: Tom Lane
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: User concurrency thresholding: where do I look?
  • From: Simon Riggs
• Re: disk filling up
  • From: Joshua D. Drake
• Re: User concurrency thresholding: where do I look?
  • From: Tom Lane
• Re: disk filling up
  • From: Mark Lewis
• Re: User concurrency thresholding: where do I look?
  • From: Jignesh K. Shah
• Re: disk filling up
  • From: Bill Moran
• disk filling up
  • From: Brandon Shalton
• performance of postgresql in replication using slony
  • From: angga erwina
• [no subject]
  • From: Unknown
• Delete Cascade FK speed issue
  • From: Patric de Waha
• Re: Join with lower/upper limits doesn't scale well
  • From: Gregory Stark
• Join with lower/upper limits doesn't scale well
  • From: Craig James
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Greg Smith
• Re: slow query
  • From: Nis Jørgensen
• slow query
  • From: Vidhya Bondre
• [PERFORMANCE] is it possible to force an index to be held in memory?
  • From: valgog
• Re:
  • From: Ed Tyrrill
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Tom Lane
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Tom Lane
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Tom Lane
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Craig James
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Alvaro Herrera
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Richard Huxton
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Ho Fat Tsang
• Re: How to install Postgresql 8.2.x on windows XP silently
  • From: Magnus Hagander
• How to install Postgresql 8.2.x on windows XP silently
  • From: Sachchida Ojha
• Re: rtree/gist index taking enormous amount of space in 8.2.3
  • From: Tom Lane
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Kevin Grittner
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Gregory Stark
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Greg Smith
• Re: High IOWAIT times, low iops? Need Help with configuration
  • From: Greg Smith
• Re: High IOWAIT times, low iops? Need Help with configuration
  • From: Evan Reiser
• Re: update query taking too long
  • From: Richard Huxton
• Re: update query taking too long
  • From: Heikki Linnakangas
• Re: update query taking too long
  • From: Jean-David Beyer
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Richard Huxton
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Ho Fat Tsang
• Re: update query taking too long
  • From: Chris
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Richard Huxton
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Ho Fat Tsang
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Richard Huxton
• Re: PostgreSQL 8.0 occasionally slow down
  • From: Andreas Kostyrka
• Re: High IOWAIT times, low iops? Need Help with configuration
  • From: Richard Huxton
• Re: update query taking too long
  • From: Richard Huxton
• PostgreSQL 8.0 occasionally slow down
  • From: Ho Fat Tsang
• Re: update query taking too long
  • From: Chris
• Re: update query taking too long
  • From: Richard Huxton
• Re: update query taking too long
  • From: Chris
• Re: update query taking too long
  • From: A. Kretschmer
• Re: update query taking too long
  • From: Chris
• Re: update query taking too long
  • From: Chris
• Re: update query taking too long
  • From: Tom Lane
• Re: update query taking too long
  • From: A. Kretschmer
• update query taking too long
  • From: Chris
• High IOWAIT times, low iops? Need Help with configuration
  • From: Evan Reiser
• Re: Volunteer to build a configuration tool
  • From: Josh Berkus
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Josh Berkus
• rtree/gist index taking enormous amount of space in 8.2.3
  • From: Dolafi, Tom
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Greg Smith
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Josh Berkus
• Re: Database-wide VACUUM ANALYZE
  • From: Alvaro Herrera
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Greg Smith
• Re: Database-wide VACUUM ANALYZE
  • From: Steven Flatt
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Josh Berkus
• Re: Volunteer to build a configuration tool
  • From: Gregory Stark
• Re: Volunteer to build a configuration tool
  • From: Jim Nasby
• Re: Database-wide VACUUM ANALYZE
  • From: Jim Nasby
• Re:
  • From: Tom Lane
• Re:
  • From: Stephen Frost
• Re:
  • From: Ed Tyrrill
• Re:
  • From: Stephen Frost
• Re:
  • From: Ed Tyrrill
• Re: startup caching suggestions
  • From: Bryan Murphy
• Re: startup caching suggestions
  • From: Oleg Bartunov
• Re:
  • From: Tom Lane
• Re:
  • From: Stephen Frost
• Non-optimal query plan with 8.2
  • From: Tyrrill, Ed
• [no subject]
  • From: Tyrrill, Ed
• startup caching suggestions
  • From: Bryan Murphy
• Re: PITR Backups
  • From: Tom Lane
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Tom Lane
• Re: PITR Backups
  • From: Gregory Stark
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Simon Riggs
• Re: PITR Backups
  • From: Tom Lane
• Re: PITR Backups
  • From: Simon Riggs
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Gregory Stark
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Gregory Stark
• Re: PITR Backups
  • From: Tom Lane
• Re: Slow indexscan
  • From: Tom Lane
• Re: PITR Backups
  • From: Simon Riggs
• Re: Performance query about large tables, lots of concurrent access
  • From: Jean-David Beyer
• Re: PostgreSQL Configuration Tool for Dummies - feedback adjustable control
  • From: Sabin Coanda
• Re: Performance query about large tables, lots of concurrent access
  • From: Michael Stone
• Re: PITR Backups
  • From: Koichi Suzuki
• Is AIX Concurrent IO safe with PostgreSQL?
  • From: Dawid Kuroczko
• Re: Slow indexscan
  • From: Mikko Partio
• Re: PREPARE and stuff
  • From: PFC
• Re: PREPARE and stuff
  • From: Gregory Stark
• Re: PREPARE and stuff
  • From: Andreas Kostyrka
• Re: PREPARE and stuff
  • From: Heikki Linnakangas
• PREPARE and stuff
  • From: PFC
• Re: PostgreSQL Configuration Tool for Dummies - feedback adjustable control
  • From: Greg Smith
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Greg Smith
• Re: Volunteer to build a configuration tool
  • From: Greg Smith
• Re: Slow join query
  • From: Scott Marlowe
• Re: Slow join query
  • From: Tom Tamulewicz
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Slow join query
  • From: Michael Glaesemann
• Re: Slow join query
  • From: Tom Tamulewicz
• Re: Slow join query
  • From: Michael Glaesemann
• Re: PostgreSQL Configuration Tool for Dummies - feedback adjustable control
  • From: david
• Slow join query
  • From: Tom Tamulewicz
• Re: PITR Backups
  • From: Tom Lane
• Re: PITR Backups
  • From: Simon Riggs
• Re: PITR Backups
  • From: Tom Lane
• Re: Data transfer very slow when connected via DSL
  • From: Dimitri
• Re: PITR Backups
  • From: Gregory Stark
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Data transfer very slow when connected via DSL
  • From: Joshua D. Drake
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Database-wide VACUUM ANALYZE
  • From: Alvaro Herrera
• Re: PITR Backups
  • From: Joshua D. Drake
• Re: PITR Backups
  • From: Joshua D. Drake
• Re: PostgreSQL Configuration Tool for Dummies - feedback adjustable control
  • From: Sabin Coanda
• Re: Data transfer very slow when connected via DSL
  • From: Harald Armin Massa
• Re: Data transfer very slow when connected via DSL
  • From: Dimitri
• Re: Hardware suggestions
  • From: Francisco Reyes
• Re: PITR Backups
  • From: Simon Riggs
• Re: PITR Backups
  • From: Andreas Kostyrka
• Re: PITR Backups
  • From: Kurt Overberg
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Adam Tauno Williams
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Simon Riggs
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Simon Riggs
• Re: Data transfer very slow when connected via DSL
  • From: PFC
• Re: Data transfer very slow when connected via DSL
  • From: Harald Armin Massa
• Re: Data transfer very slow when connected via DSL
  • From: Dave Page
• Re: Data transfer very slow when connected via DSL
  • From: Dave Page
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Data transfer very slow when connected via DSL
  • From: Dimitri
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: PITR Backups
  • From: Toru SHIMOGAKI
• Re: Data transfer very slow when connected via DSL
  • From: Dimitri
• Re: PITR Backups
  • From: Dan Gorman
• Re: PITR Backups
  • From: Toru SHIMOGAKI
• Re: PITR Backups
  • From: Toru SHIMOGAKI
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Greg Smith
• Re: Hardware suggestions
  • From: Greg Smith
• Re: PITR Backups
  • From: Steve Atkins
• Re: PITR Backups
  • From: Joshua D. Drake
• Re: PITR Backups
  • From: Toru SHIMOGAKI
• Re: Data transfer very slow when connected via DSL
  • From: Tom Lane
• Re: PITR Backups
  • From: Tom Lane
• PITR Backups
  • From: Dan Gorman
• Re: Performance query about large tables, lots of concurrent access
  • From: Joshua D. Drake
• Re: Data transfer very slow when connected via DSL
  • From: Scott Marlowe
• Re: Performance query about large tables, lots of concurrent access
  • From: Scott Marlowe
• Re: Performance query about large tables, lots of concurrent access
  • From: Scott Marlowe
• Re: Data transfer very slow when connected via DSL
  • From: Dimitri
• Re: Hardware suggestions
  • From: Scott Marlowe
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Data transfer very slow when connected via DSL
  • From: Dimitri
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Very long SQL strings
  • From: Tom Lane
• Re: Database-wide VACUUM ANALYZE
  • From: Steven Flatt
• Re: Very long SQL strings
  • From: Steven Flatt
• Re: Database-wide VACUUM ANALYZE
  • From: Bill Moran
• Re: Very long SQL strings
  • From: Chris Browne
• Re: Database-wide VACUUM ANALYZE
  • From: Larry Rosenman
• Re: Database-wide VACUUM ANALYZE
  • From: Steven Flatt
• Re: Database-wide VACUUM ANALYZE
  • From: Francisco Reyes
• Re: Very long SQL strings
  • From: Andreas Kretschmer
• Re: Very long SQL strings
  • From: Tom Lane
• Re: Very long SQL strings
  • From: Heikki Linnakangas
• Re: Database-wide VACUUM ANALYZE
  • From: Heikki Linnakangas
• Very long SQL strings
  • From: Steven Flatt
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: vacuum a lot of data when insert only
  • From: Andrew Sullivan
• Re: Performance query about large tables, lots of concurrent access
  • From: Andrew Sullivan
• Database-wide VACUUM ANALYZE
  • From: Steven Flatt
• vacuum a lot of data when insert only
  • From: Sabin Coanda
• Re: Volunteer to build a configuration tool
  • From: Campbell, Lance
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Volunteer to build a configuration tool
  • From: Andrew Sullivan
• Re: Performance query about large tables, lots of concurrent access
  • From: Scott Marlowe
• Re: Data transfer very slow when connected via DSL
  • From: Tom Lane
• Re: Replication
  • From: Markus Schiltknecht
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Scott Marlowe
• Re: Volunteer to build a configuration tool
  • From: Dave Page
• Re: Data transfer very slow when connected via DSL
  • From: Harald Armin Massa
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Ben Trewern
• Re: Volunteer to build a configuration tool
  • From: Tom Lane
• Data transfer very slow when connected via DSL
  • From: Rainer Bauer
• Re: Hardware suggestions
  • From: Francisco Reyes
• Re: Volunteer to build a configuration tool
  • From: Greg Smith
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Stefan Kaltenbrunner
• Re: Maintenance question / DB size anomaly...
  • From: Kurt Overberg
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Performance query about large tables, lots of concurrent access
  • From: Scott Marlowe
• Re: Hardware suggestions
  • From: Scott Marlowe
• Re: [GENERAL] [ADMIN] Postgres VS Oracle
  • From: Scott Marlowe
• Re: any way to get rid of Bitmap Heap Scan recheck?
  • From: Scott Marlowe
• Re: Performance query about large tables, lots of concurrent access
  • From: Andrew Sullivan
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Maintenance question / DB size anomaly...
  • From: Tom Lane
• Re: Volunteer to build a configuration tool
  • From: Greg Smith
• Re: Maintenance question / DB size anomaly...
  • From: Kurt Overberg
• Re: Performance query about large tables, lots of concurrent access
  • From: Shaun Thomas
• Re: Slow indexscan
  • From: Tom Lane
• Re: Maintenance question / DB size anomaly...
  • From: Tom Lane
• Re: Performance query about large tables, lots of concurrent access
  • From: Michael Stone
• Re: Performance query about large tables, lots of concurrent access
  • From: Andrew Sullivan
• Re: Performance query about large tables, lots of concurrent access
  • From: Joshua D. Drake
• Re: Maintenance question / DB size anomaly...
  • From: Kurt Overberg
• Re: Performance query about large tables, lots of concurrent access
  • From: Michael Stone
• Re: Performance query about large tables, lots of concurrent access
  • From: Alvaro Herrera
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Performance query about large tables, lots of concurrent access
  • From: Alvaro Herrera
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Slow indexscan
  • From: Oleg Bartunov
• Re: Performance query about large tables, lots of concurrent access
  • From: Francisco Reyes
• Re: Performance query about large tables, lots of concurrent access
  • From: Alvaro Herrera
• Re: Performance query about large tables, lots of concurrent access
  • From: Heikki Linnakangas
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Volunteer to build a configuration tool
  • From: Mark Lewis
• Re: Volunteer to build a configuration tool
  • From: Heikki Linnakangas
• Re: Slow indexscan
  • From: Michael Glaesemann
• Re: Slow indexscan
  • From: Mikko Partio
• Re: Volunteer to build a configuration tool
  • From: Campbell, Lance
• Re: Slow indexscan
  • From: Tom Lane
• Re: Slow indexscan
  • From: Joshua D. Drake
• Re: Slow indexscan
  • From: Mikko Partio
• Re: [PG 8.1.0 / AIX 5.3] Vacuum processes freezing
  • From: RESTOUX, Loïc
• Re: Maintenance question / DB size anomaly...
  • From: Tom Lane
• Re: Volunteer to build a configuration tool
  • From: Greg Smith
• Re: Slow indexscan
  • From: Tom Lane
• Re: Replication
  • From: Andrew Sullivan
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Kevin Hunter
• Slow indexscan
  • From: Mikko Partio
• Re: Maintenance question / DB size anomaly...
  • From: Andreas Kostyrka
• Re: Maintenance question / DB size anomaly...
  • From: Bill Moran
• Re: Maintenance question / DB size anomaly...
  • From: Kurt Overberg
• Re: cached entities
  • From: Bill Moran
• cached entities
  • From: Sergey Konoplev
• Re: Short row header
  • From: Gregory Stark
• Re: Short row header
  • From: Heikki Linnakangas
• Short row header
  • From: PFC
• Re: Volunteer to build a configuration tool
  • From: PFC
• Re: Volunteer to build a configuration tool
  • From: Tom Lane
• Re: Volunteer to build a configuration tool
  • From: Greg Smith
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Greg Smith
• Re: Volunteer to build a configuration tool
  • From: Tom Lane
• Re: Volunteer to build a configuration tool
  • From: Greg Smith
• Re: Maintenance question / DB size anomaly...
  • From: Tom Lane
• Re: Maintenance question / DB size anomaly...
  • From: Kurt Overberg
• Re: Volunteer to build a configuration tool
  • From: Mike Benoit
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Francisco Reyes
• Re: Maintenance question / DB size anomaly...
  • From: Bill Moran
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Charles Sprickman
• Re: Maintenance question / DB size anomaly...
  • From: Tom Lane
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Josh Berkus
• Re: Maintenance question / DB size anomaly...
  • From: Kurt Overberg
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Tom Lane
• Re: Maintenance question / DB size anomaly...
  • From: Tom Lane
• Re: Replication
  • From: Jeff Davis
• Re: [ADMIN] Postgres VS Oracle
  • From: Simon Riggs
• PostgreSQL Configuration Tool for Dummies
  • From: Campbell, Lance
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Ray Stell
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Josh Berkus
• Re: Best use of second controller with faster disks?
  • From: Francisco Reyes
• Re: PostgreSQL Configuration Tool for Dummies
  • From: david
• Re: PostgreSQL Configuration Tool for Dummies
  • From: david
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Francisco Reyes
• Re: Performance query about large tables, lots of concurrent access
  • From: Francisco Reyes
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Y Sidhu
• PostgreSQL Configuration Tool for Dummies
  • From: Campbell, Lance
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Campbell, Lance
• Re: PostgreSQL Configuration Tool for Dummies
  • From: D'Arcy J.M. Cain
• Re: Performance query about large tables, lots of concurrent access
  • From: Heikki Linnakangas
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Campbell, Lance
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Y Sidhu
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Francisco Reyes
• Re: Maintenance question / DB size anomaly...
  • From: Kurt Overberg
• Re: PostgreSQL Configuration Tool for Dummies
  • From: PFC
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Richard Huxton
• Re: Maintenance question / DB size anomaly...
  • From: Richard Huxton
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Campbell, Lance
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Francisco Reyes
• Re: PostgreSQL Configuration Tool for Dummies
  • From: Richard Huxton
• Re: Maintenance question / DB size anomaly...
  • From: Kurt Overberg
• PostgreSQL Configuration Tool for Dummies
  • From: Campbell, Lance
• Re: Regarding Timezone
  • From: Tom Lane
• Re: Performance query about large tables, lots of concurrent access
  • From: Gregory Stark
• Re: Maintenance question / DB size anomaly...
  • From: Tom Lane
• Re: Performance query about large tables, lots of concurrent access
  • From: Alvaro Herrera
• Re: Performance query about large tables, lots of concurrent access
  • From: Francisco Reyes
• Re: Performance query about large tables, lots of concurrent access
  • From: Tom Lane
• Re: Performance query about large tables, lots of concurrent access
  • From: Gregory Stark
• Re: Performance query about large tables, lots of concurrent access
  • From: Francisco Reyes
• Re: Performance query about large tables, lots of concurrent access
  • From: Francisco Reyes
• Re: Hardware suggestions
  • From: Francisco Reyes
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Maintenance question / DB size anomaly...
  • From: Chris Browne
• Re: Performance query about large tables, lots of concurrent access
  • From: Tom Lane
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Performance query about large tables, lots of concurrent access
  • From: Tom Lane
• Re: Performance query about large tables, lots of concurrent access
  • From: Kurt Overberg
• Re: Performance query about large tables, lots of concurrent access
  • From: Gregory Stark
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Performance query about large tables, lots of concurrent access
  • From: Bill Moran
• Re: Maintenance question / DB size anomaly...
  • From: Richard Huxton
• Re: Maintenance question / DB size anomaly...
  • From: Tom Lane
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Maintenance question / DB size anomaly...
  • From: Kurt Overberg
• Re: Performance query about large tables, lots of concurrent access
  • From: Mark Lewis
• Re: Performance query about large tables, lots of concurrent access
  • From: Alvaro Herrera
• Re: Performance query about large tables, lots of concurrent access
  • From: Gregory Stark
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Performance query about large tables, lots of concurrent access
  • From: Alvaro Herrera
• Re: [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Jim Nasby
• Re: Volunteer to build a configuration tool
  • From: Ray Stell
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: dbt2 NOTPM numbers
  • From: Jim Nasby
• Re: Hardware suggestions
  • From: Claus Guttesen
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Hardware suggestions
  • From: christian . braun
• Re: Regarding Timezone
  • From: A. Kretschmer
• Re: Regarding Timezone
  • From: Heikki Linnakangas
• Regarding Timezone
  • From: soni de
• Re: Performance query about large tables, lots of concurrent access
  • From: PFC
• Re: Performance query about large tables, lots of concurrent access
  • From: Tom Lane
• Re: Volunteer to build a configuration tool
  • From: Greg Smith
• Re: Volunteer to build a configuration tool
  • From: Steve Atkins
• Re: Volunteer to build a configuration tool
  • From: david
• Re: Volunteer to build a configuration tool
  • From: Greg Smith
• Re: Parsing VACUUM VERBOSE
  • From: Guillaume Smet
• Re: Parsing VACUUM VERBOSE
  • From: Guillaume Smet
• Re: Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Performance query about large tables, lots of concurrent access
  • From: Karl Wright
• Re: Volunteer to build a configuration tool
  • From: James Neethling
• Re: Replication
  • From: Markus Schiltknecht
• Re: [GENERAL] [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Andrew Sullivan
• Re: [GENERAL] [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Andrew Sullivan
• Re: [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Andreas Kostyrka
• Re: Replication
  • From: Craig James
• Re: [GENERAL] [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Jonah H. Harris
• Re: [DOCS] Volunteer to build a configuration tool
  • From: Y Sidhu
• Re: [GENERAL] [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Andrew Sullivan
• Re: Parsing VACUUM VERBOSE
  • From: Y Sidhu
• Re: [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Andreas Kostyrka
• Re: [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Jonah H. Harris
• Re: [GENERAL] [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Andreas Kostyrka
• Re: [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Joshua D. Drake
• Re: [ADMIN] Postgres VS Oracle
  • From: Andreas Kostyrka
• Re: Replication
  • From: Markus Schiltknecht
• Re: [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Jonah H. Harris
• Re: [GENERAL] [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Joshua D. Drake
• Re: [DOCS] Volunteer to build a configuration tool
  • From: Campbell, Lance
• Re: [GENERAL] [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: PFC
• Re: [pgsql-advocacy] [ADMIN] Postgres VS Oracle
  • From: Joshua D. Drake
• Re: [ADMIN] Postgres VS Oracle
  • From: Jonah H. Harris
• Re: [ADMIN] Postgres VS Oracle
  • From: Andreas Kostyrka
• Re: [ADMIN] Postgres VS Oracle
  • From: Jonah H. Harris
• Volunteer to build a configuration tool
  • From: Campbell, Lance
• Re: Parsing VACUUM VERBOSE
  • From: Sabin Coanda
• Re: Database size
  • From: J6M
• Re: determining maxsize for character varying
  • From: Tom Lane
• Re: determining maxsize for character varying
  • From: Ragnar
• Re: determining maxsize for character varying
  • From: okparanoid
• Re: determining maxsize for character varying
  • From: Andreas Kretschmer
• determining maxsize for character varying
  • From: okparanoid
• Re: Variable (degrading) perfomance
  • From: Merlin Moncure
• Re: Replication
  • From: Gábriel Ákos
• Re: Database size
  • From: Francisco Reyes
• Re: Replication
  • From: Devrim GÜNDÜZ
• Re: Replication
  • From: Merlin Moncure
• Re: Replication
  • From: Alexander Staubo
• Re: Replication
  • From: Andreas Kostyrka
• Re: Database size
  • From: A. Kretschmer
• Re: Replication
  • From: Eugene Ogurtsov
• Re: Replication
  • From: Joshua D. Drake
• Re: Replication
  • From: Craig James
• Re: Replication
  • From: Andreas Kostyrka
• Re: Replication
  • From: Craig James
• Re: Replication
  • From: Kevin Grittner
• Re: Replication
  • From: Alexander Staubo
• Re: Replication
  • From: Ben
• Re: Replication
  • From: Joshua D. Drake
• Replication
  • From: Craig James
• Replication
  • From: Craig A. James
• Re: Parsing VACUUM VERBOSE
  • From: Y Sidhu
• Re: Parsing VACUUM VERBOSE
  • From: Guillaume Smet
• Re: Parsing VACUUM VERBOSE
  • From: Y Sidhu
• Re: Parsing VACUUM VERBOSE
  • From: Sabin Coanda
• Re: [PG 8.1.0 / AIX 5.3] Vacuum processes freezing
  • From: Simon Riggs
• Re: Parsing VACUUM VERBOSE
  • From: Dimitri Fontaine
• Re: Parsing VACUUM VERBOSE
  • From: Guillaume Smet
• Re: Best use of second controller with faster disks?
  • From: Vivek Khera
• Parsing VACUUM VERBOSE
  • From: Sabin Coanda
• Re: Best use of second controller with faster disks?
  • From: Francisco Reyes
• Re: Update table performance problem
  • From: Mark Makarowsky
• Re: Performance Testing Utility
  • From: Vivek Khera
• Re: Update table performance problem
  • From: Tom Lane
• Re: [PG 8.1.0 / AIX 5.3] Vacuum processes freezing
  • From: Tom Lane
• Update table performance problem
  • From: Mark Makarowsky
• Re: dbt2 NOTPM numbers
  • From: Mark Wong
• [PG 8.1.0 / AIX 5.3] Vacuum processes freezing
  • From: RESTOUX, Loïc
• Re: dbt2 NOTPM numbers
  • From: Markus Schiltknecht
• Re: dbt2 NOTPM numbers
  • From: Mark Wong
• Re: WAL shipping and ever expanding pg_xlog
  • From: Michael Dengler
• Re: WAL shipping and ever expanding pg_xlog
  • From: Merlin Moncure
• Re: VACUUM vs auto-vacuum daemon
  • From: Joshua D. Drake
• Re: VACUUM vs auto-vacuum daemon
  • From: Bill Moran
• Re: Best use of second controller with faster disks?
  • From: Vivek Khera
• Re: WAL shipping and ever expanding pg_xlog
  • From: Michael Dengler
• WAL shipping and ever expanding pg_xlog
  • From: Michael Dengler
• Re: Optimize slow query
  • From: Cédric Villemain
• Re: Optimize slow query
  • From: Tyler Durden
• Optimize slow query
  • From: Tyler Durden
• Re: Performance Testing Utility
  • From: Tobias Brox
• Re: Performance Testing Utility
  • From: Heikki Linnakangas
• Performance Testing Utility
  • From: Christo Du Preez
• Re: Best use of second controller with faster disks?
  • From: Francisco Reyes
• Re: test / live environment, major performance difference
  • From: Tom Lane
• Re: performance drop on 8.2.4, reverting to 8.1.4
  • From: Steven Flatt
• Re: Best use of second controller with faster disks?
  • From: Vivek Khera
• Re: Variable (degrading) performance
  • From: Heikki Linnakangas
• Re: test / live environment, major performance difference
  • From: Christo Du Preez
• Re: test / live environment, major performance difference
  • From: Tom Lane
• Re: test / live environment, major performance difference
  • From: Christo Du Preez
• Re: VACUUM vs auto-vacuum daemon
  • From: Sabin Coanda
• Re: VACUUM vs auto-vacuum daemon
  • From: Bill Moran
• Re: test / live environment, major performance difference
  • From: Tom Lane
• Re: VACUUM vs auto-vacuum daemon
  • From: Alvaro Herrera
• Re: Best way to delete unreferenced rows?
  • From: Tyrrill, Ed
• VACUUM vs auto-vacuum daemon
  • From: Sabin Coanda
• Re: Variable (degrading) performance
  • From: Vladimir Stankovic
• Re: test / live environment, major performance difference
  • From: Steinar H. Gunderson
• Re: How much memory PostgreSQL is going to use?
  • From: Bill Moran
• Re: test / live environment, major performance difference
  • From: Steinar H. Gunderson
• Re: test / live environment, major performance difference
  • From: Dave Dutcher
• How much memory PostgreSQL is going to use?
  • From: Arnau
• Re: test / live environment, major performance difference
  • From: Alvaro Herrera
• Re: test / live environment, major performance difference
  • From: Christo Du Preez
• Re: test / live environment, major performance difference
  • From: Gregory Stark
• Re: test / live environment, major performance difference
  • From: Michael Glaesemann
• Re: test / live environment, major performance difference
  • From: Reid Thompson
• Re: test / live environment, major performance difference
  • From: Christo Du Preez
• Re: test / live environment, major performance difference
  • From: Christo Du Preez
• Re: test / live environment, major performance difference
  • From: Christo Du Preez
• Best use of second controller with faster disks?
  • From: Francisco Reyes
• Re: Best way to delete unreferenced rows?
  • From: Ed Tyrrill
• Re: test / live environment, major performance difference
  • From: Craig James
• Re: How much ram is too much
  • From: Dave Cramer
• Re: Variable (degrading) performance
  • From: Heikki Linnakangas
• Re: How much ram is too much
  • From: Dave Cramer
• Variable (degrading) performance
  • From: Vladimir Stankovic
• Re: test / live environment, major performance difference
  • From: Dave Dutcher
• Re: test / live environment, major performance difference
  • From: Ansgar -59cobalt- Wiechers
• Re: dbt2 NOTPM numbers
  • From: Markus Schiltknecht
• Re: Best way to delete unreferenced rows?
  • From: Craig James
• test / live environment, major performance difference
  • From: Christo Du Preez
• Re: dbt2 NOTPM numbers
  • From: Heikki Linnakangas
• Re: How much ram is too much
  • From: Andrew Sullivan
• Re: dbt2 NOTPM numbers
  • From: Markus Schiltknecht
• Re: How much ram is too much
  • From: Dave Cramer
• Re: Vacuum takes forever
  • From: Jim Nasby
• Re: How much ram is too much
  • From: Jim Nasby
• Re: dbt2 NOTPM numbers
  • From: Jim Nasby
• Re: pg_statistic doesnt contain details for specific table
  • From: Michael Fuhr
• Variable (degrading) perfomance
  • From: Vladimir Stankovic
• Re: pg_statistic doesnt contain details for specific table
  • From: Nimesh Satam
• Re: pg_statistic doesnt contain details for specific table
  • From: Michael Fuhr
• Re: How much ram is too much
  • From: Dave Cramer
• Re: pg_statistic doesnt contain details for specific table
  • From: Nimesh Satam
• Re: pg_statistic doesnt contain details for specific table
  • From: Heikki Linnakangas
• pg_statistic doesnt contain details for specific table
  • From: Nimesh Satam
• Re: [OT] Re: How much ram is too much
  • From: Andreas Kostyrka
• Re: How much ram is too much
  • From: Guy Rouillier
• Re: [OT] Re: How much ram is too much
  • From: Zoltan Boszormenyi
• Re: [OT] Re: How much ram is too much
  • From: mark
• Re: [OT] Re: How much ram is too much
  • From: Zoltan Boszormenyi
• Re: [OT] Re: How much ram is too much
  • From: Dave Cramer