Mailing lists [pgsql-performance]

1 May 2007

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

2 May 2007

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

3 May 2007

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

4 May 2007

• 00:22   Re: Feature Request --- was: PostgreSQL Performance Tuning Carlos Moreno
• 00:53   Re: Feature Request --- was: PostgreSQL Performance Tuning david@lang.hm
• 01:12   Re: Feature Request --- was: PostgreSQL Performance Tuning Carlos Moreno
• 01:53   Re: Feature Request --- was: PostgreSQL Performance Tuning david@lang.hm
• 02:38   Re: Query performance problems with partitioned tables Merlin Moncure
• 04:33   Re: Feature Request --- was: PostgreSQL Performance Tuning Greg Smith
• 04:53   Re: pg_stat_* collection Greg Smith
• 05:10   Re: pg_stat_* collection Tobias Brox
• 12:46   Re: Feature Request --- was: PostgreSQL Performance Tuning Michael Stone
• 12:48   Re: pg_stat_* collection Michael Stone
• 15:05   Index not being used in sorting of simple table Paul Smith
• 15:11   Re: Query performance problems with partitioned tables Scott Marlowe
• 15:26   Re: Index not being used in sorting of simple table Heikki Linnakangas
• 15:43   Re: Index not being used in sorting of simple table Tom Lane
• 16:20   Re: Index not being used in sorting of simple table Paul Smith
• 17:01   Re: Feature Request --- was: PostgreSQL Performance Tuning Sebastian Hennebrueder
• 17:10   Re: Query performance problems with partitioned tables Merlin Moncure
• 17:11   Re: Feature Request --- was: PostgreSQL Performance Tuning Josh Berkus
• 17:22   Re: Feature Request --- was: PostgreSQL Performance Tuning Sebastian Hennebrueder

5 May 2007

• 01:07   Re: Feature Request --- was: PostgreSQL Performance Tuning Greg Smith
• 07:19   Re: Feature Request --- was: PostgreSQL Performance Tuning Mark Kirkwood
• 09:31   Re: Feature Request --- was: PostgreSQL Performance Tuning Steinar H. Gunderson
• 15:54   Re: Feature Request --- was: PostgreSQL Performance Tuning Sebastian Hennebrueder
• 22:57   How to Find Cause of Long Vacuum Times - NOOB Question Yudhvir Singh Sidhu
• 23:40   Re: How to Find Cause of Long Vacuum Times - NOOB Question Steinar H. Gunderson

6 May 2007

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

7 May 2007

• 00:36   Re: Index not being used in sorting of simple table Tom Lane
• 13:38   Merging large volumes of data Ambrus Wagner (IJ/ETH)
• 13:45   Re: Merging large volumes of data Andreas Kostyrka
• 14:24   Re: Merging large volumes of data Gregory Stark
• 15:09   Re: Merging large volumes of data Tom Lane
• 15:54   Re: How to Find Cause of Long Vacuum Times - NOOB Question Jim Nasby
• 21:55   Best OS for Postgres 8.2 David Levy
• 21:59   Re: Best OS for Postgres 8.2 Joshua D. Drake
• 22:04   Re: Best OS for Postgres 8.2 Bill Moran
• 22:14   Re: Best OS for Postgres 8.2 Joshua D. Drake
• 22:57   Re: Best OS for Postgres 8.2 Steve Atkins

8 May 2007

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

9 May 2007

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

10 May 2007

• 00:26   Re: Performance Woes CAJ CAJ
• 00:29   Re: Performance Woes Joshua D. Drake
• 00:35   Re: Performance Woes Ralph Mason
• 00:39   Re: Performance Woes Joshua D. Drake
• 00:42   Re: Performance Woes Jeff Davis
• 01:45   Re: Performance Woes Ralph Mason
• 01:50   Re: Performance Woes Scott Mohekey
• 02:05   Re: Performance Woes Alvaro Herrera
• 04:30   Re: Performance Woes Tom Lane
• 04:58   Background vacuum Daniel Haensse
• 05:25   Re: Background vacuum Dan Harris
• 09:07   Re: Cannot make GIN intarray index be used by the planner Valentine Gogichashvili
• 12:47   Re: [PERFORM] REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Bill Moran
• 13:23   REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Susan Russo
• 13:38   Re: REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Steinar H. Gunderson
• 13:47   Re: REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Bill Moran
• 14:08   Re: REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Susan Russo
• 15:30   Re: Nested loops overpriced Peter Eisentraut
• 15:35   Re: Nested loops overpriced Peter Eisentraut
• 15:47   Re: Nested loops overpriced Tom Lane
• 20:47   Re: [PERFORM] REVISIT specific query (not all) on Pg8 MUCH slowerthan Pg7 Bill Moran
• 20:47   Re: [PERFORM] REVISIT specific query (not all) on Pg8 MUCH slowerthan Pg7 Bill Moran

11 May 2007

• 00:11   Re: Background vacuum Ron Mayer
• 02:05   Re: REVISIT specific query (not all) on Pg8 MUCH slower than Pg7 Susan Russo
• 13:35   Re: Best OS for Postgres 8.2 Adam Witney
• 15:31   Re: estimating the need for VACUUM FULL and REINDEX Guillaume Cottenceau
• 17:25   Re: estimating the need for VACUUM FULL and REINDEX Alvaro Herrera
• 19:11   Re: BUG #3270: limit < 16 optimizer behaviour Bruno Wolff III

