Mailing lists [pgsql-performance]

1 May 2007

• 13:23   Re: Feature Request --- was: PostgreSQL Performance Tuning Josh Berkus
• 14:36   Re: sytem log audit/reporting and psql Andreas Haumer
• 14:46   Re: index structure for 114-dimension vector Andrew Lazarus
• 17:27   Re: index structure for 114-dimension vector Alexander Staubo
• 20:40   Re: Feature Request --- was: PostgreSQL Performance Tuning Carlos Moreno
• 20:49   Re: Feature Request --- was: PostgreSQL Performance Tuning david@lang.hm
• 22:52   Re: Feature Request --- was: PostgreSQL Performance Tuning Greg Smith
• 23:59   Re: Feature Request --- was: PostgreSQL Performance Tuning Greg Smith

2 May 2007

• 01:34   Re: Feature Request --- was: PostgreSQL Performance Tuning david@lang.hm
• 12:56   Intermitent slow queries Parks, Aaron B.
• 15:18   Re: Intermitent slow queries Dave Cramer
• 15:55   Re: Intermitent slow queries Ron
• 16:00   Re: Intermitent slow queries Steinar H. Gunderson
• 16:04   Re: Intermitent slow queries Parks, Aaron B.
• 16:07   Re: Intermitent slow queries Parks, Aaron B.

3 May 2007

• 03:14   Join vs Subquery Brian Herlihy
• 06:18   Re: Intermitent slow queries Ron
• 08:46   Re: Join vs Subquery Gregory Stark
• 11:23   Re: Join vs Subquery Tom Lane
• 11:45   pg_stat_* collection Greg Smith
• 11:53   Re: pg_stat_* collection Alexander Staubo
• 12:02   Re: Query performance problems with partitioned tables Fei Liu
• 12:03   Re: pg_stat_* collection Magnus Hagander
• 13:35   Re: pg_stat_* collection Tobias Brox
• 15:21   Re: pg_stat_* collection Jeff Davis
• 16:15   Re: Feature Request --- was: PostgreSQL Performance Tuning Ron
• 16:21   Re: Feature Request --- was: PostgreSQL Performance Tuning Josh Berkus
• 16:42   Re: Feature Request --- was: PostgreSQL Performance Tunin g Dave Page
• 17:17   Re: Feature Request --- was: PostgreSQL Performance Tuning david@lang.hm
• 18:06   Re: Feature Request --- was: PostgreSQL Performance Tuning Carlos Moreno
• 18:24   Re: Feature Request --- was: PostgreSQL Performance Tuning david@lang.hm
• 19:41   Re: Feature Request --- was: PostgreSQL Performance Tuning Carlos Moreno
• 19:50   Re: Feature Request --- was: PostgreSQL Performance Tuning david@lang.hm
• 21:22   Re: Feature Request --- was: PostgreSQL Performance Tuning Carlos Moreno
• 21:53   Re: Feature Request --- was: PostgreSQL Performance Tuning david@lang.hm
• 22:12   Re: Feature Request --- was: PostgreSQL Performance Tuning Carlos Moreno
• 22:53   Re: Feature Request --- was: PostgreSQL Performance Tuning david@lang.hm
• 23:38   Re: Query performance problems with partitioned tables Merlin Moncure

4 May 2007

• 01:33   Re: Feature Request --- was: PostgreSQL Performance Tuning Greg Smith
• 01:53   Re: pg_stat_* collection Greg Smith
• 02:10   Re: pg_stat_* collection Tobias Brox
• 09:46   Re: Feature Request --- was: PostgreSQL Performance Tuning Michael Stone
• 09:48   Re: pg_stat_* collection Michael Stone
• 12:05   Index not being used in sorting of simple table Paul Smith
• 12:11   Re: Query performance problems with partitioned tables Scott Marlowe
• 12:26   Re: Index not being used in sorting of simple table Heikki Linnakangas
• 12:43   Re: Index not being used in sorting of simple table Tom Lane
• 13:20   Re: Index not being used in sorting of simple table Paul Smith
• 14:01   Re: Feature Request --- was: PostgreSQL Performance Tuning Sebastian Hennebrueder
• 14:10   Re: Query performance problems with partitioned tables Merlin Moncure
• 14:11   Re: Feature Request --- was: PostgreSQL Performance Tuning Josh Berkus
• 14:22   Re: Feature Request --- was: PostgreSQL Performance Tuning Sebastian Hennebrueder
• 22:07   Re: Feature Request --- was: PostgreSQL Performance Tuning Greg Smith

5 May 2007

• 04:19   Re: Feature Request --- was: PostgreSQL Performance Tuning Mark Kirkwood
• 06:31   Re: Feature Request --- was: PostgreSQL Performance Tuning Steinar H. Gunderson
• 12:54   Re: Feature Request --- was: PostgreSQL Performance Tuning Sebastian Hennebrueder
• 19:57   How to Find Cause of Long Vacuum Times - NOOB Question Yudhvir Singh Sidhu
• 20:40   Re: How to Find Cause of Long Vacuum Times - NOOB Question Steinar H. Gunderson

6 May 2007

• 01:53   Re: How to Find Cause of Long Vacuum Times - NOOB Question Yudhvir Singh Sidhu
• 02:38   Re: Feature Request --- was: PostgreSQL Performance Tuning Jim Nasby
• 04:07   Re: Feature Request --- was: PostgreSQL Performance Tuning Andreas Kostyrka
• 05:15   Re: How to Find Cause of Long Vacuum Times - NOOB Question Heikki Linnakangas
• 06:17   Re: How to Find Cause of Long Vacuum Times - NOOB Question Steinar H. Gunderson
• 06:35   Re: How to Find Cause of Long Vacuum Times - NOOB Question Yudhvir Singh Sidhu
• 13:33   Re: Index not being used in sorting of simple table Robins
• 21:36   Re: Index not being used in sorting of simple table Tom Lane

7 May 2007

