• 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 2006-04 Chronological Index (1/4)

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

• 28 March 2008
  • [no subject] Unknown
  • [no subject] Unknown
  • [no subject] Unknown
  • [no subject] Unknown
  • [no subject] Unknown
• 01 May 2006
  • Re: query performance question Dave Dutcher
• 30 April 2006
  • Re: Why so slow? Bill Moran
  • Re: Performance Issues on Opteron Dual Core Mark Kirkwood
  • Re: Why so slow? Bealach-na Bo
• 29 April 2006
  • Re: Worsening performance with 7.4 on flash-based system chris smith
  • Re: Easy question Michael Artz
  • Re: Worsening performance with 7.4 on flash-based system William Yu
  • Re: Slow restoration question Andreas Kretschmer
  • Re: Slow restoration question Tom Lane
  • Re: Why so slow? Michael Stone
  • Re: hardare config question Luke Lonergan
  • Re: Why so slow? K C Lau
  • Re: Why so slow? Tom Lane
  • Re: Why so slow? K C Lau
• 28 April 2006
  • Performance Issues on Opteron Dual Core Gregory Stewart
  • Re: Why so slow? Bruno Wolff III
  • Re: Worsening performance with 7.4 on flash-based system Greg Stumph
  • Re: hardare config question Ron Peacetree
  • Re: hardare config question Mark Lewis
  • Re: Why so slow? Alan Hodgson
  • Re: Why so slow? Bealach-na Bo
  • Re: hardare config question Vivek Khera
  • Re: Why so slow? Bealach-na Bo
  • Re: CPU usage goes to 100%, query seems to ran forever Andrus
  • hardare config question Erik Myllymaki
  • Re: Arrays and index scan Tom Lane
  • Re: Why so slow? Alan Hodgson
  • Re: Why so slow? Jim C. Nasby
  • Re: CPU usage goes to 100%, query seems to ran forever Tom Lane
  • Arrays and index scan Markus Schaber
  • Re: Why so slow? Bealach-na Bo
  • query performance question gulsah
  • Re: CPU usage goes to 100%, query seems to ran forever Andrus
  • Re: how unsafe (or worst scenarios) when setting fsync Markus Schaber
  • Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Mikael Carneholm
  • Re: Large (8M) cache vs. dual-core CPUs Sven Geisler
  • Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Guoping Zhang
  • Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Guoping Zhang
  • Re: how unsafe (or worst scenarios) when setting fsync Tom Lane
  • Re: how unsafe (or worst scenarios) when setting fsync Guoping Zhang
  • Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Tom Lane
  • Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Guoping Zhang
  • Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood
• 27 April 2006
  • Re: CPU usage goes to 100%, query seems to ran forever Tom Lane
  • Re: Running on an NFS Mounted Directory Dan Gorman
  • CPU usage goes to 100%, query seems to ran forever Andrus
  • Re: Why so slow? Andreas Kretschmer
  • Why so slow? Bealach-na Bo
  • Re: Running on an NFS Mounted Directory Michael Stone
  • Re: Running on an NFS Mounted Directory Jim C. Nasby
  • Re: Firebird 1.5.3 X Postgresql 8.1.3 (linux Firebird 1.5.3 X Postgresql 8.1.3 (linux and and windows)] Tom Lane
  • Re: Large (8M) cache vs. dual-core CPUs Vivek Khera
  • Re: Large (8M) cache vs. dual-core CPUs Vivek Khera
  • Re: how unsafe (or worst scenarios) when setting fsync Tom Lane
  • Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Tom Lane
  • Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
  • Re: Running on an NFS Mounted Directory Michael Stone
  • Re: Running on an NFS Mounted Directory Ketema Harris
  • Re: Running on an NFS Mounted Directory Ketema Harris
  • Re: Running on an NFS Mounted Directory Bruno Wolff III
  • Re: Running on an NFS Mounted Directory Michael Stone
  • Re: Running on an NFS Mounted Directory Steve Wampler
  • Re: Running on an NFS Mounted Directory Ketema Harris
  • Re: Running on an NFS Mounted Directory Bruno Wolff III
  • Re: Running on an NFS Mounted Directory Ketema Harris
  • Re: Running on an NFS Mounted Directory Michael Stone
  • Re: Running on an NFS Mounted Directory Ketema Harris
  • Firebird 1.5.3 X Postgresql 8.1.3 (linux Firebird 1.5.3 X Postgresql 8.1.3 (linux and and windows)] andremachado
  • Re: Introducing a new linux readahead framework Michael Stone
  • Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Guillaume Smet
  • Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Mikael Carneholm
  • Re: how unsafe (or worst scenarios) when setting fsync Simon Riggs
  • how unsafe (or worst scenarios) when setting fsync OFF for postgresql Guoping Zhang
  • Re: Running on an NFS Mounted Directory Dan Gorman
  • Re: Running on an NFS Mounted Directory Jim C. Nasby
  • Re: Running on an NFS Mounted Directory Steve Wampler
  • Re: Large (8M) cache vs. dual-core CPUs mark
  • Re: Slow deletes in 8.1 when FKs are involved Will Reese
  • Running on an NFS Mounted Directory Ketema Harris
  • Re: Easy question Bert
