• Text Size: Normal / Large
• Donate
• Contact

Section Navigation

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

pgsql-performance 2007-05 Chronological Index (1/4)

• Thread Index
• [Prev Page]
• [Next Page]

• 31 May 2007
  • Re: setting up raid10 with more than 4 drives Sander Steffann
  • Re: setting up raid10 with more than 4 drives Steinar H. Gunderson
  • Re: max_fsm_pages, shared_buffers and checkpoint_segments Vivek Khera
  • Re: Some info to share: db_STRESS Benchmark results Dimitri
  • Re: Some info to share: db_STRESS Benchmark results Alexander Staubo
  • Some info to share: db_STRESS Benchmark results Dimitri
  • Re: DB cluster sharing between 32 and 64 bit software versions Bill Moran
  • DB cluster sharing between 32 and 64 bit software versions Ireneusz Pluta
  • Re: Bad RAID1 read performance Albert Cervera Areny
  • Re: Append table Hanu Kurubar
  • Re: setting up raid10 with more than 4 drives Rajesh Kumar Mallah
• 30 May 2007
  • Re: Database connection for Tbl_B established Y Sidhu
  • Re: Database connection for Tbl_B established Tom Lane
  • Database connection for Tbl_B established Y Sidhu
  • Re: setting up raid10 with more than 4 drives mark
  • Re: setting up raid10 with more than 4 drives Luke Lonergan
  • Re: Bad RAID1 read performance Luke Lonergan
  • Re: setting up raid10 with more than 4 drives Rajesh Kumar Mallah
  • Re: Bad RAID1 read performance Dimitri
  • Re: Very slow left outer join Tom Lane
  • Re: Very slow left outer join Tyrrill, Ed
  • Re: Very slow left outer join Tyrrill, Ed
  • Re: setting up raid10 with more than 4 drives mark
  • Re: setting up raid10 with more than 4 drives Luke Lonergan
  • Re: setting up raid10 with more than 4 drives PFC
  • Re: setting up raid10 with more than 4 drives PFC
  • Re: setting up raid10 with more than 4 drives Gregory Stark
  • Re: setting up raid10 with more than 4 drives Luke Lonergan
  • Re: setting up raid10 with more than 4 drives Michael Stone
  • Re: Bad RAID1 read performance Albert Cervera Areny
  • Re: setting up raid10 with more than 4 drives Luke Lonergan
  • Re: setting up raid10 with more than 4 drives Michael Stone
  • Re: Vacuum takes forever Andrew Sullivan
  • Re: Bad RAID1 read performance Luke Lonergan
  • Re: setting up raid10 with more than 4 drives Luke Lonergan
  • Re: setting up raid10 with more than 4 drives Gregory Stark
  • Re: setting up raid10 with more than 4 drives Stephen Frost
  • Bad RAID1 read performance Albert Cervera Areny
  • Re: Vacuum takes forever Dave Page
  • Re: setting up raid10 with more than 4 drives Peter Childs
  • Re: setting up raid10 with more than 4 drives david
  • Re: setting up raid10 with more than 4 drives Jonah H. Harris
  • Re: Vacuum takes forever Joost Kraaijeveld
  • Re: setting up raid10 with more than 4 drives Luke Lonergan
  • Re: setting up raid10 with more than 4 drives Stephen Frost
  • Re: setting up raid10 with more than 4 drives Luke Lonergan
  • Re: Very slow left outer join Tom Lane
  • Re: setting up raid10 with more than 4 drives Rajesh Kumar Mallah
  • Re: Very slow left outer join Klint Gore
  • Re: Very slow left outer join Michael Glaesemann
  • Re: How PostgreSQL handles multiple DDBB instances? Craig James
  • Very slow left outer join Tyrrill, Ed
• 29 May 2007
  • Re: How PostgreSQL handles multiple DDBB instances? Jeff Davis
  • Re: setting up raid10 with more than 4 drives Luke Lonergan
  • setting up raid10 with more than 4 drives Rajesh Kumar Mallah
  • Re: Vacuum takes forever Joshua D. Drake
  • Re: Vacuum takes forever Dave Page
  • Re: Big problem with sql update operation Alvaro Herrera
  • Re: Vacuum takes forever Joost Kraaijeveld
  • Re: Vacuum takes forever PFC
  • Vacuum takes forever Joost Kraaijeveld
  • Re: general PG network slowness (possible cure) (repost) Merlin Moncure
  • Re: PITR performance costs Merlin Moncure
  • Re: Feature suggestion : FAST CLUSTER PFC
  • Re: Feature suggestion : FAST CLUSTER Jim Nasby
  • Re: Feature suggestion : FAST CLUSTER PFC
• 28 May 2007
  • Re: general PG network slowness (possible cure) (repost) Bruce Momjian
  • Re: PITR performance costs Simon Riggs
  • Re: PITR performance costs Stephen Frost
  • Re: PITR performance costs Dave Cramer
  • Re: PITR performance costs Heikki Linnakangas
  • Re: PITR performance costs A. Kretschmer
  • Re: PITR performance costs Bill Moran
  • PITR performance costs Dave Cramer
  • Re: Postgres Benchmark Results PFC
  • Re: Postgres Benchmark Results Chris
• 27 May 2007
  • Re: Feature suggestion : FAST CLUSTER PFC
  • Re: Feature suggestion : FAST CLUSTER Alexander Staubo
  • Re: Feature suggestion : FAST CLUSTER PFC
  • Re: Domains versus Check Constraints Stefan Kaltenbrunner
  • Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Jim C. Nasby
  • Re: Memory allocation and Vacuum abends Jim C. Nasby
  • Re: Simulate database fragmentation Jim C. Nasby
  • Re: Domains versus Check Constraints Jim C. Nasby
  • Re: Feature suggestion : FAST CLUSTER Jim C. Nasby
  • Re: ECC RAM really needed? Andrew Sullivan