• 10:38   Merging large volumes of data Ambrus Wagner (IJ/ETH)
• 10:45   Re: Merging large volumes of data Andreas Kostyrka
• 11:24   Re: Merging large volumes of data Gregory Stark
• 12:09   Re: Merging large volumes of data Tom Lane
• 12:54   Re: How to Find Cause of Long Vacuum Times - NOOB Question Jim Nasby
• 18:55   Best OS for Postgres 8.2 David Levy
• 18:59   Re: Best OS for Postgres 8.2 Joshua D. Drake
• 19:04   Re: Best OS for Postgres 8.2 Bill Moran
• 19:14   Re: Best OS for Postgres 8.2 Joshua D. Drake
• 19:57   Re: Best OS for Postgres 8.2 Steve Atkins
• 21:39   Re: Best OS for Postgres 8.2 Chris
• 21:55   Re: Best OS for Postgres 8.2 david@lang.hm
• 22:14   Re: Best OS for Postgres 8.2 Chris

8 May 2007

• 00:41   Re: Best OS for Postgres 8.2 Ron
• 00:56   Re: Best OS for Postgres 8.2 Greg Smith
• 01:10   Re: How to Find Cause of Long Vacuum Times - NOOB Question Yudhvir Singh Sidhu
• 01:37   Re: Best OS for Postgres 8.2 Tom Lane
• 01:41   Re: Best OS for Postgres 8.2 李彦 Ian Li
• 05:01   Re: Best OS for Postgres 8.2 david@lang.hm
• 05:09   Re: Best OS for Postgres 8.2 Claus Guttesen
• 05:22   Re: Best OS for Postgres 8.2 Heikki Linnakangas
• 05:22   Re: Best OS for Postgres 8.2 Claus Guttesen
• 05:48   Re: Best OS for Postgres 8.2 david@lang.hm
• 06:21   Re: Best OS for Postgres 8.2 Trygve Laugstøl
• 06:35   Re: Best OS for Postgres 8.2 Steinar H. Gunderson
• 06:43   truncate a table instead of vaccum full when count(*) is 0 Pomarede Nicolas
• 06:43   Re: Best OS for Postgres 8.2 Alexander Staubo
• 06:48   Re: Best OS for Postgres 8.2 Steinar H. Gunderson
• 07:02   Re: truncate a table instead of vaccum full when count(*) is 0 Guillaume Cottenceau
• 07:08   Re: truncate a table instead of vaccum full when count(*) is 0 Heikki Linnakangas
• 07:09   Re: truncate a table instead of vaccum full when count(*) is 0 Pomarede Nicolas
• 07:13   Re: truncate a table instead of vaccum full when count(*) is 0 Pomarede Nicolas
• 07:18   Re: Best OS for Postgres 8.2 david@lang.hm
• 07:22   Re: truncate a table instead of vaccum full when count(*) is 0 Gregory Stark
• 07:24   Re: truncate a table instead of vaccum full when count(*) is 0 Pomarede Nicolas
• 07:28   Re: truncate a table instead of vaccum full when count(*) is 0 ismo.tuononen@solenovo.fi
• 07:29   Re: Best OS for Postgres 8.2 david@lang.hm
• 07:37   Re: truncate a table instead of vaccum full when count(*) is 0 Heikki Linnakangas
• 07:40   Re: Best OS for Postgres 8.2 Trygve Laugstøl
• 07:51   Re: truncate a table instead of vaccum full when count(*) is 0 Gregory Stark
• 07:52   Re: truncate a table instead of vaccum full when count(*) is 0 Pomarede Nicolas
• 08:00   Re: truncate a table instead of vaccum full when count(*) is 0 Heikki Linnakangas
• 08:02   Re: [OT] Best OS for Postgres 8.2 C. Bergström
• 08:06   Re: truncate a table instead of vaccum full when count(*) is 0 Guillaume Cottenceau
• 08:19   Re: truncate a table instead of vaccum full when count(*) is 0 Heikki Linnakangas
• 09:02   Re: Best OS for Postgres 8.2 Luke Lonergan
• 09:08   estimating the need for VACUUM FULL and REINDEX Guillaume Cottenceau
• 09:26   Re: [OT] Best OS for Postgres 8.2 Adam Tauno Williams
• 09:40   Re: estimating the need for VACUUM FULL and REINDEX Heikki Linnakangas
• 09:46   Re: estimating the need for VACUUM FULL and REINDEX Bill Moran
• 10:49   Re: [PERFORM] specific query (not all) on Pg8 MUCH slower than Pg7 Steinar H. Gunderson
• 11:38   specific query (not all) on Pg8 MUCH slower than Pg7 Susan Russo
• 11:48   Re: specific query (not all) on Pg8 MUCH slower than Pg7 Tom Lane
• 11:48   Re: specific query (not all) on Pg8 MUCH slower than Pg7 Steinar H. Gunderson
• 11:54   Re: specific query (not all) on Pg8 MUCH slower than Pg7 Richard Broersma Jr
• 11:59   Re: specific query (not all) on Pg8 MUCH slower than Pg7 Alexander Staubo
• 12:04   Re: specific query (not all) on Pg8 MUCH slower than Pg7 Bill Moran
• 12:05   Re: specific query (not all) on Pg8 MUCH slower than Pg7 Tom Lane
• 12:22   Nested loops overpriced Peter Eisentraut
• 12:24   Re: specific query (not all) on Pg8 MUCH slower than Pg7 Susan Russo
• 12:34   Re: specific query (not all) on Pg8 MUCH slower than Pg7 Alvaro Herrera
• 12:53   Re: Nested loops overpriced Tom Lane
• 13:08   Re: Best OS for Postgres 8.2 Ron
• 13:09   Re: specific query (not all) on Pg8 MUCH slower than Pg7 Tom Lane
• 13:58   Re: Best OS for Postgres 8.2 李彦 Ian Li
• 14:31   Re: truncate a table instead of vaccum full when count(*) is 0 Pomarede Nicolas
• 15:41   Re: Query performance problems with partitioned tables Fei Liu
• 15:58   Re: Query performance problems with partitioned tables Scott Marlowe
• 16:52   DISTINCT Question Y Sidhu
• 16:55   Re: DISTINCT Question Steinar H. Gunderson
• 16:57   Re: DISTINCT Question Joshua D. Drake
• 17:28   Re: DISTINCT Question Scott Marlowe
• 17:45   Throttling PostgreSQL's CPU usage Daniel Griscom
• 17:50   Re: Best OS for Postgres 8.2 Charles Sprickman
• 17:51   Re: Throttling PostgreSQL's CPU usage Steinar H. Gunderson
• 17:56   Re: Throttling PostgreSQL's CPU usage Bill Moran
• 18:01   Re: Throttling PostgreSQL's CPU usage david@lang.hm
• 18:10   Re: Throttling PostgreSQL's CPU usage Mark Lewis
• 18:43   What's The Difference Between VACUUM and VACUUM ANALYZE? Y Sidhu
• 18:48   Re: [PERFORM] specific query (not all) on Pg8 MUCH slower than Pg7 Steinar H. Gunderson
• 18:48   Re: [PERFORM] specific query (not all) on Pg8 MUCH slower than Pg7 Steinar H. Gunderson
• 18:48   Re: What's The Difference Between VACUUM and VACUUM ANALYZE? david@lang.hm
• 18:52   Re: What's The Difference Between VACUUM and VACUUM ANALYZE? Alvaro Herrera
• 19:06   Re: What's The Difference Between VACUUM and VACUUM ANALYZE? Steinar H. Gunderson
• 19:21   Re: What's The Difference Between VACUUM and VACUUM ANALYZE? Alvaro Herrera
• 19:31   Re: Throttling PostgreSQL's CPU usage Carlos Moreno
• 19:39   Re: Throttling PostgreSQL's CPU usage Joshua D. Drake
• 19:40   Re: Throttling PostgreSQL's CPU usage Steinar H. Gunderson
• 19:45   Re: Throttling PostgreSQL's CPU usage Carlos Moreno
• 20:03   Re: Throttling PostgreSQL's CPU usage Daniel Griscom
• 20:10   Re: Throttling PostgreSQL's CPU usage Steinar H. Gunderson
• 20:21   Re: Throttling PostgreSQL's CPU usage Carlos Moreno
• 20:23   Re: Throttling PostgreSQL's CPU usage david@lang.hm
• 20:26   Re: Throttling PostgreSQL's CPU usage david@lang.hm
• 20:31    Orhan Aglagul
• 20:49   Re: Dan Harris
• 21:05   Re: Joshua D. Drake
• 21:19   Re: Carlos Moreno
• 21:22   Re: Scott Marlowe
• 21:30   Re: Scott Marlowe
• 22:12   Re: Orhan Aglagul
• 22:13   FW: Orhan Aglagul
• 22:14   FW: Orhan Aglagul
• 22:14   FW: Orhan Aglagul
• 22:25   Re: FW: david@lang.hm

