Mailing lists [pgsql-performance]

1 April 2006

• 00:09   Re: Query using SeqScan instead of IndexScan Brendan Duddridge
• 00:23   Re: Query using SeqScan instead of IndexScan chris smith
• 00:31   Re: Query using SeqScan instead of IndexScan Brendan Duddridge
• 08:54   Re: [Solved] Slow performance on Windows .NET and OleDb Antoine
• 14:32   Re: Query using SeqScan instead of IndexScan Jim C. Nasby
• 16:51   Re: Query using SeqScan instead of IndexScan Brendan Duddridge
• 18:23   Re: [Solved] Slow performance on Windows .NET and OleDb Merlin Moncure
• 23:50   Re: Query using SeqScan instead of IndexScan chris smith

2 April 2006

• 00:32   Re: Query using SeqScan instead of IndexScan chris smith
• 03:26   Re: Query using SeqScan instead of IndexScan Alvaro Herrera
• 03:31   Re: Query using SeqScan instead of IndexScan Mark Kirkwood
• 03:46   Re: Query using SeqScan instead of IndexScan Tom Lane
• 08:32   Trigger vs Rule Ключников А.С.
• 14:33   Re: statistics buffer is full Qingqing Zhou
• 14:36   Re: Large Binary Objects Middleware Qingqing Zhou
• 14:45   Re: Logging SQL queries to optimize them ? Qingqing Zhou
• 16:20   Re: index not used again Jan Kesten
• 19:47   Re: index not used again Stephan Szabo
• 21:11   Re: Trigger vs Rule Niklas Johansson
• 22:30   Re: Query using SeqScan instead of IndexScan Josh Berkus

3 April 2006

• 04:20   Re: Query using SeqScan instead of IndexScan Brendan Duddridge
• 09:04   Re: Trigger vs Rule Niklas Johansson
• 09:17   Re: Trigger vs Rule Ключников А.С.
• 09:42   Measuring the execution time of functions within functions... Mario Splivalo
• 12:50   Re: Measuring the execution time of functions within functions... Alvaro Herrera
• 16:32   Re: Measuring the execution time of functions within functions... Jerry Sievers
• 18:24   optimizing db for small table with tons of updates Kenji Morishige
• 18:31   Re: optimizing db for small table with tons of updates Josh Berkus
• 18:36   Re: optimizing db for small table with tons of updates Rajesh Kumar Mallah
• 18:39   Re: optimizing db for small table with tons of updates Tom Lane
• 19:02   Re: optimizing db for small table with tons of updates Kenji Morishige
• 19:04   Re: optimizing db for small table with tons of updates Alvaro Herrera
• 19:08   Re: optimizing db for small table with tons of updates Kenji Morishige
• 19:23   Re: optimizing db for small table with tons of updates Tom Lane
• 19:29   Re: optimizing db for small table with tons of updates Kenji Morishige
• 21:25   The order of fields around the "=" in the WHERE conditions Mike Quinn
• 21:35   Re: The order of fields around the "=" in the WHERE conditions Tom Lane
• 21:58   Re: The order of fields around the "=" in the WHERE conditions Tom Lane

4 April 2006

• 00:39   bad performance on Solaris 10 Chris Mair
• 00:51   Re: bad performance on Solaris 10 Josh Berkus
• 00:54   freebsd/softupdates for data dir Miguel
• 02:11   Re: freebsd/softupdates for data dir Mark Kirkwood
• 03:46   Re: bad performance on Solaris 10 Luke Lonergan
• 05:12   Re: bad performance on Solaris 10 Mark Kirkwood
• 06:09   Re: bad performance on Solaris 10 Josh Berkus
• 14:41   Re: freebsd/softupdates for data dir Vivek Khera
• 14:59   vacuum full seems to hang on very small table Dan Harris
• 15:08   Re: vacuum full seems to hang on very small table Brad Nicholson
• 15:38   Re: vacuum full seems to hang on very small table Simon Riggs
• 17:19   Re: The order of fields around the "=" in the WHERE Mike Quinn
• 19:39   Query runs too long for indexed tables Andrus
• 19:48   Re: Query runs too long for indexed tables Scott Marlowe
• 20:00   Re: Query runs too long for indexed tables Marc Morin
• 20:03   Re: Query runs too long for indexed tables Marc Morin
• 20:26   Re: Query using SeqScan instead of IndexScan Jim Nasby
• 20:28   Re: Query using SeqScan instead of IndexScan Jim Nasby
• 22:07   Re: The order of fields around the "=" in the WHERE Mike Quinn

5 April 2006

• 09:40   Re: Query runs too long for indexed tables Andrus
• 10:22   Re: Query runs too long for indexed tables PFC
• 10:40   Re: Query runs too long for indexed tables Andrus
• 11:24   Re: Query runs too long for indexed tables PFC
• 14:10   Re: Query runs too long for indexed tables Tom Lane
• 18:14   Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
• 19:04   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Tom Lane
• 20:43   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
• 20:56   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
• 21:31   Re: bad performance on Solaris 10 Chris Mair
• 21:37   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
• 21:40   Re: bad performance on Solaris 10 Luke Lonergan
• 21:46   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
• 21:48   Re: bad performance on Solaris 10 Alvaro Herrera
• 21:54   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
• 21:56   Re: bad performance on Solaris 10 Luke Lonergan
• 21:58   Re: Sun Fire T2000 and PostgreSQL 8.1.3 August Zajonc
• 22:03   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Josh Berkus
• 22:07   Re: freebsd/softupdates for data dir Jim Nasby
• 22:08   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Scott Marlowe
• 22:24   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Tom Lane
• 23:04   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Chris Browne
• 23:04   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Chris Browne
• 23:14   Re: bad performance on Solaris 10 Chris Mair
• 23:25   Re: bad performance on Solaris 10 Mark Kirkwood
• 23:29   Re: bad performance on Solaris 10 Chris Mair
• 23:33   Re: bad performance on Solaris 10 Chris Mair

6 April 2006