12 May 2007

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

13 May 2007

• 06:34   Re: Best OS for Postgres 8.2 Andrew McMillan
• 08:39   Re: Kernel cache vs shared_buffers Harald Armin Massa
• 09:41   Re: Kernel cache vs shared_buffers Heikki Linnakangas
• 09:57   Re: Kernel cache vs shared_buffers Harald Armin Massa
• 10:38   Re: Kernel cache vs shared_buffers Magnus Hagander

14 May 2007

• 00:43   pg_stats how-to? Yudhvir Singh Sidhu
• 01:45   Re: pg_stats how-to? Adam Tauno Williams
• 09:08   Re: 500 requests per second Richard Huxton
• 16:17   Re: pg_stats how-to? Y Sidhu
• 16:26   Re: pg_stats how-to? Jim C. Nasby
• 17:21   Re: Transaction prioritization from java possible? Josh Berkus
• 17:49   Re: pg_stats how-to? Jim C. Nasby
• 18:09   Re: pg_stats how-to? Y Sidhu
• 18:36   Re: pg_stats how-to? Jim C. Nasby
• 19:08   Re: pg_stats how-to? Y Sidhu
• 19:14   Re: pg_stats how-to? Jim C. Nasby
• 20:53   Re: pg_stats how-to? Y Sidhu
• 21:11   Re: pg_stats how-to? Bill Moran
• 22:16   Re: pg_stats how-to? Y Sidhu

15 May 2007

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

16 May 2007

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

17 May 2007

• 13:55   Re: Background vacuum Andrew Sullivan
• 14:04   WAL log performance/efficiency question Keaton Adams
• 14:23   Re: WAL log performance/efficiency question Heikki Linnakangas
• 14:56   Re: WAL log performance/efficiency question Tom Lane
• 15:34   Re: WAL log performance/efficiency question Keaton Adams
• 15:52   Re: WAL log performance/efficiency question Heikki Linnakangas
• 16:01   Re: WAL log performance/efficiency question Keaton Adams
• 22:45   Ever Increasing IOWAIT Ralph Mason
• 23:02   Re: Ever Increasing IOWAIT Joshua D. Drake
• 23:19   Re: Ever Increasing IOWAIT Ralph Mason

18 May 2007

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

19 May 2007

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

20 May 2007

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

21 May 2007

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

22 May 2007

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

23 May 2007

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

24 May 2007

• 01:31   Re: [PERFORM] does VACUUM ANALYZE complete with this error?  Tom Lane
• 01:31   Re: [PERFORM] does VACUUM ANALYZE complete with this error?  Tom Lane
• 02:01   Memory allocation and Vacuum abends Leandro Guimarães dos Santos
• 04:28   Re: max_fsm_pages, shared_buffers and checkpoint_segments Heikki Linnakangas
• 07:01   Re: LIKE search and performance Andy
• 19:15   Re: LIKE search and performance James Mansion
• 19:23   Re: LIKE search and performance Magnus Hagander
• 20:51   Re: LIKE search and performance James Mansion
• 21:04   Re: LIKE search and performance Mark Lewis
• 21:22   Re: LIKE search and performance Craig James
• 21:47   Re: LIKE search and performance Alvaro Herrera
• 21:55   Re: LIKE search and performance mark@mark.mielke.cc
• 22:07   Re: LIKE search and performance Craig James
• 22:07   Re: LIKE search and performance PFC

25 May 2007

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

26 May 2007

• 00:20   Re: general PG network slowness (possible cure) (repost) Tom Lane
• 00:36   Re: Adding disks/xlog & index Gregory Stark
• 01:44   ECC RAM really needed? Craig James
• 02:15   Re: ECC RAM really needed? Bruno Wolff III
• 04:02   Re: ECC RAM really needed? Greg Smith
• 04:19   Re: ECC RAM really needed? Tom Lane
• 07:07   Re: general PG network slowness (possible cure) (repost) Peter T. Breuer
• 12:41   Re: Performance problem on 8.2.4, but not 8.2.3 Kristo Kaiv
• 12:43   Re: ECC RAM really needed? Michael Stone
• 14:52   Re: ECC RAM really needed? mark@mark.mielke.cc
• 16:46   Re: general PG network slowness (possible cure) (repost) Tom Lane

27 May 2007

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

28 May 2007

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

29 May 2007

• 06:21   Re: Feature suggestion : FAST CLUSTER PFC
• 07:57   Re: Feature suggestion : FAST CLUSTER Jim Nasby
• 08:41   Re: Feature suggestion : FAST CLUSTER PFC
• 13:07   Re: PITR performance costs Merlin Moncure
• 13:19   Re: general PG network slowness (possible cure) (repost) Merlin Moncure
• 17:04   Vacuum takes forever Joost Kraaijeveld
• 17:14   Re: Vacuum takes forever PFC
• 17:56   Re: Vacuum takes forever Joost Kraaijeveld
• 20:41   Re: Big problem with sql update operation Alvaro Herrera
• 20:43   Re: Vacuum takes forever Dave Page
• 20:48   Re: Vacuum takes forever Joshua D. Drake
• 21:22   setting up raid10 with more than 4 drives Rajesh Kumar Mallah
• 21:57   Re: setting up raid10 with more than 4 drives Luke Lonergan
• 22:07   Re: How PostgreSQL handles multiple DDBB instances? Jeff Davis

30 May 2007

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

31 May 2007

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