9 May 2007

• 00:31   Re: Best OS for Postgres 8.2 Greg Smith
• 00:51   Re: Best OS for Postgres 8.2 Greg Smith
• 01:10   Re: Throttling PostgreSQL's CPU usage Luke Lonergan
• 01:14   Re: Greg Smith
• 01:58   Re: Robert Treat
• 02:57   Re: Throttling PostgreSQL's CPU usage Magnus Hagander
• 06:00   Re: Best OS for Postgres 8.2 david@lang.hm
• 06:18   Re: estimating the need for VACUUM FULL and REINDEX Guillaume Cottenceau
• 06:38   Re: Best OS for Postgres 8.2 Steinar H. Gunderson
• 06:46   Re: Best OS for Postgres 8.2 david@lang.hm
• 08:31   Re: What's The Difference Between VACUUM and VACUUM ANALYZE? Gregory Stark
• 08:36   Re: FW: Gregory Stark
• 08:58   Re: Nested loops overpriced Peter Eisentraut
• 09:11   Apparently useless bitmap scans Peter Eisentraut
• 10:13   Cannot make GIN intarray index be used by the planner Valentine Gogichashvili
• 10:29   Poor performance with queries using clause: sth IN (...) Andrzej Zawadzki
• 10:32   Re: Cannot make GIN intarray index be used by the planner Oleg Bartunov
• 10:36   Re: Cannot make GIN intarray index be used by the planner Valentine Gogichashvili
• 10:39   Re: Nested loops overpriced Daniel Cristian Cruz
• 10:49   Re: Throttling PostgreSQL's CPU usage Daniel Griscom
• 10:49   Re: Cannot make GIN intarray index be used by the planner Oleg Bartunov
• 11:11   Re: Nested loops overpriced Tom Lane
• 11:28   Re: Throttling PostgreSQL's CPU usage Carlos Moreno
• 11:29   Re: Apparently useless bitmap scans Alvaro Herrera
• 11:30   Re: Poor performance with queries using clause: sth IN (...) Gregory Stark
• 11:34   Re: Nested loops overpriced Gregory Stark
• 11:49   Re: Apparently useless bitmap scans Tom Lane
• 11:52   Re: Nested loops overpriced Daniel Cristian Cruz
• 12:26   Re: Apparently useless bitmap scans Peter Eisentraut
• 12:56   Re: Apparently useless bitmap scans Tom Lane
• 13:17   Re: Nested loops overpriced Peter Eisentraut
• 13:27   ZFS and Postgresql - WASRe: Best OS for Postgres 8.2 Jignesh Shah
• 14:01   Re: ZFS and Postgresql - WASRe: Best OS for Postgres 8.2 Alvaro Herrera
• 14:10   Re: Best OS for Postgres 8.2 Jim Nasby
• 14:14   Re: How to Find Cause of Long Vacuum Times - NOOB Question Jim Nasby
• 14:40   Re: Nested loops overpriced Tom Lane
• 14:49   Re: ZFS and Postgresql - WASRe: Best OS for Postgres 8.2 Jignesh Shah
• 14:58   Re: ZFS and Postgresql - WASRe: Best OS for Postgres 8.2 david@lang.hm
• 15:41   Re: Cannot make GIN intarray index be used by the planner Valentine Gogichashvili
• 16:18   Re: Cannot make GIN intarray index be used by the planner Tom Lane
• 19:00   Vacuum Times - Verbose and maintenance_work_mem Y Sidhu
• 20:56   Performance Woes Ralph Mason
• 21:26   Re: Performance Woes CAJ CAJ
• 21:29   Re: Performance Woes Joshua D. Drake
• 21:35   Re: Performance Woes Ralph Mason
• 21:39   Re: Performance Woes Joshua D. Drake
• 21:42   Re: Performance Woes Jeff Davis
• 22:45   Re: Performance Woes Ralph Mason
• 22:50   Re: Performance Woes Scott Mohekey
• 23:05   Re: Performance Woes Alvaro Herrera

10 May 2007