• 00:35   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
• 00:49   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
• 01:18   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Marcelo Tada
• 01:24   Re: bad performance on Solaris 10 Mark Kirkwood
• 03:36   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Anthony Ransley
• 03:41   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Robert Lor
• 04:16   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Robert Lor
• 04:23   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Leigh Dyer
• 04:27   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
• 04:47   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Leigh Dyer
• 06:01   Re: bad performance on Solaris 10 Chris Mair
• 06:29   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
• 06:31   Re: bad performance on Solaris 10 Josh Berkus
• 06:34   Re: bad performance on Solaris 10 Josh Berkus
• 06:45   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Mark Kirkwood
• 06:56   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Josh Berkus
• 07:29   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Miguel
• 07:37   Re: bad performance on Solaris 10 Robert Lor
• 07:42   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Leigh Dyer
• 08:02   Query planner is using wrong index. Brian Herlihy
• 08:50   Re: Query planner is using wrong index. Ragnar
• 08:57   Maintenance_work_mem influence on queries luchot
• 09:08   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Markus Schaber
• 09:27   Re: Query planner is using wrong index. Brian Herlihy
• 11:34   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Juan Casero \(FL FLC\)
• 11:47   Re: Query planner is using wrong index. Ragnar
• 13:30   Re: Intel C/C++ Compiler Tests (fwd) Bruce Momjian
• 13:45   Re: freebsd/softupdates for data dir Vivek Khera
• 14:01   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Matthew Nuzum
• 14:01   Re: Query planner is using wrong index. Brian Herlihy
• 14:48   CURSOR OR OFFSET/LIMIT Kaloyan Iliev
• 15:20   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Vivek Khera
• 15:36   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Vivek Khera
• 15:39   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Vivek Khera
• 16:18   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Luke Lonergan
• 16:18   Re: Query planner is using wrong index. Ragnar
• 17:11   Re: CURSOR OR OFFSET/LIMIT John DeSoi
• 21:55   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Jignesh K. Shah
• 22:13   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Jignesh K. Shah
• 23:56   Re: Query planner is using wrong index. Brian Herlihy

7 April 2006