• 26 May 2007
  • Re: general PG network slowness (possible cure) (repost) Tom Lane
  • Re: ECC RAM really needed? mark
  • Re: ECC RAM really needed? Michael Stone
  • Re: Performance problem on 8.2.4, but not 8.2.3 Kristo Kaiv
  • Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
  • Re: ECC RAM really needed? Tom Lane
  • Re: ECC RAM really needed? Greg Smith
  • Re: ECC RAM really needed? Bruno Wolff III
  • ECC RAM really needed? Craig James
  • Re: Adding disks/xlog & index Gregory Stark
  • Re: general PG network slowness (possible cure) (repost) Tom Lane
• 25 May 2007
  • Re: Adding disks/xlog & index Tom Lane
  • Re: Adding disks/xlog & index Tom Lane
  • Re: Big problem with sql update operation Alvaro Herrera
  • Re: Big problem with sql update operation Michal Szymanski
  • Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
  • Adding disks/xlog & index lists
  • Re: Performance problem on 8.2.4, but not 8.2.3 Dave Pirotte
  • Re: Performance problem on 8.2.4, but not 8.2.3 Tom Lane
  • Re: Performance problem on 8.2.4, but not 8.2.3 Steinar H. Gunderson
  • Re: Performance problem on 8.2.4, but not 8.2.3 Tom Lane
  • Re: Performance problem on 8.2.4, but not 8.2.3 Kristo Kaiv
  • Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
  • Performance problem on 8.2.4, but not 8.2.3 Dave Pirotte
  • Re: How PostgreSQL handles multiple DDBB instances? Tom Lane
  • Re: How PostgreSQL handles multiple DDBB instances? Arnau
  • Re: LIKE search and performance Richard Huxton
  • Re: How PostgreSQL handles multiple DDBB instances? Tom Lane
  • Re: LIKE search and performance Gregory Stark
  • Re: LIKE search and performance Richard Huxton
  • Re: LIKE search and performance Richard Huxton
  • Re: LIKE search and performance PFC
  • Re: How PostgreSQL handles multiple DDBB instances? Arnau
  • Re: LIKE search and performance Richard Huxton
  • Re: LIKE search and performance Joshua D. Drake
  • Re: LIKE search and performance mark
  • Re: LIKE search and performance PFC
  • Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
  • Re: general PG network slowness (possible cure) (repost) Tom Lane
  • Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
  • Re: LIKE search and performance Richard Huxton
  • Re: My quick and dirty "solution" (Re: Performance P roblem with Vacuum of bytea table (PG 8.0.13)) Andreas Kostyrka
  • Re: general PG network slowness (possible cure) (repost) Tom Lane
  • Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
  • Re: Big problem with sql update operation Tom Lane
  • Re: How PostgreSQL handles multiple DDBB instances? Tom Lane
  • Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Tom Lane
  • Re: LIKE search and performance mark
  • Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Bastian Voigt
  • Re: general PG network slowness (possible cure) (repost) Alvaro Herrera
  • Re: general PG network slowness (possible cure) (repost) Richard Huxton
  • Re: general PG network slowness (possible cure) (repost) Tom Lane
  • Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Bastian Voigt
  • Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
  • Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Alvaro Herrera
  • Re: general PG network slowness (possible cure) (repost) Richard Huxton
  • Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
  • Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
  • Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Kristo Kaiv
  • Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Richard Huxton
  • Re: general PG network slowness (possible cure) (repost) Steinar H. Gunderson
  • My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Bastian Voigt
  • Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Richard Huxton
  • Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Bastian Voigt
  • Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Richard Huxton
  • Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Bastian Voigt
  • Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Richard Huxton
  • Re: general PG network slowness (possible cure) (repost) Richard Huxton
  • Big problem with sql update operation Michal Szymanski
  • How PostgreSQL handles multiple DDBB instances? Arnau
  • Performance Problem with Vacuum of bytea table (PG 8.0.13) Bastian Voigt
  • general PG network slowness (possible cure) (repost) Peter T. Breuer
  • Re: LIKE search and performance Richard Huxton
• 24 May 2007
  • Re: LIKE search and performance PFC
  • Re: LIKE search and performance Craig James
  • Re: LIKE search and performance mark
  • Re: LIKE search and performance Alvaro Herrera
  • Re: LIKE search and performance Craig James
  • Re: LIKE search and performance Mark Lewis
  • Re: LIKE search and performance James Mansion
  • Re: LIKE search and performance Magnus Hagander
  • Re: LIKE search and performance James Mansion
  • Re: LIKE search and performance Andy
  • Re: max_fsm_pages, shared_buffers and checkpoint_segments Heikki Linnakangas
  • Memory allocation and Vacuum abends Leandro Guimarães dos Santos
• 23 May 2007
  • Re: Auto-ANALYZE? Tom Lane
  • Auto-ANALYZE? Craig James
  • Re: does VACUUM ANALYZE complete with this error? Scott Marlowe
  • Re: max_fsm_pages, shared_buffers and checkpoint_segments Peter Schuller
  • Re: Drop table vs Delete record Chris Mair
  • Re: does VACUUM ANALYZE complete with this error? Susan Russo
  • Simulate database fragmentation Y Sidhu
  • Re: does VACUUM ANALYZE complete with this error? Tom Lane
  • Re: [PERFORM] does VACUUM ANALYZE complete with this error? Tom Lane

• Thread Index
• [Prev Page]
• [Next Page]