• Text Size: Normal / Large
• Donate
• Contact

Section Navigation

• Community
• Contributors
• 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
• Featured Users
• International Sites
• Propaganda
• Resources
• Weekly News
• Community login
  • Profile
  • Lost password

pgsql-performance 2006-11 Chronological Index (2/2)

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

• 15 November 2006
  • Re: Context switch storm Simon Riggs
• 14 November 2006
  • Re: Context switch storm Cosimo Streppone
  • Re: Context switch storm Merlin Moncure
  • Re: Context switch storm Bucky Jordan
  • Re: Context switch storm Jim C. Nasby
  • Re: Context switch storm Merlin Moncure
  • Re: Context switch storm Andreas Kostyrka
  • Re: Context switch storm Cosimo Streppone
• 13 November 2006
  • Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?] Guy Thornley
• 11 November 2006
  • Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works Simon Riggs
• 10 November 2006
  • Re: [BUGS] BUG #2737: hash indexing large table fails, while btree of same index works Tom Lane
  • Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?] Ron Mayer
  • Re: 10x rowcount mis-estimation favouring merge over nestloop Abhijit Menon-Sen
  • Re: 10x rowcount mis-estimation favouring merge over nestloop Tom Lane
  • 10x rowcount mis-estimation favouring merge over nestloop Abhijit Menon-Sen
  • Re: Keeping processes open for re-use Joshua D. Drake
  • Re: Keeping processes open for re-use Shane Ambler
• 09 November 2006
  • Re: Keeping processes open for re-use imad
  • Re: Easy read-heavy benchmark kicking around? Merlin Moncure
  • Re: Keeping processes open for re-use Csaba Nagy
  • Keeping processes open for re-use Hilary Forbes
• 08 November 2006
  • Re: Easy read-heavy benchmark kicking around? Luke Lonergan
  • Re: Which OS provides the _fastest_ PostgreSQL performance? Ron Mayer
  • Re: Easy read-heavy benchmark kicking around? Cosimo Streppone
  • Re: Easy read-heavy benchmark kicking around? Merlin Moncure
  • Re: Easy read-heavy benchmark kicking around? Markus Schaber
• 07 November 2006
  • Re: Context switching Josh Berkus
  • Re: Easy read-heavy benchmark kicking around? Dimitri Fontaine
  • Re: Easy read-heavy benchmark kicking around? Mark Kirkwood
  • Re: Help w/speeding up range queries? Jim Nasby
• 06 November 2006
  • Re: Context switch storm Cosimo Streppone
  • Re: Easy read-heavy benchmark kicking around? Scott Marlowe
  • Re: Easy read-heavy benchmark kicking around? Merlin Moncure
  • Re: Easy read-heavy benchmark kicking around? Luke Lonergan
  • Easy read-heavy benchmark kicking around? Brian Hurt
  • RES: Context switching Carlos H. Reimer
  • Re: Yet another question on LIMIT performance :/ Tom Lane
  • Re: Setting "nice" values Madison Kelly
  • Re: Yet another question on LIMIT performance :/ Hannes Dorbath
  • Re: Yet another question on LIMIT performance :/ Heikki Linnakangas
  • Re: Setting "nice" values Tobias Brox
  • Yet another question on LIMIT performance :/ Hannes Dorbath
  • Re: Setting "nice" values Madison Kelly
  • Re: Setting "nice" values Tobias Brox
  • Re: Setting "nice" values Madison Kelly
  • Re: Setting "nice" values Madison Kelly
  • Re: Setting "nice" values Madison Kelly
  • Re: Setting "nice" values Jim Nasby
  • Re: Slow functional indexes? Gene
  • Re: Slow functional indexes? Tom Lane
• 05 November 2006
  • Re: Slow functional indexes? Stuart Bishop
• 03 November 2006
  • Re: profiling PL/pgSQL? korryd
  • EXISTS optimization Kevin Grittner
  • Re: Context switch storm Andreas Kostyrka
  • Re: Context switch storm Tom Lane
  • Re: profiling PL/pgSQL? Jonah H. Harris
  • Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Tom Lane
  • Re: Context switch storm Richard Huxton
  • Re: Context switch storm creimer
  • Re: Context switch storm Cosimo Streppone
  • Re: Context switch storm Richard Huxton
  • Re: Context switch storm Richard Troy
  • Re: Context switch storm Andreas Kostyrka
  • Re: Setting "nice" values Andreas Kostyrka
  • Re: Context switch storm Richard Huxton
  • Re: Context switch storm Richard Huxton
  • Re: Context switch storm Gregory S. Williamson
  • Context switch storm creimer
  • Re: profiling PL/pgSQL? Richard Huxton
  • Re: profiling PL/pgSQL? A. Kretschmer
  • profiling PL/pgSQL? Drew Wilson
  • Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Arjen van der Meijden
• 02 November 2006
  • Re: Locking vs. Exceptions Benjamin Minshall
  • Re: VACUUMs take twice as long across all nodes Vivek Khera
  • Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Alvaro Herrera
  • Re: Setting "nice" values Tobias Brox
  • Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed Alvaro Herrera
  • Re: Setting "nice" values Scott Marlowe
  • Re: Setting "nice" values Madison Kelly
  • Re: Setting "nice" values Scott Marlowe
  • Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed Steven Flatt
  • Setting "nice" values Madison Kelly
  • Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Dave Dutcher
  • Locking vs. Exceptions Robins
  • Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Richard Huxton
  • Query plan for "heavy" SELECT with "lite" sub-SELECTs Nikolay Samokhvalov
  • Re: Help w/speeding up range queries? Simon Riggs
  • Re: Help w/speeding up range queries? Marcin Mank
  • Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed Simon Riggs
• 01 November 2006
  • Re: Database-wide vacuum can take a long time, during which Matthew O'Connor
  • Database-wide vacuum can take a long time, during which tables are not being analyzed Steven Flatt
  • Re: big transaction slows down over time - but disk seems Richard Huxton
  • Re: big transaction slows down over time - but disk seems Ben
  • Re: big transaction slows down over time - but disk seems almost unused Ben
  • Re: big transaction slows down over time - but disk seems Richard Huxton
  • Re: MVCC & indexes? Ivan Voras
  • Re: big transaction slows down over time - but disk Andreas Kostyrka
  • Re: big transaction slows down over time - but disk seems almost unused Ben
  • Re: big transaction slows down over time - but disk seems Heikki Linnakangas
  • big transaction slows down over time - but disk seems almost unused Ben
  • Re: pg_trgm indexes giving bad estimations? Tom Lane
  • Re: Help w/speeding up range queries? Tom Lane
  • Re: pg_trgm indexes giving bad estimations? Ben
  • Re: Help w/speeding up range queries? Luke Lonergan
  • Context switching Carlos H. Reimer
  • Re: Help w/speeding up range queries? Tom Lane

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