• 00:09   Re: Query planner is using wrong index. Dave Dutcher
• 00:15   Re: Query planner is using wrong index. Brian Herlihy
• 03:17   Re: Query planner is using wrong index. Tom Lane
• 06:41   Re: Query planner is using wrong index. Brian Herlihy
• 12:45   Same SQL, 104296ms of difference between 7.4.12 and 8.0.7 Rafael Martinez Guerrero
• 13:31   Re: Same SQL, 104296ms of difference between 7.4.12 and Richard Huxton
• 14:00   Re: Same SQL, 104296ms of difference between 7.4.12 and Rafael Martinez Guerrero
• 14:34   Re: Query planner is using wrong index. Tom Lane
• 14:38   Loading the entire DB into RAM Charles A. Landemaine
• 14:40   Re: Same SQL, 104296ms of difference between 7.4.12 and Richard Huxton
• 14:51   Re: Same SQL, 104296ms of difference between 7.4.12 and Rafael Martinez
• 15:01   Re: Loading the entire DB into RAM Charles A. Landemaine
• 15:01   Re: Loading the entire DB into RAM Matt Davies | Postgresql List
• 15:08   Spotting planner errors (was Re: Query planner is using wrong index.) Richard Huxton
• 15:12   Re: Spotting planner errors (was Re: Query planner is using wrong index.) Tom Lane
• 15:25   Re: Spotting planner errors (was Re: Query planner is using Richard Huxton
• 15:25   Re: Loading the entire DB into RAM Tom Lane
• 15:29   Re: Same SQL, 104296ms of difference between 7.4.12 and 8.0.7 Tom Lane
• 15:30   Re: Loading the entire DB into RAM Merlin Moncure
• 15:49   Re: Loading the entire DB into RAM Scott Marlowe
• 17:11   Re: Loading the entire DB into RAM PFC
• 17:37   Re: Same SQL, 104296ms of difference between 7.4.12 and 8.0.7 Tom Lane
• 18:29   pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
• 18:41   Re: pg 8.1.3, AIX, huge box, painfully slow. Tom Lane
• 18:54   Re: pg 8.1.3, AIX, huge box, painfully slow. Scott Marlowe
• 19:02   Re: Same SQL, 104296ms of difference between 7.4.12 and Rafael Martinez
• 19:29   Re: bad performance on Solaris 10 Chris Mair
• 19:46   Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
• 19:59   Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
• 20:06   Re: pg 8.1.3, AIX, huge box, painfully slow. Tom Lane
• 20:16   Re: pg 8.1.3, AIX, huge box, painfully slow. D'Arcy J.M. Cain
• 20:24   Re: pg 8.1.3, AIX, huge box, painfully slow. Scott Marlowe
• 20:30   Re: pg 8.1.3, AIX, huge box, painfully slow. Greg Stark
• 20:39   Re: pg 8.1.3, AIX, huge box, painfully slow. Gábriel Ákos
• 21:19   Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
• 21:26   Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
• 21:36   Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
• 21:50   Re: pg 8.1.3, AIX, huge box, painfully slow. Luke Lonergan
• 21:56   Re: pg 8.1.3, AIX, huge box, painfully slow. Tom Lane
• 22:03   Re: pg 8.1.3, AIX, huge box, painfully slow. Tom Lane
• 22:07   Re: pg 8.1.3, AIX, huge box, painfully slow. Luke Lonergan
• 22:12   Re: pg 8.1.3, AIX, huge box, painfully slow. Tom Lane
• 22:28   Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
• 22:52   Re: pg 8.1.3, AIX, huge box, painfully slow. Tom Lane
• 22:57   Re: pg 8.1.3, AIX, huge box, painfully slow. Luke Lonergan
• 23:05   Re: pg 8.1.3, AIX, huge box, painfully slow. Tom Lane
• 23:39   Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill

8 April 2006

• 01:26   Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill

9 April 2006

• 03:27   Re: Indexes with descending date columns Bruce Momjian
• 05:49   OT: Data structure design question: How do they count so fast? Brendan Duddridge
• 09:23   pls reply ASAP Chethana, Rao (IE10)
• 09:47    Doron Baranes
• 10:42   Re: Luckys
• 11:07   Re: Ragnar
• 15:34   Re: pls reply ASAP Rajesh Kumar Mallah
• 18:23   serious problems with vacuuming databases Tomas Vondra
• 18:38   Re: serious problems with vacuuming databases Alvaro Herrera
• 18:54   Re: serious problems with vacuuming databases Tom Lane
• 20:25   Re: Scaling up PostgreSQL in Multiple CPU / Dual Core Bruce Momjian
• 20:34   Re: serious problems with vacuuming databases Tomas Vondra
• 20:37   Re: serious problems with vacuuming databases Tomas Vondra
• 20:45   Re: serious problems with vacuuming databases Tomas Vondra
• 20:46   Re: serious problems with vacuuming databases Alvaro Herrera
• 21:49   Re: serious problems with vacuuming databases Tomas Vondra
• 22:02   Re: serious problems with vacuuming databases Alvaro Herrera

10 April 2006

• 04:48   Re: slow "IN" clause Qingqing Zhou
• 05:50   Re: OT: Data structure design question: How do they count so fast? Brendan Duddridge
• 06:59   Re: serious problems with vacuuming databases Ahmad Fajar
• 07:21   Takes too long to fetch the data from database soni de
• 07:30   Re: Doron Baranes
• 07:56   Restore performance? Jesper Krogh
• 08:07   Re: Restore performance? Luke Lonergan
• 08:22   Dump restore performance 7.3 -> 8.1 Jesper Krogh
• 08:43   Re: Restore performance? Andreas Pflug
• 08:46   Re: Restore performance? Jesper Krogh
• 09:01   Re: Restore performance? Marcin Mańk
• 09:06   Re: pg 8.1.3, AIX, huge box, painfully slow. Richard Huxton
• 09:24   Re: OT: Data structure design question: How do they count Richard Huxton
• 09:27   Re: pg 8.1.3, AIX, huge box, painfully slow. Simon Riggs
• 09:44   Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
• 11:56   Re: Ragnar
• 15:24   Re: Restore performance? Tom Lane
• 15:36   Re: pg 8.1.3, AIX, huge box, painfully slow. Tom Lane
• 15:40   Re: Restore performance? Rajesh Kumar Mallah
• 15:43   Re: Restore performance? Rajesh Kumar Mallah
• 15:55   Re: Restore performance? Jesper Krogh
• 15:58   Re: Takes too long to fetch the data from database Rajesh Kumar Mallah
• 16:09   Re: Restore performance? Rajesh Kumar Mallah
• 16:24   Re: Restore performance? Alvaro Herrera
• 16:59   Better index stategy for many fields with few values Oscar Picasso
• 17:19   Re: Restore performance? PFC
• 17:25   Re: Better index stategy for many fields with few values PFC
• 19:40   Re: Takes too long to fetch the data from database Joshua D. Drake
• 20:10   Re: Restore performance? Vivek Khera
• 20:21   Encouraging multi-table join order Dan Harris
• 20:40   Re: pg 8.1.3, AIX, huge box, painfully slow. Brad Nicholson
• 21:04   Re: OT: Data structure design question: How do they count so fast? Brendan Duddridge
• 21:12   Re: bad performance on Solaris 10 Chris Mair
• 23:59   Re: Encouraging multi-table join order Tom Lane

11 April 2006

• 00:49   Re: Encouraging multi-table join order Dan Harris
• 02:05   Re: Encouraging multi-table join order Tom Lane
• 02:29   pgmemcache C Storm
• 02:30   slow "IN" clause FavoYang@gmail.com
• 05:02   Re: slow "IN" clause Vinko Vrsalovic
• 07:05   Re: Takes too long to fetch the data from database soni de
• 07:19   Stored Procedure Performance Simon Dale
• 07:58   Re: Stored Procedure Performance hubert depesz lubaczewski
• 08:23   Re: Stored Procedure Performance Rajesh Kumar Mallah
• 10:04   Re: Stored Procedure Performance Richard Huxton
• 10:17   Re: Takes too long to fetch the data from database Richard Huxton
• 12:05   Re: Restore performance? Jesper Krogh
• 13:13   Re: Takes too long to fetch the data from database Merlin Moncure
• 13:50   Re: Stored Procedure Performance Merlin Moncure
• 13:50   Re: Takes too long to fetch the data from database Tom Lane
• 13:57   Re: Stored Procedure Performance Christopher Browne
• 14:02   Re: Stored Procedure Performance H.J. Sanders
• 14:09   Re: Stored Procedure Performance Alvaro Herrera
• 17:59   Re: Indexes with descending date columns Markus Schaber
• 19:35   FOREIGN KEYS vs PERFORMANCE Rodrigo Sakai
• 20:26   Re: FOREIGN KEYS vs PERFORMANCE Scott Marlowe
• 21:13   Re: Encouraging multi-table join order Dan Harris
• 21:14   Re: Stored Procedure Performance Merlin Moncure
• 21:20   Re: Encouraging multi-table join order Tom Lane
• 21:30   Re: Encouraging multi-table join order Dan Harris
• 22:13   Re: Encouraging multi-table join order Tom Lane
• 22:29   Re: Sequencial scan instead of using index markir@paradise.net.nz
• 22:30   Re: Sequencial scan instead of using index markir@paradise.net.nz
• 22:32   Re: Sequencial scan instead of using index Harry Hehl
• 22:50   Re: Sequencial scan instead of using index Tom Lane
• 22:55   Re: pgmemcache Jim C. Nasby
• 22:59   Re: freebsd/softupdates for data dir Jim C. Nasby
• 23:06   Re: FOREIGN KEYS vs PERFORMANCE Michael Glaesemann
• 23:38   Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby

12 April 2006

• 02:05   Re: Restore performance? Christopher Kings-Lynne
• 02:56   Re: FOREIGN KEYS vs PERFORMANCE Tom Lane
• 07:18   Re: pgmemcache PFC
• 07:22   Re: FOREIGN KEYS vs PERFORMANCE PFC
• 12:59   Re: Better index stategy for many fields with few values Markus Schaber
• 13:04   Re: Sequencial scan instead of using index Harry Hehl
• 13:18   Re: FOREIGN KEYS vs PERFORMANCE Markus Schaber
• 14:50   Re: FOREIGN KEYS vs PERFORMANCE Craig A. James
• 14:50   Re: FOREIGN KEYS vs PERFORMANCE Rodrigo Sakai
• 15:03   Re: FOREIGN KEYS vs PERFORMANCE Merlin Moncure
• 15:07   Re: FOREIGN KEYS vs PERFORMANCE Michael Glaesemann
• 15:09   Re: FOREIGN KEYS vs PERFORMANCE PFC
• 15:13   Re: FOREIGN KEYS vs PERFORMANCE Scott Marlowe
• 15:36   Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
• 15:40   Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
• 17:45   Re: FOREIGN KEYS vs PERFORMANCE Craig A. James
• 19:56   Re: bad performance on Solaris 10 Bruce Momjian
• 20:44   Re: Better index stategy for many fields with few values Jim C. Nasby
• 21:41   Re: FOREIGN KEYS vs PERFORMANCE Jim C. Nasby
• 22:35   Re: bad performance on Solaris 10 Luke Lonergan
• 22:38   Re: Better index stategy for many fields with few Luke Lonergan
• 22:50   Re: bad performance on Solaris 10 Josh Berkus
• 23:04   Re: Better index stategy for many fields with few values Jim Nasby
• 23:05   Re: pgmemcache Josh Berkus

13 April 2006

• 00:10   Re: pgmemcache Jim C. Nasby
• 00:33   multi column query Sriram Dandapani
• 00:35   Re: pgmemcache Tom Lane
• 00:43   Re: multi column query Jim C. Nasby
• 01:11   Inserts optimization? Francisco Reyes
• 01:19   Re: Inserts optimization? Chris
• 01:26   pg 7.4.x - pg_restore impossibly slow patrick keshishian
• 01:37   Re: FOREIGN KEYS vs PERFORMANCE Craig A. James
• 01:53   Re: bad performance on Solaris 10 Jignesh K. Shah
• 02:55   Re: Sun Fire T2000 and PostgreSQL 8.1.3 Bruce Momjian
• 04:42   Re: Inserts optimization? Tom Lane
• 04:46   Re: pg 7.4.x - pg_restore impossibly slow Tom Lane
• 04:52   Re: bad performance on Solaris 10 Tom Lane
• 08:39   Re: bad performance on Solaris 10 Bruce Momjian
• 09:33   Re: Better index stategy for many fields with few values Markus Schaber
• 09:51   Re: Better index stategy for many fields with few values Markus Schaber
• 12:34   Slow query - possible bug? Gavin Hamill
• 12:46   Re: Slow query - possible bug? chris smith
• 13:08   Re: Slow query - possible bug? Gavin Hamill
• 14:00   Re: Slow query - possible bug? Richard Huxton
• 14:00   Re: Better index stategy for many fields with few values Markus Schaber
• 14:03   Re: pgmemcache Markus Schaber
• 14:48   Re: pg 8.1.3, AIX, huge box, painfully slow. Gavin Hamill
• 15:21   index is not used if I include a function that returns current time in my query Cristian Veronesi
• 15:27   Re: Slow query - possible bug? Tom Lane
• 15:40   Re: Better index stategy for many fields with few values Oscar Picasso
• 15:50   Re: index is not used if I include a function that returns current time in my query Tom Lane
• 16:43   Re: multi column query Jim Nasby
• 17:38   Re: pgmemcache Tom Lane
• 17:40   Re: bad performance on Solaris 10 Robert Lor
• 18:00   Blocks read for index scans Jim Nasby
• 18:29   Re: pgmemcache Jim Nasby
• 18:46   Re: Inserts optimization? Francisco Reyes
• 18:49   Re: Blocks read for index scans Jim Nasby
• 18:59   Re: Inserts optimization? Francisco Reyes
• 19:38   Re: bad performance on Solaris 10 Merlin Moncure
• 19:52   Re: multi column query Sriram Dandapani
• 20:22   Re: pgmemcache PFC
• 20:53   Re: pgmemcache Greg Stark

14 April 2006

• 00:36   Re: Blocks read for index scans Tom Lane
• 00:44   Re: pgmemcache Tom Lane
• 01:26   Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
• 03:15   Re: pg 7.4.x - pg_restore impossibly slow Tom Lane
• 05:59   Re: Inserts optimization? Jim C. Nasby
• 06:14   Re: Blocks read for index scans Jim C. Nasby
• 06:20   Re: pg 7.4.x - pg_restore impossibly slow Jim C. Nasby
• 06:37   Re: Blocks read for index scans Terje Elde
• 07:01   Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
• 07:11   Re: pg 7.4.x - pg_restore impossibly slow patrick keshishian
• 11:30   Re: Inserts optimization? Francisco Reyes
• 11:49   Re: Inserts optimization? Michael Stone
• 12:00   Re: Inserts optimization? Marc Cousin
• 13:34   pg_toast size Julien Drouard
• 14:02   Re: bad performance on Solaris 10 Jignesh K. Shah
• 15:13   Re: Blocks read for index scans Tom Lane
• 16:04   merge>hash>loop Ian Westmacott
• 16:10   Re: Inserts optimization? Francisco Reyes
• 16:13   Re: merge>hash>loop Tom Lane
• 16:30   Re: Inserts optimization? Tom Lane
• 16:46   Re: merge>hash>loop Ian Westmacott
• 16:59   Re: merge>hash>loop Tom Lane
• 17:50   Re: Inserts optimization? Francisco Reyes
• 18:02   Re: Inserts optimization? Francisco Reyes
• 19:03   Re: bad performance on Solaris 10 Josh Berkus
• 19:06   Re: Inserts optimization? Michael Stone
• 20:09   Re: Inserts optimization? Francisco Reyes
• 20:15   Re: Inserts optimization? Scott Marlowe
• 20:28   Re: Inserts optimization? Francisco Reyes

15 April 2006

• 08:33   Re: Inserts optimization? Gábriel Ákos
• 08:35   Re: Inserts optimization? Gábriel Ákos
• 13:16   Re: Inserts optimization? Francisco Reyes
• 13:26   Re: Inserts optimization? Francisco Reyes
• 13:34   Re: Inserts optimization? Francisco Reyes

16 April 2006

• 23:23   Migration study, step 2: rewriting queries Mikael Carneholm

17 April 2006

• 01:35   Re: Migration study, step 2: rewriting queries Tom Lane
• 12:10   index is not used if I include a function that returns current time in my query Cris Carampa
• 12:10   Re: pgmemcache Christian Storm
• 12:10   Re: pgmemcache Christian Storm
• 14:35   slow cursor Sriram Dandapani
• 18:36   creating of temporary table takes very long Sriram Dandapani
• 18:52   Re: creating of temporary table takes very long Sriram Dandapani
• 19:28   Re: creating of temporary table takes very long Tom Lane
• 19:49   Re: creating of temporary table takes very long Sriram Dandapani
• 20:05   Re: creating of temporary table takes very long Sriram Dandapani

18 April 2006

• 04:55   Re: slow cursor Luckys
• 08:10   Re: Slow query - possible bug? Gavin Hamill
• 08:51   Re: Migration study, step 2: rewriting queries Mikael Carneholm
• 09:02   Re: Inserts optimization? Markus Schaber
• 10:52   Re: merge>hash>loop Markus Schaber
• 11:56   Re: Inserts optimization? Magnus Hagander
• 13:08   SELECT FOR UPDATE performance is bad Mario Splivalo
• 14:31   Re: SELECT FOR UPDATE performance is bad Tom Lane
• 14:32   Re: Migration study, step 2: rewriting queries Tom Lane
• 14:38   Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• 15:08   Re: Problem with LIKE-Performance Dave Dutcher
• 15:16   Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• 15:20   Re: Problem with LIKE-Performance Tom Lane
• 15:33   Re: SELECT FOR UPDATE performance is bad Tom Lane
• 15:35   Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• 15:35   Re: Problem with LIKE-Performance Hakan Kocaman
• 15:38   Re: Problem with LIKE-Performance REISS Thomas DSIC DESP
• 15:44   Re: Problem with LIKE-Performance Guido Neitzer
• 15:44   Re: [bulk] RE: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• 15:45   Re: Problem with LIKE-Performance Tom Lane
• 16:04   Re: [bulk] Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• 16:10   Re: creating of temporary table takes very long Tom Lane
• 16:13   Re: creating of temporary table takes very long Sriram Dandapani
• 16:26   Re: [bulk] Re: Problem with LIKE-Performance Richard Huxton
• 16:39   Re: [bulk] Re: [bulk] Re: Problem with LIKE-Performance Tarabas (Manuel Rorarius)
• 16:59   Re: SELECT FOR UPDATE performance is bad PFC
• 17:19   Re: FOREIGN KEYS vs PERFORMANCE Rodrigo Sakai
• 17:31   Re: Slow query - possible bug? Tom Lane
• 19:08   Re: Slow query - possible bug? Gavin Hamill
• 19:52   Re: Slow query - possible bug? Tom Lane
• 19:56   Re: index is not used if I include a function that returns current time in my query Jim C. Nasby
• 20:01   Re: Blocks read for index scans Jim C. Nasby
• 20:06   Re: Blocks read for index scans Jim C. Nasby
• 20:26   Re: Slow query - possible bug? Gavin Hamill
• 21:04   Re: Inserts optimization? Jim C. Nasby
• 21:10   Re: Inserts optimization? Jim C. Nasby
• 21:34   Re: pg_toast size Jim C. Nasby
• 21:52   Re: merge>hash>loop Jim C. Nasby
• 22:22   Re: merge>hash>loop Tom Lane
• 22:26   Re: merge>hash>loop Tom Lane
• 22:34   Re: creating of temporary table takes very long Jim C. Nasby
• 22:34   Multicolumn order by Theo Kramer
• 22:48   Re: creating of temporary table takes very long Tom Lane
• 23:08   Re: Multicolumn order by Tom Lane
• 23:13   Re: Multicolumn order by Jim C. Nasby
• 23:15   Re: merge>hash>loop Jim C. Nasby
• 23:22   Re: merge>hash>loop Jim C. Nasby
• 23:38   Re: merge>hash>loop Tom Lane

19 April 2006

• 01:02   Planner doesn't chose Index - (slow select) patrick keshishian
• 02:19   Re: Planner doesn't chose Index - (slow select) Tom Lane
• 02:20   Re: SELECT FOR UPDATE performance is bad Christopher Kings-Lynne
• 02:41   Re: Blocks read for index scans Terje Elde
• 04:47   Re: merge>hash>loop Mark Kirkwood
• 05:13   Re: Blocks read for index scans Jim C. Nasby
• 05:18   Re: merge>hash>loop Jim C. Nasby
• 05:25   Re: merge>hash>loop Tom Lane
• 05:31   Re: Blocks read for index scans Mark Kirkwood
• 05:33   Re: merge>hash>loop Mark Kirkwood
• 06:01   Re: Multicolumn order by Theo Kramer
• 08:20   Re: SELECT FOR UPDATE performance is bad Mario Splivalo
• 08:21   Re: SELECT FOR UPDATE performance is bad Mario Splivalo
• 09:26   Re: Multicolumn order by Theo Kramer
• 12:08   Re: Inserts optimization? Markus Schaber
• 12:11   Re: Inserts optimization? Magnus Hagander
• 12:50   Re: Inserts optimization? Markus Schaber
• 15:15   Re: Inserts optimization? Tom Lane
• 15:22   Re: Inserts optimization? Scott Marlowe
• 15:31   Re: Inserts optimization? Tom Lane
• 15:42   Re: Inserts optimization? PFC
• 16:52   Re: Inserts optimization? Scott Marlowe
• 19:28   Re: Planner doesn't chose Index - (slow select) patrick keshishian

20 April 2006

• 01:04   Re: Inserts optimization? Christopher Kings-Lynne
• 01:33   Re: Inserts optimization? Mark Kirkwood
• 05:37   Re: Takes too long to fetch the data from database soni de
• 06:27   Re: Takes too long to fetch the data from database Bruno Wolff III
• 07:24   Perfrmance Problems (7.4.6) Doron Baranes
• 10:48   Re: Perfrmance Problems (7.4.6) Ruben Rubio Rey
• 11:57   Re: Perfrmance Problems (7.4.6) Doron Baranes
• 13:19   Quick Performance Poll Simon Dale
• 13:36   Re: Quick Performance Poll Jim Buttafuoco
• 13:52   Identical query on two machines, different plans.... Mario Splivalo
• 14:00   Re: Identical query on two machines, different plans.... Csaba Nagy
• 14:04   Re: Identical query on two machines, different plans.... Mario Splivalo
• 14:06   Re: Identical query on two machines, different plans.... Csaba Nagy
• 14:16   Re: Inserts optimization? Scott Marlowe
• 14:32   Re: Quick Performance Poll Luke Lonergan
• 14:41   Re: Quick Performance Poll Jim Buttafuoco
• 14:54   Re: Perfrmance Problems (7.4.6) Ruben Rubio Rey
• 15:03   Re: Quick Performance Poll Luke Lonergan
• 15:06   Re: Quick Performance Poll Jim Buttafuoco
• 15:11   Re: Quick Performance Poll Markus Schaber
• 15:16   IBM pSeries - overrated bucket of crud? Gavin Hamill
• 15:17   Re: Quick Performance Poll Luke Lonergan
• 15:21   Performance decrease Radovan Antloga
• 15:41   Re: Performance decrease Tom Lane
• 16:05   Re: Takes too long to fetch the data from database Merlin Moncure
• 16:10   Re: Performance decrease Radovan Antloga
• 16:27   Re: merge>hash>loop Jim C. Nasby
• 16:50   Re: SELECT FOR UPDATE performance is bad Jim C. Nasby
• 16:55   Re: Quick Performance Poll Jim C. Nasby
• 17:00   Re: Performance decrease Jim C. Nasby
• 17:59   Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
• 18:43   Re: Hardware: HP StorageWorks MSA 1500 Mark Lewis
• 19:30   Recovery will take 10 hours Brendan Duddridge
• 19:43   Re: Inserts optimization? Vivek Khera
• 19:45   Re: Inserts optimization? Vivek Khera
• 19:45   Re: Quick Performance Poll Milen Kulev
• 20:17   Re: Recovery will take 10 hours Tom Lane
• 21:13   Re: Recovery will take 10 hours Brendan Duddridge
• 21:19   Re: Performance decrease Guido Neitzer
• 21:20   Re: Recovery will take 10 hours Tom Lane
• 21:21   Re: Recovery will take 10 hours Luke Lonergan
• 21:28   Re: Quick Performance Poll Luke Lonergan
• 21:47   Re: Recovery will take 10 hours Jeff Frost
• 23:11   Re: Recovery will take 10 hours Brendan Duddridge
• 23:15   Re: Recovery will take 10 hours Brendan Duddridge
• 23:20   Re: Recovery will take 10 hours Brendan Duddridge
• 23:20   Re: Recovery will take 10 hours Tom Lane
• 23:27   Re: Recovery will take 10 hours Jeff Frost
• 23:28   Re: Recovery will take 10 hours Brendan Duddridge
• 23:29   Re: Recovery will take 10 hours Tom Lane
• 23:43   Re: Recovery will take 10 hours Brendan Duddridge

21 April 2006

• 00:24   Re: Recovery will take 10 hours Brendan Duddridge
• 01:06   Re: Recovery will take 10 hours Brendan Duddridge
• 01:16   Re: Recovery will take 10 hours Gavin Sherry
• 01:38   Introducing a new linux readahead framework Wu Fengguang
• 04:31   Re: Introducing a new linux readahead framework Jim C. Nasby
• 04:42   Re: Takes too long to fetch the data from database soni de
• 05:22   Re: Quick Performance Poll Milen Kulev
• 07:15   Re: Introducing a new linux readahead framework Wu Fengguang
• 07:53   Re: Introducing a new linux readahead framework Markus Schaber
• 08:54   Better way to write aggregates? Jan Dittmer
• 10:01   Little use of CPU ( < 5%) luchot
• 12:20   Re: Introducing a new linux readahead framework Wu Fengguang
• 12:27   Re: Better way to write aggregates? Jim Buttafuoco
• 12:35   Re: Better way to write aggregates? Jan Dittmer
• 12:39   Re: Better way to write aggregates? Jim Buttafuoco
• 13:26   Re: Takes too long to fetch the data from database Dave Dutcher
• 13:44   Re: Takes too long to fetch the data from database Merlin Moncure
• 13:54   Re: Little use of CPU ( < 5%) Dave Dutcher
• 14:26   Re: Better way to write aggregates? Tom Lane
• 15:25   Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
• 15:55   Inactive memory Grows unlimited ALVARO ARCILA
• 16:38   Re: Inactive memory Grows unlimited Alvaro Herrera
• 17:39   Re: Takes too long to fetch the data from database Bruno Wolff III
• 18:19   Re: Takes too long to fetch the data from database Jim C. Nasby
• 18:34   Re: Introducing a new linux readahead framework Jim C. Nasby
• 21:20   Re: Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
• 23:56   Re: WAL logging of SELECT ... INTO command Bruce Momjian

22 April 2006

• 00:10   Re: WAL logging of SELECT ... INTO command Simon Riggs
• 12:16   Re: Introducing a new linux readahead framework Wu Fengguang

23 April 2006

• 17:05   Re: Recovery will take 10 hours Simon Riggs
• 21:01   GROUP BY Vs. Sub SELECT Bruno Almeida do Lago
• 23:34   Re: GROUP BY Vs. Sub SELECT Tom Lane

24 April 2006

• 02:01   Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood
• 02:49   Slow deletes in 8.1 when FKs are involved Will Reese
• 04:46   Re: Recovery will take 10 hours Brendan Duddridge
• 05:41   Re: Slow deletes in 8.1 when FKs are involved Tom Lane
• 05:55   Re: Inactive memory Grows unlimited Matteo Beccati
• 08:31   Re: Recovery will take 10 hours Markus Schaber
• 18:04   Re: Recovery will take 10 hours Simon Riggs
• 18:14   Re: Slow deletes in 8.1 when FKs are involved Jim C. Nasby
• 18:17   Index on function less well cached than "regular" index ? Paul Mackay
• 18:47   Re: GROUP BY Vs. Sub SELECT Bruno Almeida do Lago
• 19:01   Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
• 19:54   Re: GROUP BY Vs. Sub SELECT Richard Broersma Jr
• 20:55   Re: Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
• 21:05   Re: GROUP BY Vs. Sub SELECT Jim C. Nasby
• 22:12   Re: Index on function less well cached than "regular" index ? Tom Lane
• 22:45   ip address data type Sriram Dandapani
• 22:48   Re: ip address data type Jim C. Nasby
• 23:40   Re: ip address data type Steve Atkins
• 23:57   Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood

25 April 2006

• 05:27   Introducing a new linux readahead framework Wu Fengguang
• 05:27   Slow deletes in 8.1 when FKs are involved Will Reese
• 05:27   security for row level but not based on Database user's login Friends
• 05:27   Worsening performance with 7.4 on flash-based system Greg Stumph
• 05:28   Easy question clemens.bertschler@gmail.com
• 05:28   Re: serious problems with vacuuming databases Tomas Vondra
• 09:40   Re: security for row level but not based on Database user's Richard Huxton
• 10:40   Re: security for row level but not based on Database user's Richard Huxton
• 13:28   Query on postgresql 7.4.2 not using index Arnau
• 13:34   Re: Query on postgresql 7.4.2 not using index chris smith
• 13:49   Re: Query on postgresql 7.4.2 not using index Arnau
• 14:32   Re: Query on postgresql 7.4.2 not using index Guillaume Smet
• 15:05   Re: Query on postgresql 7.4.2 not using index Scott Marlowe
• 15:23   Re: Query on postgresql 7.4.2 not using index Tom Lane
• 15:48   Re: Query on postgresql 7.4.2 not using index Arnau
• 15:54   Re: Query on postgresql 7.4.2 not using index Scott Marlowe
• 15:55   Re: Query on postgresql 7.4.2 not using index Tom Lane
• 16:33   Re: Query on postgresql 7.4.2 not using index Arnau
• 16:45   PL/pgSQL Loop Vs. Batch Update David Wheeler
• 16:56   Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows) andremachado
• 17:08   planner not using index for like operator Sriram Dandapani
• 17:53   Slow queries salad ;) PFC
• 18:03   Re: planner not using index for like operator Dave Dutcher
• 18:14   Large (8M) cache vs. dual-core CPUs Bill Moran
• 18:20   Re: Slow queries salad ;) Tom Lane
• 18:24   Re: planner not using index for like operator Jim C. Nasby
• 18:31   Re: planner not using index for like operator Sriram Dandapani
• 18:33   Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
• 18:35   Re: Large (8M) cache vs. dual-core CPUs Gavin Hamill
• 18:35   Re: Slow queries salad ;) Jim C. Nasby
• 18:37   Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
• 18:37   Re: Large (8M) cache vs. dual-core CPUs mark@mark.mielke.cc
• 18:42   Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
• 18:49   Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
• 18:52   Re: planner not using index for like operator Sriram Dandapani
• 19:12   Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
• 19:22   Re: ip address data type Florian Weimer
• 20:16   Re: Large (8M) cache vs. dual-core CPUs David Boreham
• 21:00   Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
• 21:04   Re: Large (8M) cache vs. dual-core CPUs Bruce Momjian
• 21:10   Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
• 21:16   Re: Large (8M) cache vs. dual-core CPUs David Boreham
• 21:41   slow deletes on pgsql 7.4 Junaili Lie
• 21:43   Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
• 21:46   Re: slow deletes on pgsql 7.4 Junaili Lie
• 22:03   Re: Large (8M) cache vs. dual-core CPUs Joshua D. Drake
• 23:09   Re: slow deletes on pgsql 7.4 Tom Lane
• 23:55   Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby

26 April 2006

• 00:03   Re: Slow deletes in 8.1 when FKs are involved Will Reese
• 00:15   Re: slow deletes on pgsql 7.4 Junaili Lie
• 00:54   Re: Large (8M) cache vs. dual-core CPUs mark@mark.mielke.cc
• 01:04   Re: slow deletes on pgsql 7.4 Tom Lane
• 01:16   Re: Large (8M) cache vs. dual-core CPUs mark@mark.mielke.cc
• 01:20   Re: PL/pgSQL Loop Vs. Batch Update Tom Lane
• 01:39   Re: Query on postgresql 7.4.2 not using index chris smith
• 02:06   Re: Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows) Tom Lane
• 02:26   Re: Large (8M) cache vs. dual-core CPUs Leigh Dyer
• 02:28   Re: PL/pgSQL Loop Vs. Batch Update David Wheeler
• 02:36   Re: PL/pgSQL Loop Vs. Batch Update Tom Lane
• 03:08   Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
• 03:18   Re: PL/pgSQL Loop Vs. Batch Update David Wheeler
• 06:48   Re: Large (8M) cache vs. dual-core CPUs mark@mark.mielke.cc
• 12:41   Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
• 14:02   Re: Large (8M) cache vs. dual-core CPUs David Boreham
• 14:20   Re: Large (8M) cache vs. dual-core CPUs William Yu
• 14:27   Re: slow deletes on pgsql 7.4 Junaili Lie
• 14:43   Re: Large (8M) cache vs. dual-core CPUs David Boreham
• 14:44   Re: Introducing a new linux readahead framework Michael Stone
• 15:11   Re: Large (8M) cache vs. dual-core CPUs Ron Peacetree
• 15:13   Re: Large (8M) cache vs. dual-core CPUs PFC
• 15:18   Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
• 15:24   Re: Large (8M) cache vs. dual-core CPUs William Yu
• 15:27   Re: Large (8M) cache vs. dual-core CPUs Scott Marlowe
• 20:08   Re: Introducing a new linux readahead framework Steve Poe
• 22:09   Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
• 22:15   Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
• 22:16   Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
• 22:17   Re: Large (8M) cache vs. dual-core CPUs Bruce Momjian
• 22:25   Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
• 22:29   Re: Introducing a new linux readahead framework Jim C. Nasby
• 22:37   Re: Large (8M) cache vs. dual-core CPUs Jim C. Nasby
• 23:02   Re: WAL logging of SELECT ... INTO command Bruce Momjian
• 23:34   Re: [Bizgres-general] Introducing a new linux Luke Lonergan
• 23:44   Re: Slow deletes in 8.1 when FKs are involved Stef T
• 23:54   Re: [Bizgres-general] Introducing a new linux Michael Stone

