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

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

• 14 April 2006
  • Re: Inserts optimization? Scott Marlowe
  • Re: Inserts optimization? Francisco Reyes
  • Re: Inserts optimization? Michael Stone
  • Re: bad performance on Solaris 10 Josh Berkus
  • Re: Inserts optimization? Francisco Reyes
  • Re: pgmemcache Christian Storm
  • Re: Inserts optimization? Francisco Reyes
  • Re: merge>hash>loop Tom Lane
  • Re: merge>hash>loop Ian Westmacott
  • Re: Inserts optimization? Tom Lane
  • Re: merge>hash>loop Tom Lane
  • Re: Inserts optimization? Francisco Reyes
  • merge>hash>loop Ian Westmacott
  • Re: Blocks read for index scans Tom Lane
  • Re: bad performance on Solaris 10 Jignesh K. Shah
  • pg_toast size Julien Drouard
  • Re: Inserts optimization? Marc Cousin
  • Re: Inserts optimization? Michael Stone
  • Re: Inserts optimization? Francisco Reyes
  • Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
  • Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
  • Re: Blocks read for index scans Terje Elde
  • Re: pg 7.4.x - pg_restore impossibly slow Jim C. Nasby
  • Re: Blocks read for index scans Jim C. Nasby
  • Re: Inserts optimization? Jim C. Nasby
  • Re: pg 7.4.x - pg_restore impossibly slow Tom Lane
  • Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
  • Re: pgmemcache Tom Lane
  • Re: Blocks read for index scans Tom Lane
• 13 April 2006
  • Re: pgmemcache Greg Stark
  • Re: pgmemcache PFC
  • Re: multi column query Sriram Dandapani
  • Re: bad performance on Solaris 10 Merlin Moncure
  • Re: Inserts optimization? Francisco Reyes
  • Re: Blocks read for index scans Jim Nasby
  • Re: Inserts optimization? Francisco Reyes
  • Re: pgmemcache Jim Nasby
  • Blocks read for index scans Jim Nasby
  • Re: bad performance on Solaris 10 Robert Lor
  • Re: pgmemcache Tom Lane
  • Re: pgmemcache Christian Storm
  • Re: multi column query Jim Nasby
  • Re: index is not used if I include a function that returns current time in my query Tom Lane
  • Re: Better index stategy for many fields with few values Oscar Picasso
  • Re: Slow query - possible bug? Tom Lane
  • index is not used if I include a function that returns current time in my query Cristian Veronesi
  • Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
  • Re: pgmemcache Markus Schaber
  • Re: Better index stategy for many fields with few values Markus Schaber
  • Re: Slow query - possible bug? Richard Huxton
  • Re: Slow query - possible bug? Gavin Hamill
  • Re: Slow query - possible bug? chris smith
  • Slow query - possible bug? Gavin Hamill
  • index is not used if I include a function that returns current time in my query Cris Carampa
  • Re: Better index stategy for many fields with few values Markus Schaber
  • Re: Better index stategy for many fields with few values Markus Schaber
  • Re: bad performance on Solaris 10 Bruce Momjian
  • Re: bad performance on Solaris 10 Tom Lane
  • Re: pg 7.4.x - pg_restore impossibly slow Tom Lane
  • Re: Inserts optimization? Tom Lane
  • Re: Sun Fire T2000 and PostgreSQL 8.1.3 Bruce Momjian
  • Re: bad performance on Solaris 10 Jignesh K. Shah
  • Re: FOREIGN KEYS vs PERFORMANCE Craig A. James
  • pg 7.4.x - pg_restore impossibly slow patrick keshishian
  • Re: Inserts optimization? Chris
  • Inserts optimization? Francisco Reyes
  • Re: multi column query Jim C. Nasby
  • Re: pgmemcache Tom Lane
  • multi column query Sriram Dandapani
  • Re: pgmemcache Jim C. Nasby
• 12 April 2006
  • Re: pgmemcache Josh Berkus
  • Re: Better index stategy for many fields with few values Jim Nasby
  • Re: bad performance on Solaris 10 Josh Berkus
  • Re: Better index stategy for many fields with few Luke Lonergan
  • Re: bad performance on Solaris 10 Luke Lonergan
  • Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
  • Re: Better index stategy for many fields with few values Jim C. Nasby
  • Re: bad performance on Solaris 10 Bruce Momjian
  • Re: FOREIGN KEYS vs PERFORMANCE Craig A. James
  • Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
  • Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
  • Re: FOREIGN KEYS vs PERFORMANCE Scott Marlowe
  • Re: FOREIGN KEYS vs PERFORMANCE PFC
  • Re: FOREIGN KEYS vs PERFORMANCE Michael Glaesemann
  • Re: FOREIGN KEYS vs PERFORMANCE Merlin Moncure
  • Re: FOREIGN KEYS vs PERFORMANCE Rodrigo Sakai
  • Re: FOREIGN KEYS vs PERFORMANCE Craig A. James
  • Re: FOREIGN KEYS vs PERFORMANCE Markus Schaber
  • Re: Sequencial scan instead of using index Harry Hehl
  • Re: Better index stategy for many fields with few values Markus Schaber
  • Re: FOREIGN KEYS vs PERFORMANCE PFC
  • Re: pgmemcache PFC
  • Re: FOREIGN KEYS vs PERFORMANCE Tom Lane
  • Re: Restore performance? Christopher Kings-Lynne