• 01:30   Re: Performance Woes Tom Lane
• 01:58   Background vacuum Daniel Haensse
• 02:25   Re: Background vacuum Dan Harris
• 06:07   Re: Cannot make GIN intarray index be used by the planner Valentine Gogichashvili
• 09:47   Re: [PERFORM] REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Bill Moran
• 10:23   REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Susan Russo
• 10:38   Re: REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Steinar H. Gunderson
• 10:47   Re: REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Bill Moran
• 11:08   Re: REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Susan Russo
• 12:30   Re: Nested loops overpriced Peter Eisentraut
• 12:35   Re: Nested loops overpriced Peter Eisentraut
• 12:47   Re: Nested loops overpriced Tom Lane
• 17:47   Re: [PERFORM] REVISIT specific query (not all) on Pg8 MUCH slowerthan Pg7 Bill Moran
• 17:47   Re: [PERFORM] REVISIT specific query (not all) on Pg8 MUCH slowerthan Pg7 Bill Moran
• 21:11   Re: Background vacuum Ron Mayer
• 23:05   Re: REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Susan Russo

11 May 2007

• 10:35   Re: Best OS for Postgres 8.2 Adam Witney
• 12:31   Re: estimating the need for VACUUM FULL and REINDEX Guillaume Cottenceau
• 14:25   Re: estimating the need for VACUUM FULL and REINDEX Alvaro Herrera
• 16:11   Re: BUG #3270: limit < 16 optimizer behaviour Bruno Wolff III

12 May 2007

• 00:13   Re: Best OS for Postgres 8.2 Robert Treat
• 04:15   500 requests per second Tarhon-Onu Victor
• 08:41   Kernel cache vs shared_buffers Michael van Rooyen
• 11:29   Re: Kernel cache vs shared_buffers Heikki Linnakangas
• 13:51   Re: estimating the need for VACUUM FULL and REINDEX Jim C. Nasby
• 13:55   Re: Kernel cache vs shared_buffers Jim C. Nasby

13 May 2007

• 03:34   Re: Best OS for Postgres 8.2 Andrew McMillan
• 05:39   Re: Kernel cache vs shared_buffers Harald Armin Massa
• 06:41   Re: Kernel cache vs shared_buffers Heikki Linnakangas
• 06:57   Re: Kernel cache vs shared_buffers Harald Armin Massa
• 07:38   Re: Kernel cache vs shared_buffers Magnus Hagander
• 21:43   pg_stats how-to? Yudhvir Singh Sidhu
• 22:45   Re: pg_stats how-to? Adam Tauno Williams

14 May 2007

• 06:08   Re: 500 requests per second Richard Huxton
• 13:17   Re: pg_stats how-to? Y Sidhu
• 13:26   Re: pg_stats how-to? Jim C. Nasby
• 14:21   Re: Transaction prioritization from java possible? Josh Berkus
• 14:49   Re: pg_stats how-to? Jim C. Nasby
• 15:09   Re: pg_stats how-to? Y Sidhu
• 15:36   Re: pg_stats how-to? Jim C. Nasby
• 16:08   Re: pg_stats how-to? Y Sidhu
• 16:14   Re: pg_stats how-to? Jim C. Nasby
• 17:53   Re: pg_stats how-to? Y Sidhu
• 18:11   Re: pg_stats how-to? Bill Moran
• 19:16   Re: pg_stats how-to? Y Sidhu
• 21:20   Re: pg_stats how-to? Tom Lane

15 May 2007