27 April 2006

• 02:07   Running on an NFS Mounted Directory Ketema Harris
• 02:13   Re: Slow deletes in 8.1 when FKs are involved Will Reese
• 02:55   Re: Large (8M) cache vs. dual-core CPUs mark@mark.mielke.cc
• 03:36   Re: Running on an NFS Mounted Directory Steve Wampler
• 04:55   Re: Running on an NFS Mounted Directory Jim C. Nasby
• 05:02   Re: Running on an NFS Mounted Directory Dan Gorman
• 06:59   how unsafe (or worst scenarios) when setting fsync OFF for postgresql Guoping Zhang
• 07:13   Re: how unsafe (or worst scenarios) when setting fsync Simon Riggs
• 07:43   Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Mikael Carneholm
• 09:26   Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Guillaume Smet
• 11:44   Re: Introducing a new linux readahead framework Michael Stone
• 12:32   Firebird 1.5.3 X Postgresql 8.1.3 (linux Firebird 1.5.3 X Postgresql 8.1.3 (linux and and windows)] andremachado
• 12:39   Re: Running on an NFS Mounted Directory Ketema Harris
• 12:45   Re: Running on an NFS Mounted Directory Michael Stone
• 12:58   Re: Running on an NFS Mounted Directory Ketema Harris
• 13:02   Re: Running on an NFS Mounted Directory Bruno Wolff III
• 13:07   Re: Running on an NFS Mounted Directory Ketema Harris
• 13:10   Re: Running on an NFS Mounted Directory Steve Wampler
• 13:25   Re: Running on an NFS Mounted Directory Michael Stone
• 13:30   Re: Running on an NFS Mounted Directory Bruno Wolff III
• 13:41   Re: Running on an NFS Mounted Directory Ketema Harris
• 13:42   Re: Running on an NFS Mounted Directory Ketema Harris
• 14:04   Re: Running on an NFS Mounted Directory Michael Stone
• 14:05   Re: Hardware: HP StorageWorks MSA 1500 Alex Hayward
• 14:53   Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Tom Lane
• 14:58   Re: how unsafe (or worst scenarios) when setting fsync Tom Lane
• 15:11   Re: Large (8M) cache vs. dual-core CPUs Vivek Khera
• 15:19   Re: Large (8M) cache vs. dual-core CPUs Vivek Khera
• 16:13   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
• 17:50   Re: Running on an NFS Mounted Directory Jim C. Nasby
• 17:57   Re: Running on an NFS Mounted Directory Michael Stone
• 18:12   Why so slow? Bealach-na Bo
• 18:27   Re: Why so slow? Andreas Kretschmer
• 18:46   CPU usage goes to 100%, query seems to ran forever Andrus
• 19:00   Re: Running on an NFS Mounted Directory Dan Gorman
• 19:09   Re: CPU usage goes to 100%, query seems to ran forever Tom Lane