• 11 April 2006
  • Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
  • Re: FOREIGN KEYS vs PERFORMANCE Michael Glaesemann
  • Re: freebsd/softupdates for data dir Jim C. Nasby
  • Re: pgmemcache Jim C. Nasby
  • Re: Sequencial scan instead of using index Tom Lane
  • Re: Sequencial scan instead of using index Harry Hehl
  • Re: Sequencial scan instead of using index markir
  • Re: Sequencial scan instead of using index markir
  • Re: Encouraging multi-table join order Tom Lane
  • Re: Encouraging multi-table join order Dan Harris
  • Re: Encouraging multi-table join order Tom Lane
  • Re: Stored Procedure Performance Merlin Moncure
  • Re: Encouraging multi-table join order Dan Harris
  • Re: FOREIGN KEYS vs PERFORMANCE Scott Marlowe
  • FOREIGN KEYS vs PERFORMANCE Rodrigo Sakai
  • Re: Indexes with descending date columns Markus Schaber
  • Re: Stored Procedure Performance Alvaro Herrera
  • Re: Stored Procedure Performance H.J. Sanders
  • Re: Stored Procedure Performance Christopher Browne
  • Re: Takes too long to fetch the data from database Tom Lane
  • Re: Stored Procedure Performance Merlin Moncure
  • Re: Takes too long to fetch the data from database Merlin Moncure
  • Re: Restore performance? Jesper Krogh
  • Re: Takes too long to fetch the data from database Richard Huxton
  • Re: Stored Procedure Performance Richard Huxton
  • Re: Stored Procedure Performance Rajesh Kumar Mallah
  • Re: Stored Procedure Performance hubert depesz lubaczewski
  • Stored Procedure Performance Simon Dale
  • Re: Takes too long to fetch the data from database soni de
  • Re: slow "IN" clause Vinko Vrsalovic
  • Re: Encouraging multi-table join order Tom Lane
  • Re: Encouraging multi-table join order Dan Harris
• 10 April 2006
  • Re: Encouraging multi-table join order Tom Lane
  • Re: bad performance on Solaris 10 Chris Mair
  • Re: OT: Data structure design question: How do they count so fast? Brendan Duddridge
  • Re: pg 8.1.3, AIX, huge box, painfully slow. Brad Nicholson
  • Encouraging multi-table join order Dan Harris
  • Re: Restore performance? Vivek Khera
  • Re: Takes too long to fetch the data from database Joshua D. Drake
  • Re: Better index stategy for many fields with few values PFC
  • Re: Restore performance? PFC
  • Better index stategy for many fields with few values Oscar Picasso
  • Re: Restore performance? Alvaro Herrera
  • Re: Restore performance? Rajesh Kumar Mallah
  • Re: Takes too long to fetch the data from database Rajesh Kumar Mallah
  • Re: Restore performance? Jesper Krogh
  • Re: Restore performance? Rajesh Kumar Mallah
  • Re: Restore performance? Rajesh Kumar Mallah
  • Re: pg 8.1.3, AIX, huge box, painfully slow. Tom Lane
  • Re: Restore performance? Tom Lane
  • Re: Ragnar
  • Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
  • Re: pg 8.1.3, AIX, huge box, painfully slow. Simon Riggs
  • Re: OT: Data structure design question: How do they count Richard Huxton
  • Re: pg 8.1.3, AIX, huge box, painfully slow. Richard Huxton
  • Re: Restore performance? Marcin Mańk
  • Re: Restore performance? Jesper Krogh
  • Re: Restore performance? Andreas Pflug
  • Dump restore performance 7.3 -> 8.1 Jesper Krogh
  • Re: Restore performance? Luke Lonergan
  • Restore performance? Jesper Krogh
  • Re: Doron Baranes
  • Takes too long to fetch the data from database soni de
  • Re: serious problems with vacuuming databases Ahmad Fajar
  • Re: OT: Data structure design question: How do they count so fast? Brendan Duddridge
  • Re: slow "IN" clause Qingqing Zhou
  • slow "IN" clause FavoYang
• 09 April 2006
  • Re: serious problems with vacuuming databases Alvaro Herrera
  • Re: serious problems with vacuuming databases Tomas Vondra
  • Re: serious problems with vacuuming databases Alvaro Herrera
  • Re: serious problems with vacuuming databases Tomas Vondra
  • Re: serious problems with vacuuming databases Tomas Vondra
  • Re: serious problems with vacuuming databases Tomas Vondra
  • Re: Scaling up PostgreSQL in Multiple CPU / Dual Core Bruce Momjian
  • Re: serious problems with vacuuming databases Tom Lane
  • Re: serious problems with vacuuming databases Alvaro Herrera
  • serious problems with vacuuming databases Tomas Vondra
  • Re: pls reply ASAP Rajesh Kumar Mallah
  • Re: Ragnar
  • Re: Luckys
  • [no subject] Doron Baranes
  • pls reply ASAP Chethana, Rao (IE10)
  • OT: Data structure design question: How do they count so fast? Brendan Duddridge
  • Re: Indexes with descending date columns Bruce Momjian
• 08 April 2006
  • Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
• 07 April 2006
  • Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill

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