• 06:17   Re: 500 requests per second Tarhon-Onu Victor
• 07:49   Re: 500 requests per second Richard Huxton
• 10:58   Many to many join seems slow? Drew Wilson
• 11:05   Re: Many to many join seems slow? Alvaro Herrera
• 11:11   Re: Many to many join seems slow? Drew Wilson
• 11:17   Re: Many to many join seems slow? Heikki Linnakangas
• 12:16   bitmap index and IS NULL predicate Jason Pinnix
• 12:22   Re: bitmap index and IS NULL predicate Alexander Staubo
• 13:00   Re: Many to many join seems slow? Daniel Cristian Cruz
• 13:44   [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Guillaume Cottenceau
• 13:44   Re: Many to many join seems slow? Drew Wilson
• 13:45   Re: Many to many join seems slow? Drew Wilson
• 14:45   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Michael Stone
• 17:18   Disk Fills Up and fsck "Compresses" it Y Sidhu
• 19:42   How to Run a pg_stats Query Y Sidhu
• 19:50   Re: How to Run a pg_stats Query Alvaro Herrera
• 20:28   Re: 500 requests per second Jim C. Nasby
• 20:39   Re: pg_stats how-to? Jim C. Nasby
• 20:42   Re: Disk Fills Up and fsck "Compresses" it Jim C. Nasby

16 May 2007

• 00:02   Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages Greg Smith
• 00:55   New performance documentation released Greg Smith
• 04:41   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Guillaume Cottenceau
• 12:21   Re: Disk Fills Up and fsck "Compresses" it Y Sidhu
• 12:38   Re: New performance documentation released Luke Lonergan
• 12:48   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Jim C. Nasby
• 12:51   Re: Disk Fills Up and fsck "Compresses" it Jim C. Nasby
• 13:00   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Guillaume Cottenceau
• 13:09   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Alvaro Herrera
• 13:17   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Jim C. Nasby
• 13:22   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Michael Stone
• 17:04   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Chris Browne
• 18:18   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Michael Stone
• 18:25   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Alvaro Herrera
• 18:31   Re: [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal Tom Lane
• 20:29   Re: Disk Fills Up and fsck "Compresses" it Mark Kirkwood

17 May 2007

• 10:55   Re: Background vacuum Andrew Sullivan
• 11:04   WAL log performance/efficiency question Keaton Adams
• 11:23   Re: WAL log performance/efficiency question Heikki Linnakangas
• 11:56   Re: WAL log performance/efficiency question Tom Lane
• 12:34   Re: WAL log performance/efficiency question Keaton Adams
• 12:52   Re: WAL log performance/efficiency question Heikki Linnakangas
• 13:01   Re: WAL log performance/efficiency question Keaton Adams
• 19:45   Ever Increasing IOWAIT Ralph Mason
• 20:02   Re: Ever Increasing IOWAIT Joshua D. Drake
• 20:19   Re: Ever Increasing IOWAIT Ralph Mason
• 22:44   Re: Background vacuum Ron Mayer
• 23:50   Re: Background vacuum Greg Smith

18 May 2007

• 00:09   Re: Background vacuum Ron Mayer
• 00:22   Re: Background vacuum Tom Lane
• 06:12   Re: Ever Increasing IOWAIT Richard Huxton
• 06:21   performance drop on 8.2.4, reverting to 8.1.4 Liviu Ionescu
• 07:11   Re: performance drop on 8.2.4, reverting to 8.1.4 Steinar H. Gunderson
• 07:15   Re: performance drop on 8.2.4, reverting to 8.1.4 Liviu Ionescu
• 07:46   Re: performance drop on 8.2.4, reverting to 8.1.4 Steinar H. Gunderson
• 08:06   Re: performance drop on 8.2.4, reverting to 8.1.4 Liviu Ionescu
• 08:15   Re: performance drop on 8.2.4, reverting to 8.1.4 Steinar H. Gunderson
• 08:52   Re: performance drop on 8.2.4, reverting to 8.1.4 Liviu Ionescu
• 10:10   Re: performance drop on 8.2.4, reverting to 8.1.4 Steinar H. Gunderson
• 10:34   Re: performance drop on 8.2.4, reverting to 8.1.4 Liviu Ionescu
• 10:58   Re: Ever Increasing IOWAIT Mark Lewis
• 12:13   Re: performance drop on 8.2.4, reverting to 8.1.4 George Pavlov
• 12:41   Re: performance drop on 8.2.4, reverting to 8.1.4 Liviu Ionescu
• 12:55   Re: performance drop on 8.2.4, reverting to 8.1.4 Tom Lane
• 13:03   CPU Intensive query Abu Mushayeed
• 13:42   Re: CPU Intensive query Steinar H. Gunderson
• 13:50   Re: performance drop on 8.2.4, reverting to 8.1.4 Liviu Ionescu
• 14:35   reading large BYTEA type is slower than expected Mark Harris
• 14:48   Re: reading large BYTEA type is slower than expected Tom Lane
• 14:50   Re: reading large BYTEA type is slower than expected Y Sidhu
• 15:15   121+ million record table perf problems cyber-postgres@midnightfantasy.com
• 15:30   Re: 121+ million record table perf problems Andrew Sullivan
• 15:50   Re: 121+ million record table perf problems Joshua D. Drake
• 15:52   Re: reading large BYTEA type is slower than expected Mark Harris
• 15:53   Re: 121+ million record table perf problems Brian Hurt
• 15:57   choosing fillfactor Gene Hart
• 16:05   Slow queries on big table Tyrrill, Ed
• 16:08   Re: 121+ million record table perf problems Alan Hodgson
• 16:21   Re: Background vacuum Ron Mayer
• 16:36   Re: Slow queries on big table Scott Marlowe
• 16:37   Re: reading large BYTEA type is slower than expected Mark Harris
• 16:37   Re: 121+ million record table perf problems Tom Lane
• 16:59   Re: Slow queries on big table Tom Lane
• 17:05   Re: Slow queries on big table Andrew Kroeger
• 17:06   Re: Slow queries on big table Tom Lane
• 17:19   Re: choosing fillfactor Heikki Linnakangas
• 18:23   Re: Slow queries on big table Tyrrill, Ed
• 18:28   Re: Slow queries on big table Steinar H. Gunderson
• 18:36   Re: Slow queries on big table Tom Lane
• 18:37   Re: CPU Intensive query Abu Mushayeed
• 18:51   Re: CPU Intensive query Tom Lane
• 19:26   Re: CPU Intensive query Abu Mushayeed
• 19:32   Re: CPU Intensive query Steinar H. Gunderson
• 19:35   Re: CPU Intensive query Steinar H. Gunderson
• 19:39   Re: 121+ million record table perf problems Craig James
• 20:17   Re: Slow queries on big table Tyrrill, Ed
• 20:21   Re: 121+ million record table perf problems Alvaro Herrera
• 20:26   Re: pg_stats how-to? Y Sidhu

19 May 2007

• 02:17   Re: 121+ million record table perf problems Greg Smith
• 02:27   Re: Background vacuum Greg Smith
• 10:21   Re: CPU Intensive query Andrew Sullivan
• 14:33   Re: Diminishing bandwidth performance with multiple quad core X5355s jlmarin
• 14:33   Re: pg_stats how-to? Shoaib Mir
• 14:33   any way to get rid of Bitmap Heap Scan recheck? Sergei Shelukhin
• 14:33   Re: performance drop on 8.2.4, reverting to 8.1.4 Kenneth Marshall
• 14:33   Efficient recursion C Storm
• 14:34   Re: any way to get rid of Bitmap Heap Scan recheck? Sergei Shelukhin
• 15:05   Re: any way to get rid of Bitmap Heap Scan recheck? Heikki Linnakangas
• 15:10   Re: any way to get rid of Bitmap Heap Scan recheck? Tom Lane
• 15:12   Re: Efficient recursion Tom Lane
• 17:51   Re: performance drop on 8.2.4, reverting to 8.1.4 Guido Neitzer
• 19:08   QP Problem s d
• 19:38   Re: Background vacuum Ron Mayer
• 20:20   Re: QP Problem Tom Lane

20 May 2007

• 11:56   Postgres Benchmark Results PFC
• 13:41   Re: Postgres Benchmark Results Arjen van der Meijden
• 14:07   Re: Postgres Benchmark Results PFC
• 14:13   Re: Diminishing bandwidth performance with multiple quad core X5355s Arjen van der Meijden
• 14:26   Re: Postgres Benchmark Results Arjen van der Meijden
• 14:26   Re: Postgres Benchmark Results Tom Lane
• 15:00   Re: Postgres Benchmark Results Zoltan Boszormenyi
• 15:08   Re: Postgres Benchmark Results PFC
• 15:49   Re: Postgres Benchmark Results Andreas Kostyrka
• 17:41   Re: Ever Increasing IOWAIT Ralph Mason
• 17:42   Re: Ever Increasing IOWAIT Ralph Mason
• 18:58   Re: Ever Increasing IOWAIT Tom Lane

21 May 2007

• 01:36   Rewriting DISTINCT and losing performance Chuck D.
• 02:18   Re: Ever Increasing IOWAIT Ralph Mason
• 06:15   Re: Rewriting DISTINCT and losing performance Josh Berkus
• 08:40   Re: Rewriting DISTINCT and losing performance Richard Huxton
• 11:43   Increasing Shared_buffers = slow commits? Chris Hoover
• 12:10   Re: Rewriting DISTINCT and losing performance Chuck D.
• 14:13   Re: Rewriting DISTINCT and losing performance Chuck D.
• 14:24   Re: pg_stats how-to? Jim C. Nasby
• 14:34   Re: Rewriting DISTINCT and losing performance Richard Huxton
• 15:32   Re: Rewriting DISTINCT and losing performance Chuck D.
• 15:40   Re: Increasing Shared_buffers = slow commits? Merlin Moncure
• 16:50   Re: 500 requests per second Merlin Moncure
• 17:19   Re: pg_stats how-to? Y Sidhu
• 17:45   Re: 500 requests per second PFC
• 17:47   Re: 500 requests per second Jim C. Nasby
• 18:01   Re: Postgres Benchmark Results Jim C. Nasby
• 18:05   Re: Postgres Benchmark Results Jim C. Nasby
• 18:24   Re: 121+ million record table perf problems Vivek Khera
• 18:32   Re: Rewriting DISTINCT and losing performance Tom Lane
• 18:33   Re: Postgres Benchmark Results PFC
• 18:37   Re: Postgres Benchmark Results PFC
• 20:45   Re: Postgres Benchmark Results Guido Neitzer
• 21:05   Re: Postgres Benchmark Results Rich
• 21:28   Re: Postgres Benchmark Results Scott Marlowe
• 21:49   Re: Postgres Benchmark Results Alvaro Herrera
• 21:52   Re: 500 requests per second Dave Cramer

22 May 2007

• 02:51   Re: Postgres Benchmark Results Greg Smith
• 03:01   Re: Postgres Benchmark Results Guido Neitzer
• 03:15   Re: Postgres Benchmark Results Zoltan Boszormenyi
• 03:27   Re: Postgres Benchmark Results Zoltan Boszormenyi
• 03:29   Re: Postgres Benchmark Results Peter Schuller
• 04:26   Feature suggestion : FAST CLUSTER PFC
• 05:04   Re: Postgres Benchmark Results Gregory Stark
• 05:17   Re: Postgres Benchmark Results Gregory Stark
• 05:23   Key/Value reference table generation: INSERT/UPDATE performance valgog
• 06:05   Re: Key/Value reference table generation: INSERT/UPDATE performance Peter Childs
• 06:23   Re: Key/Value reference table generation: INSERT/UPDATE performance Richard Huxton
• 06:30   is file size relevant in choosing index or table scan? Joost Kraaijeveld
• 06:42   Re: is file size relevant in choosing index or table scan? Richard Huxton
• 07:01   Re: Key/Value reference table generation: INSERT/UPDATE performance valgog
• 07:07   Re: Postgres Benchmark Results PFC
• 07:12   Re: Key/Value reference table generation: INSERT/UPDATE performance PFC
• 07:35   Re: Key/Value reference table generation: INSERT/UPDATE performance valgog
• 07:38   Re: Key/Value reference table generation: INSERT/UPDATE performance valgog
• 08:08   Performace comparison of indexes over timestamp fields Arnau
• 09:28   Re: Key/Value reference table generation: INSERT/UPDATE performance cedric
• 09:39   Re: Performace comparison of indexes over timestamp fields Alexander Staubo
• 09:43   Re: Performace comparison of indexes over timestamp fields Steinar H. Gunderson
• 10:00   Re: Performace comparison of indexes over timestamp fields Alexander Staubo
• 10:11   Tips & Tricks for validating hardware/os Stephane Bailliez
• 10:45   Re: Tips & Tricks for validating hardware/os Alexander Staubo
• 10:53   Re: Tips & Tricks for validating hardware/os PFC
• 11:11   Re: Performace comparison of indexes over timestamp fields Tom Lane
• 13:56   Domains versus Check Constraints Chander Ganesan
• 15:40   Drop table vs Delete record Orhan Aglagul
• 15:50   Re: Drop table vs Delete record Andreas Kostyrka
• 15:53   Re: Drop table vs Delete record Orhan Aglagul

23 May 2007

• 00:48   Re: Postgres Benchmark Results Greg Smith
• 02:13   Re: Tips & Tricks for validating hardware/os Greg Smith
• 03:33   Re: Tips & Tricks for validating hardware/os Andreas Kostyrka
• 05:04   Re: Key/Value reference table generation: INSERT/UPDATE performance Guillaume Smet
• 05:31   Re: Postgres Benchmark Results Gregory Stark
• 10:01   Re: [PERFORM] does VACUUM ANALYZE complete with this error? Tom Lane
• 10:27   does VACUUM ANALYZE complete with this error? Susan Russo
• 11:01   Re: does VACUUM ANALYZE complete with this error? Tom Lane
• 12:28   LIKE search and performance Andy
• 12:47   Re: performance drop on 8.2.4, reverting to 8.1.4 Vivek Khera
• 12:51   Re: Tips & Tricks for validating hardware/os Vivek Khera
• 12:52   Re: LIKE search and performance Richard Huxton
• 12:57   Re: does VACUUM ANALYZE complete with this error? Vivek Khera
• 13:00   Re: LIKE search and performance Guido Neitzer
• 13:05   Re: LIKE search and performance Alexander Staubo
• 13:18   Re: LIKE search and performance Rigmor Ukuhe
• 13:22   max_fsm_pages, shared_buffers and checkpoint_segments Y Sidhu
• 13:31   Re: max_fsm_pages, shared_buffers and checkpoint_segments Ben
• 13:43   Re: max_fsm_pages, shared_buffers and checkpoint_segments Y Sidhu
• 14:00   Re: max_fsm_pages, shared_buffers and checkpoint_segments Ben
• 14:31   Re: [PERFORM] does VACUUM ANALYZE complete with this error? Tom Lane
• 14:53   Re: max_fsm_pages, shared_buffers and checkpoint_segments PFC
• 15:18   Re: does VACUUM ANALYZE complete with this error? Susan Russo
• 15:31   Re: does VACUUM ANALYZE complete with this error? Tom Lane
• 15:58   Simulate database fragmentation Y Sidhu
• 16:04   Re: does VACUUM ANALYZE complete with this error? Susan Russo
• 17:24   Re: Drop table vs Delete record Chris Mair
• 17:40   Re: max_fsm_pages, shared_buffers and checkpoint_segments Peter Schuller
• 18:01   Re: [PERFORM] does VACUUM ANALYZE complete with this error?  Tom Lane
• 18:01   Re: [PERFORM] does VACUUM ANALYZE complete with this error?  Tom Lane
• 19:38   Re: does VACUUM ANALYZE complete with this error? Scott Marlowe
• 20:46   Auto-ANALYZE? Craig James
• 20:56   Re: Auto-ANALYZE? Tom Lane
• 22:31   Re: [PERFORM] does VACUUM ANALYZE complete with this error?  Tom Lane
• 22:31   Re: [PERFORM] does VACUUM ANALYZE complete with this error?  Tom Lane
• 23:01   Memory allocation and Vacuum abends Leandro Guimarães dos Santos

24 May 2007

• 01:28   Re: max_fsm_pages, shared_buffers and checkpoint_segments Heikki Linnakangas
• 04:01   Re: LIKE search and performance Andy
• 16:15   Re: LIKE search and performance James Mansion
• 16:23   Re: LIKE search and performance Magnus Hagander
• 17:51   Re: LIKE search and performance James Mansion
• 18:04   Re: LIKE search and performance Mark Lewis
• 18:22   Re: LIKE search and performance Craig James
• 18:47   Re: LIKE search and performance Alvaro Herrera
• 18:55   Re: LIKE search and performance mark@mark.mielke.cc
• 19:07   Re: LIKE search and performance Craig James
• 19:07   Re: LIKE search and performance PFC

25 May 2007

• 05:18   Re: LIKE search and performance Richard Huxton
• 05:51   general PG network slowness (possible cure) (repost) Peter T. Breuer
• 05:52   Performance Problem with Vacuum of bytea table (PG 8.0.13) Bastian Voigt
• 05:52   How PostgreSQL handles multiple DDBB instances? Arnau
• 06:25   Big problem with sql update operation Michal Szymanski
• 07:31   Re: general PG network slowness (possible cure) (repost) Richard Huxton
• 07:33   Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Richard Huxton
• 07:48   Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Bastian Voigt
• 08:00   Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Richard Huxton
• 08:10   Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Bastian Voigt
• 08:51   Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Richard Huxton
• 09:30   My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Bastian Voigt
• 10:03   Re: general PG network slowness (possible cure) (repost) Steinar H. Gunderson
• 10:16   Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Richard Huxton
• 10:18   Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Kristo Kaiv
• 10:23   Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
• 10:44   Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
• 10:52   Re: general PG network slowness (possible cure) (repost) Richard Huxton
• 10:57   Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Alvaro Herrera
• 11:02   Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
• 11:06   Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Bastian Voigt
• 11:07   Re: general PG network slowness (possible cure) (repost) Tom Lane
• 11:09   Re: general PG network slowness (possible cure) (repost) Richard Huxton
• 11:10   Re: general PG network slowness (possible cure) (repost) Alvaro Herrera
• 11:11   Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) Bastian Voigt
• 11:16   Re: LIKE search and performance mark@mark.mielke.cc
• 11:19   Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Tom Lane
• 11:24   Re: How PostgreSQL handles multiple DDBB instances? Tom Lane
• 11:28   Re: Big problem with sql update operation Tom Lane
• 12:06   Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
• 12:20   Re: general PG network slowness (possible cure) (repost) Tom Lane
• 12:21   Re: My quick and dirty "solution" (Re: Performance P roblem with Vacuum of bytea table (PG 8.0.13)) Andreas Kostyrka
• 12:35   Re: LIKE search and performance Richard Huxton
• 12:45   Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
• 13:16   Re: general PG network slowness (possible cure) (repost) Tom Lane
• 13:34   Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
• 13:49   Re: LIKE search and performance PFC
• 13:56   Re: LIKE search and performance mark@mark.mielke.cc
• 14:08   Re: LIKE search and performance Joshua D. Drake
• 14:14   Re: LIKE search and performance Richard Huxton
• 14:16   Re: How PostgreSQL handles multiple DDBB instances? Arnau
• 14:30   Re: LIKE search and performance PFC
• 14:31   Re: LIKE search and performance Richard Huxton
• 14:32   Re: LIKE search and performance Richard Huxton
• 14:58   Re: LIKE search and performance Gregory Stark
• 15:04   Re: How PostgreSQL handles multiple DDBB instances? Tom Lane
• 15:15   Re: LIKE search and performance Richard Huxton
• 15:17   Re: How PostgreSQL handles multiple DDBB instances? Arnau
• 15:34   Re: How PostgreSQL handles multiple DDBB instances? Tom Lane
• 15:36   Performance problem on 8.2.4, but not 8.2.3 Dave Pirotte
• 15:58   Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
• 16:18   Re: Performance problem on 8.2.4, but not 8.2.3 Kristo Kaiv
• 16:56   Re: Performance problem on 8.2.4, but not 8.2.3 Tom Lane
• 17:05   Re: Performance problem on 8.2.4, but not 8.2.3 Steinar H. Gunderson
• 17:34   Re: Performance problem on 8.2.4, but not 8.2.3 Tom Lane
• 18:38   Re: Performance problem on 8.2.4, but not 8.2.3 Dave Pirotte
• 18:48   Adding disks/xlog & index lists@on-track.ca
• 19:24   Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
• 19:27   Re: Big problem with sql update operation Michal Szymanski
• 19:38   Re: Big problem with sql update operation Alvaro Herrera
• 20:47   Re: Adding disks/xlog & index Tom Lane
• 20:47   Re: Adding disks/xlog & index Tom Lane
• 21:20   Re: general PG network slowness (possible cure) (repost) Tom Lane
• 21:36   Re: Adding disks/xlog & index Gregory Stark
• 22:44   ECC RAM really needed? Craig James
• 23:15   Re: ECC RAM really needed? Bruno Wolff III

26 May 2007

• 01:02   Re: ECC RAM really needed? Greg Smith
• 01:19   Re: ECC RAM really needed? Tom Lane
• 04:07   Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
• 09:41   Re: Performance problem on 8.2.4, but not 8.2.3 Kristo Kaiv
• 09:43   Re: ECC RAM really needed? Michael Stone
• 11:52   Re: ECC RAM really needed? mark@mark.mielke.cc
• 13:46   Re: general PG network slowness (possible cure) (repost) Tom Lane

27 May 2007

• 11:27   Re: ECC RAM really needed? Andrew Sullivan
• 12:53   Re: Feature suggestion : FAST CLUSTER Jim C. Nasby
• 12:59   Re: Domains versus Check Constraints Jim C. Nasby
• 13:05   Re: Simulate database fragmentation Jim C. Nasby
• 13:06   Re: Memory allocation and Vacuum abends Jim C. Nasby
• 13:08   Re: Performance Problem with Vacuum of bytea table (PG 8.0.13) Jim C. Nasby
• 13:34   Re: Domains versus Check Constraints Stefan Kaltenbrunner
• 14:31   Re: Feature suggestion : FAST CLUSTER PFC
• 15:27   Re: Feature suggestion : FAST CLUSTER Alexander Staubo
• 15:42   Re: Feature suggestion : FAST CLUSTER PFC

28 May 2007

• 00:52   Re: Postgres Benchmark Results Chris
• 03:39   Re: Postgres Benchmark Results PFC
• 09:45   PITR performance costs Dave Cramer
• 09:53   Re: PITR performance costs Bill Moran
• 09:54   Re: PITR performance costs A. Kretschmer
• 13:32   Re: PITR performance costs Heikki Linnakangas
• 15:49   Re: PITR performance costs Dave Cramer
• 16:46   Re: PITR performance costs Stephen Frost
• 17:43   Re: PITR performance costs Simon Riggs
• 18:14   Re: general PG network slowness (possible cure) (repost) Bruce Momjian

29 May 2007

• 03:21   Re: Feature suggestion : FAST CLUSTER PFC
• 04:57   Re: Feature suggestion : FAST CLUSTER Jim Nasby
• 05:41   Re: Feature suggestion : FAST CLUSTER PFC
• 10:07   Re: PITR performance costs Merlin Moncure
• 10:19   Re: general PG network slowness (possible cure) (repost) Merlin Moncure
• 14:04   Vacuum takes forever Joost Kraaijeveld
• 14:14   Re: Vacuum takes forever PFC
• 14:56   Re: Vacuum takes forever Joost Kraaijeveld
• 17:41   Re: Big problem with sql update operation Alvaro Herrera
• 17:43   Re: Vacuum takes forever Dave Page
• 17:48   Re: Vacuum takes forever Joshua D. Drake
• 18:22   setting up raid10 with more than 4 drives Rajesh Kumar Mallah
• 18:57   Re: setting up raid10 with more than 4 drives Luke Lonergan
• 19:07   Re: How PostgreSQL handles multiple DDBB instances? Jeff Davis
• 21:17   Very slow left outer join Tyrrill, Ed
• 22:32   Re: How PostgreSQL handles multiple DDBB instances? Craig James
• 22:38   Re: Very slow left outer join Michael Glaesemann
• 22:47   Re: Very slow left outer join Klint Gore
• 23:18   Re: setting up raid10 with more than 4 drives Rajesh Kumar Mallah

30 May 2007

• 00:22   Re: Very slow left outer join Tom Lane
• 00:27   Re: setting up raid10 with more than 4 drives Luke Lonergan
• 00:31   Re: setting up raid10 with more than 4 drives Stephen Frost
• 00:50   Re: setting up raid10 with more than 4 drives Luke Lonergan
• 00:58   Re: Vacuum takes forever Joost Kraaijeveld
• 01:48   Re: setting up raid10 with more than 4 drives Jonah H. Harris
• 02:29   Re: setting up raid10 with more than 4 drives david@lang.hm
• 04:29   Re: setting up raid10 with more than 4 drives Peter Childs
• 05:21   Re: Vacuum takes forever Dave Page
• 06:42   Bad RAID1 read performance Albert Cervera Areny
• 07:42   Re: setting up raid10 with more than 4 drives Stephen Frost
• 09:08   Re: setting up raid10 with more than 4 drives Gregory Stark
• 11:07   Re: setting up raid10 with more than 4 drives Luke Lonergan
• 11:10   Re: Bad RAID1 read performance Luke Lonergan
• 11:11   Re: Vacuum takes forever Andrew Sullivan
• 11:26   Re: setting up raid10 with more than 4 drives Michael Stone
• 11:37   Re: setting up raid10 with more than 4 drives Luke Lonergan
• 12:00   Re: Bad RAID1 read performance Albert Cervera Areny
• 12:09   Re: setting up raid10 with more than 4 drives Michael Stone
• 12:22   Re: setting up raid10 with more than 4 drives Luke Lonergan
• 12:23   Re: setting up raid10 with more than 4 drives Gregory Stark
• 12:29   Re: setting up raid10 with more than 4 drives PFC
• 12:38   Re: setting up raid10 with more than 4 drives PFC
• 12:53   Re: setting up raid10 with more than 4 drives Luke Lonergan
• 12:57   Re: setting up raid10 with more than 4 drives mark@mark.mielke.cc
• 13:23   Re: Very slow left outer join Tyrrill, Ed
• 13:55   Re: Very slow left outer join Tyrrill, Ed
• 13:59   Re: Very slow left outer join Tom Lane
• 15:20   Re: Bad RAID1 read performance Dimitri
• 16:59   Re: setting up raid10 with more than 4 drives Rajesh Kumar Mallah
• 17:14   Re: Bad RAID1 read performance Luke Lonergan
• 17:19   Re: setting up raid10 with more than 4 drives Luke Lonergan
• 17:43   Re: setting up raid10 with more than 4 drives mark@mark.mielke.cc
• 18:45   Database connection for Tbl_B established Y Sidhu
• 19:32   Re: Database connection for Tbl_B established Tom Lane
• 20:36   Re: Database connection for Tbl_B established Y Sidhu
• 22:54   Re: setting up raid10 with more than 4 drives Rajesh Kumar Mallah

31 May 2007

• 00:36   Re: Append table Hanu Kurubar
• 08:01   Re: Bad RAID1 read performance Albert Cervera Areny
• 10:22   DB cluster sharing between 32 and 64 bit software versions Ireneusz Pluta
• 10:36   Re: DB cluster sharing between 32 and 64 bit software versions Bill Moran
• 16:28   Some info to share: db_STRESS Benchmark results Dimitri
• 16:48   Re: Some info to share: db_STRESS Benchmark results Alexander Staubo
• 17:19   Re: Some info to share: db_STRESS Benchmark results Dimitri
• 18:24   Re: max_fsm_pages, shared_buffers and checkpoint_segments Vivek Khera
• 19:39   Re: setting up raid10 with more than 4 drives Steinar H. Gunderson
• 20:12   Re: setting up raid10 with more than 4 drives Sander Steffann