28 April 2006

• 02:31   Re: Hardware: HP StorageWorks MSA 1500 Mark Kirkwood
• 04:43   Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Guoping Zhang
• 04:57   Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Tom Lane
• 05:01   Re: how unsafe (or worst scenarios) when setting fsync Guoping Zhang
• 05:06   Re: how unsafe (or worst scenarios) when setting fsync Tom Lane
• 05:18   Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Guoping Zhang
• 05:58   Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Guoping Zhang
• 08:49   Re: Large (8M) cache vs. dual-core CPUs Sven Geisler
• 08:51   Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Mikael Carneholm
• 08:59   Re: how unsafe (or worst scenarios) when setting fsync Markus Schaber
• 09:00   Re: CPU usage goes to 100%, query seems to ran forever Andrus
• 11:31   query performance question gulsah
• 11:41   Re: Why so slow? Bealach-na Bo
• 14:46   Arrays and index scan Markus Schaber
• 14:57   Re: CPU usage goes to 100%, query seems to ran forever Tom Lane
• 14:59   Re: Why so slow? Jim C. Nasby
• 15:03   Re: Why so slow? Alan Hodgson
• 15:35   Re: Arrays and index scan Tom Lane
• 16:19   hardare config question Erik Myllymaki
• 16:20   Re: CPU usage goes to 100%, query seems to ran forever Andrus
• 17:31   Re: Why so slow? Bealach-na Bo
• 17:36   Re: hardare config question Vivek Khera
• 17:37   Re: Why so slow? Bealach-na Bo
• 17:43   Re: Why so slow? Alan Hodgson
• 17:49   Re: hardare config question Mark Lewis
• 18:19   Re: hardare config question Ron Peacetree
• 19:00   Re: Why so slow? Bruno Wolff III

29 April 2006

• 02:22   Re: Why so slow? K C Lau
• 02:39   Re: Why so slow? Tom Lane
• 03:19   Re: Why so slow? K C Lau
• 05:07   Re: hardare config question Luke Lonergan
• 11:29   Re: Why so slow? Michael Stone
• 20:13   Re: Easy question codeWarrior
• 20:13   Re: Hardware: HP StorageWorks MSA 1500 mlartz@gmail.com
• 20:13   Slow restoration question Eric Lam
• 20:13   Re: Easy question Bert
• 20:13   Re: Worsening performance with 7.4 on flash-based system Greg Stumph
• 20:13   Performance Issues on Opteron Dual Core Gregory Stewart
• 20:23   Re: Slow restoration question Tom Lane
• 20:40   Re: Slow restoration question Andreas Kretschmer
• 20:59   Re: Worsening performance with 7.4 on flash-based system William Yu
• 21:53   Re: Easy question Michael Artz
• 23:51   Re: Worsening performance with 7.4 on flash-based system chris smith

30 April 2006

• 10:30   Re: Why so slow? Bealach-na Bo
• 11:00   Re: Performance Issues on Opteron Dual Core Mark Kirkwood
• 14:03   Re: Why so slow? Bill Moran