• 26 April 2006
  • Re: [Bizgres-general] Introducing a new linux Michael Stone
  • Re: Slow deletes in 8.1 when FKs are involved Stef T
  • Re: [Bizgres-general] Introducing a new linux Luke Lonergan
  • Re: WAL logging of SELECT ... INTO command Bruce Momjian
  • Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
  • Re: Introducing a new linux readahead framework Jim C. Nasby
  • Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
  • Re: Large (8M) cache vs. dual-core CPUs Bruce Momjian
  • Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
  • Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
  • Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
  • Re: Introducing a new linux readahead framework Steve Poe
  • Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
  • Re: Large (8M) cache vs. dual-core CPUs William Yu
  • Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
  • Re: Large (8M) cache vs. dual-core CPUs PFC
  • Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
  • Re: Introducing a new linux readahead framework Michael Stone
  • Re: Large (8M) cache vs. dual-core CPUs David Boreham
  • Re: slow deletes on pgsql 7.4 Junaili Lie
  • Re: Large (8M) cache vs. dual-core CPUs William Yu
  • Re: Large (8M) cache vs. dual-core CPUs David Boreham
  • Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
  • Slow restoration question Eric Lam
  • Re: Large (8M) cache vs. dual-core CPUs mark
  • Re: PL/pgSQL Loop Vs. Batch Update David Wheeler
  • Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
  • Re: PL/pgSQL Loop Vs. Batch Update Tom Lane
  • Re: PL/pgSQL Loop Vs. Batch Update David Wheeler
  • Re: Large (8M) cache vs. dual-core CPUs Leigh Dyer
  • Re: Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows) Tom Lane
  • Re: Hardware: HP StorageWorks MSA 1500 mlartz(at)gmail(dot)com
  • Re: Query on postgresql 7.4.2 not using index chris smith
  • Re: PL/pgSQL Loop Vs. Batch Update Tom Lane
  • Re: Large (8M) cache vs. dual-core CPUs mark
  • Re: slow deletes on pgsql 7.4 Tom Lane
  • Re: Large (8M) cache vs. dual-core CPUs mark
  • Re: slow deletes on pgsql 7.4 Junaili Lie
  • Re: Slow deletes in 8.1 when FKs are involved Will Reese
• 25 April 2006
  • Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
  • Re: slow deletes on pgsql 7.4 Tom Lane
  • Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
  • Re: slow deletes on pgsql 7.4 Junaili Lie
  • Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
  • slow deletes on pgsql 7.4 Junaili Lie
  • Re: Large (8M) cache vs. dual-core CPUs David Boreham
  • Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
  • Re: Large (8M) cache vs. dual-core CPUs Bruce Momjian
  • Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
  • Re: Large (8M) cache vs. dual-core CPUs David Boreham
  • Re: ip address data type Florian Weimer
  • Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
  • Re: planner not using index for like operator Sriram Dandapani
  • Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
  • Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
  • Re: Large (8M) cache vs. dual-core CPUs mark
  • Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
  • Re: Slow queries salad ;) Jim C. Nasby
  • Re: Large (8M) cache vs. dual-core CPUs Gavin Hamill
  • Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
  • Re: planner not using index for like operator Sriram Dandapani
  • Re: planner not using index for like operator Jim C. Nasby
  • Re: Slow queries salad ;) Tom Lane
  • Large (8M) cache vs. dual-core CPUs Bill Moran
  • Re: planner not using index for like operator Dave Dutcher
  • Slow queries salad ;) PFC
  • planner not using index for like operator Sriram Dandapani
  • Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows) andremachado
  • PL/pgSQL Loop Vs. Batch Update David Wheeler
  • Re: Query on postgresql 7.4.2 not using index Arnau
  • Re: Query on postgresql 7.4.2 not using index Tom Lane
  • Re: Query on postgresql 7.4.2 not using index Scott Marlowe
  • Re: Easy question codeWarrior
  • Re: Query on postgresql 7.4.2 not using index Arnau
  • Re: Query on postgresql 7.4.2 not using index Tom Lane
  • Re: Query on postgresql 7.4.2 not using index Scott Marlowe
  • Re: Query on postgresql 7.4.2 not using index Guillaume Smet
  • Re: Query on postgresql 7.4.2 not using index Arnau
  • Re: Query on postgresql 7.4.2 not using index chris smith
  • Query on postgresql 7.4.2 not using index Arnau
  • Re: security for row level but not based on Database user's Richard Huxton
  • Re: security for row level but not based on Database user's Richard Huxton
• 24 April 2006
  • Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood
  • Re: ip address data type Steve Atkins
  • Re: ip address data type Jim C. Nasby
  • ip address data type Sriram Dandapani
  • Re: Index on function less well cached than "regular" index ? Tom Lane
  • Re: GROUP BY Vs. Sub SELECT Jim C. Nasby
  • Re: Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
  • Re: serious problems with vacuuming databases Tomas Vondra
  • Re: GROUP BY Vs. Sub SELECT Richard Broersma Jr
  • Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
  • Re: GROUP BY Vs. Sub SELECT Bruno Almeida do Lago
  • Index on function less well cached than "regular" index ? Paul Mackay
  • Re: Slow deletes in 8.1 when FKs are involved Jim C. Nasby

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