Mailing lists [pgsql-performance]

1 June 2005

• 05:36   Re: postgresql-8.0.1 performance tuning Cosimo Streppone
• 05:43   Re: Index on a NULL-value Tobias Brox
• 06:33   Re: postgresql-8.0.1 performance tuning Mark Kirkwood
• 06:45   Re: postgresql-8.0.1 performance tuning Cosimo Streppone
• 07:23   Re: postgresql-8.0.1 performance tuning Mark Kirkwood
• 07:43   How to avoid database bloat Mindaugas Riauba
• 08:51   Re: postgresql-8.0.1 performance tuning Martin Fandel
• 09:01   Re: very large table Simon Riggs
• 09:10   Re: slow queries, possibly disk io Simon Riggs
• 09:45   TIP 9: the planner will ignore... & datatypes Marc Mamin
• 09:58   Re: postgresql-8.0.1 performance tuning Steinar H. Gunderson
• 10:22   Re: postgresql-8.0.1 performance tuning Cosimo Streppone
• 10:27   Re: postgresql-8.0.1 performance tuning Martin Fandel
• 13:40   Re: TIP 9: the planner will ignore... & datatypes Alvaro Herrera
• 14:40   Re: How to avoid database bloat Tom Lane
• 15:31   Moving pg_xlog Keith Worthington
• 16:20   Re: Moving pg_xlog Tom Lane
• 20:11   Re: Moving pg_xlog Keith Worthington
• 20:31   Re: Moving pg_xlog Tom Lane
• 20:31   Re: Moving pg_xlog Brad Nicholson
• 21:27   Re: Moving pg_xlog John A Meinel

2 June 2005

• 02:05   Forcing use of specific index Tobias Brox
• 03:46   Adaptec/LSI/?? RAID Stacy White
• 04:35   Re: Adaptec/LSI/?? RAID Sven Willenberger
• 05:00   Re: Adaptec/LSI/?? RAID William Yu
• 06:06   Re: Moving pg_xlog Tom Lane
• 06:38   Re: 'Fastest' PC's are slowest in the house Grega Bremec
• 07:02   Re: Moving pg_xlog Himanshu Baweja
• 07:28   Re: How to avoid database bloat Mindaugas Riauba
• 08:28   Re: SURVEY: who is running postgresql on 8 or more CPUs? Dirk Lutzebäck
• 09:16   Re: Adaptec/LSI/?? RAID Andrew McMillan
• 11:53   Re: Adaptec/LSI/?? RAID Richard Welty
• 12:12   Re: SURVEY: who is running postgresql on 8 or more CPUs? Dawid Kuroczko
• 12:28   Re: SURVEY: who is running postgresql on 8 or more CPUs? Dirk Lutzebäck
• 12:51   Re: postgresql-8.0.1 performance tuning Martin Fandel
• 13:10   Re: postgresql-8.0.1 performance tuning Martin Fandel
• 13:13   Re: postgresql-8.0.1 performance tuning Martin Fandel
• 13:45   Re: How to avoid database bloat Tom Lane
• 14:23   Re: Moving pg_xlog Tom Lane
• 14:24   Re: How to avoid database bloat Mindaugas Riauba
• 14:47   Re: Moving pg_xlog Himanshu Baweja
• 15:03   Re: Specific query performance problem help requested - postgresql 7.4 Brad Might
• 15:25   Query plan for very large number of joins 
• 15:57   Re: SURVEY: who is running postgresql on 8 or more CPUs? ohp@pyrenet.fr
• 16:05   Re: Query plan for very large number of joins Richard Huxton
• 16:10   Re: How to avoid database bloat Matthew T. O'Connor
• 16:10   Re: How to avoid database bloat Tom Lane
• 16:26   Re: Query plan for very large number of joins Tom Lane
• 17:10   Re: Adaptec/LSI/?? RAID J. Andrew Rogers
• 17:42   Re: Adaptec/LSI/?? RAID Joshua D. Drake
• 17:47   Re: Adaptec/LSI/?? RAID Vivek Khera
• 20:15   Re: Query plan for very large number of joins PFC
• 21:02   Re: Adaptec/LSI/?? RAID (what about JBOD?) mudfoot@rawbw.com
• 22:22   Re: Query plan for very large number of joins Sebastian Hennebrueder
• 23:19   Re: Adaptec/LSI/?? RAID (what about JBOD?) Andrew McMillan

3 June 2005

• 00:30   Re: Adaptec/LSI/?? RAID (what about JBOD?) mudfoot@rawbw.com
• 03:49   SHMMAX / SHMALL Was (Re: postgresql-8.0.1 performance tuning) Paul McGarry
• 06:12   Re: SHMMAX / SHMALL Was (Re: postgresql-8.0.1 performance Mark Kirkwood
• 06:35   Query limitations (size, number of UNIONs ...) Marc Mamin
• 07:07   Filesystem Martin Fandel
• 07:43   Re: Adaptec/LSI/?? RAID Cosimo Streppone
• 08:41   Re: How to avoid database bloat Mindaugas Riauba
• 08:50   Re: SHMMAX / SHMALL Was (Re: postgresql-8.0.1 performance tuning) Martin Fandel
• 09:11   Re: SHMMAX / SHMALL Was (Re: postgresql-8.0.1 performance Mark Kirkwood
• 09:20   Re: SHMMAX / SHMALL Was (Re: postgresql-8.0.1 performance tuning) Martin Fandel
• 10:41   Re: Filesystem Mark Kirkwood
• 12:22   Re: Query plan for very large number of joins 
• 13:15   Re: Query plan for very large number of joins Tom Lane
• 13:18   Re: Filesystem Alex Turner
• 13:27   Re: Query limitations (size, number of UNIONs ...) Stephen Frost
• 13:53   Re: Filesystem Martin Fandel
• 14:24   Re: Query plan for very large number of joins 
• 14:50   Re: BUG #1697: Select getting slower on continously updating data Bruno Wolff III
• 16:43   Re: How to avoid database bloat Matthew T. O'Connor
• 17:18   Re: Filesystem J. Andrew Rogers
• 17:29   Re: Query plan for very large number of joins Tom Lane
• 18:47   Postgresql and Software RAID/LVM Steve Poe
• 22:03   Re: Postgresql and Software RAID/LVM Joshua D. Drake
• 23:13   Insert slow down on empty database Morgan
• 23:22   Re: Forcing use of specific index William Yu
• 23:28   Re: Query plan for very large number of joins Simon Riggs

4 June 2005

• 01:50   Re: Insert slow down on empty database Christopher Browne
• 01:52   Re: Forcing use of specific index Junaili Lie
• 08:17   strategies for optimizing read on rather large tables hubert lubaczewski
• 10:04   Re: Query plan for very large number of joins 
• 11:17   Re: strategies for optimizing read on rather large tables Christopher Kings-Lynne
• 11:18   Re: strategies for optimizing read on rather large tables PFC
• 11:40   Re: strategies for optimizing read on rather large tables hubert lubaczewski
• 11:41   Re: strategies for optimizing read on rather large tables hubert lubaczewski
• 12:08   Re: strategies for optimizing read on rather large tables PFC
• 12:13   Re: strategies for optimizing read on rather large tables hubert lubaczewski
• 13:30   Best hardware Bernd Jagla
• 23:23   Re: Best hardware Mischa Sandberg

6 June 2005

• 01:25   Re: Forcing use of specific index Qingqing Zhou
• 01:28   Re: Need help to decide Mysql vs Postgres Bill Ewing
• 01:29   Re: BUG #1697: Select getting slower on continously updating data Bahadur Singh
• 01:29   Re: How to avoid database bloat matthew@tocr.com
• 01:32   SELECT DISTINCT Performance Issue K C Lau
• 01:32   Most effective tuning choices for busy website? Mark Stosberg
• 01:32   Re: How to avoid database bloat stig erikson
• 01:35   Performance nightmare with dspam (urgent) Casey Allen Shobe
• 01:57   Re: Need help to decide Mysql vs Postgres Christopher Kings-Lynne
• 02:04   Re: Most effective tuning choices for busy website? Neil Conway
• 06:49   Re: Postgresql and Software RAID/LVM Andrew McMillan
• 11:45   Re: SELECT DISTINCT Performance Issue PFC
• 11:54   Re: Need help to decide Mysql vs Postgres PFC
• 14:54   Re: Performance nightmare with dspam (urgent) (resolved) Casey Allen Shobe
• 14:58   Re: How to avoid database bloat Mindaugas Riauba
• 15:08   Re: Performance nightmare with dspam (urgent) (resolved) John A Meinel
• 15:11   Re: Performance nightmare with dspam (urgent) (resolved) PFC
• 15:15   Re: SELECT DISTINCT Performance Issue K C Lau
• 15:19   Re: Performance nightmare with dspam (urgent) (resolved) Michael Stone
• 15:51   Re: Need help to decide Mysql vs Postgres Jeffrey Tenny
• 16:00   Re: Need help to decide Mysql vs Postgres Amit V Shah
• 16:04   Re: Performance nightmare with dspam (urgent) (resolved) Casey Allen Shobe
• 16:08   Re: Performance nightmare with dspam (urgent) (resolved) John A Meinel
• 16:15   Re: Need help to decide Mysql vs Postgres Alvaro Herrera
• 16:24   Re: Need help to decide Mysql vs Postgres Rod Taylor
• 16:41   Re: Need help to decide Mysql vs Postgres PFC
• 16:46   Re: Need help to decide Mysql vs Postgres Amit V Shah
• 16:49   slow growing table Jone C
• 17:00   Re: slow growing table Steinar H. Gunderson
• 17:13   Re: slow growing table Steinar H. Gunderson
• 17:25   Re: Need help to decide Mysql vs Postgres Tobias Brox
• 17:27   Re: Performance nightmare with dspam (urgent) (resolved) Michael Stone
• 17:47   Postgresql on an AMD64 machine Mark Rinaudo
• 17:50   Re: Need help to decide Mysql vs Postgres Christopher Browne
• 18:12   Re: Need help to decide Mysql vs Postgres PFC
• 18:32   Re: Postgresql on an AMD64 machine Vivek Khera
• 18:34   Re: Need help to decide Mysql vs Postgres Michael Fuhr
• 18:55   Re: Need help to decide Mysql vs Postgres Ron Mayer
• 18:55   Re: Need help to decide Mysql vs Postgres Jan Wieck
• 19:13   Re: Need help to decide Mysql vs Postgres Joel Fradkin
• 19:14   Re: Postgresql and Software RAID/LVM Marty Scholes
• 21:00   Re: Postgresql on an AMD64 machine Mike Rylander
• 21:15   Re: Postgresql on an AMD64 machine Tom Lane
• 22:22   Re: Postgresql on an AMD64 machine Mark Rinaudo
• 23:49   Re: Postgresql on an AMD64 machine Neil Conway

7 June 2005

• 04:28   Re: Postgresql on an AMD64 machine Tom Lane
• 04:37   Re: Postgresql and Software RAID/LVM John A Meinel
• 04:54   Re: Need help to decide Mysql vs Postgres Tom Lane
• 09:43   Re: Performance nightmare with dspam (urgent) Russell Smith
• 12:54   Re: Need help to decide Mysql vs Postgres PFC
• 15:30   Re: Postgresql and Software RAID/LVM Marty Scholes
• 19:40   Re: Postgresql on an AMD64 machine Donald Courtney
• 19:54   Re: Postgresql on an AMD64 machine Tom Arthurs
• 20:21   Re: Postgresql on an AMD64 machine Donald Courtney
• 20:28   Re: Postgresql on an AMD64 machine Joshua D. Drake
• 20:39   Re: Postgresql on an AMD64 machine Tom Arthurs
• 20:47   Re: Postgresql on an AMD64 machine Alvaro Herrera
• 21:04   Re: Postgresql on an AMD64 machine Michael Stone
• 21:11   Re: Postgresql on an AMD64 machine Tom Lane
• 22:21   Re: slow growing table Simon Riggs

8 June 2005

• 00:20   Re: Postgresql on an AMD64 machine Neil Conway
• 00:44   Re: Postgresql on an AMD64 machine John A Meinel
• 03:08   Re: Postgresql on an AMD64 machine Josh Berkus
• 03:50   Re: Postgresql on an AMD64 machine Tom Lane
• 06:16   Re: Postgresql on an AMD64 machine Simon Riggs
• 07:37   Re: Filesystem Martin Fandel
• 09:09   Importing from pg_dump slow, low Disk IO Steve Pollard
• 09:37   full outer performance problem Kim Bisgaard
• 09:52   Re: Postgresql on an AMD64 machine Michael Stone
• 12:10   Re: Filesystem Michael Stone
• 12:18   Re: full outer performance problem Bruno Wolff III
• 12:26   Re: Filesystem Martin Fandel
• 12:32   Re: full outer performance problem Kim Bisgaard
• 13:34   Re: SELECT DISTINCT Performance Issue George Essig
• 13:49   Re: Filesystem Grega Bremec
• 14:38   Re: SELECT DISTINCT Performance Issue K C Lau
• 14:44   Re: full outer performance problem Tom Lane
• 14:55   Re: SELECT DISTINCT Performance Issue George Essig
• 15:04   Performance problems, bad estimates and plan Allan Wang
• 16:23   Re: full outer performance problem Tom Lane
• 16:32   Help specifying new web server/database machine Rory Campbell-Lange
• 16:41   Re: Help specifying new web server/database machine Bjoern Metzdorf
• 16:44   Re: Postgresql on an AMD64 machine Tom Arthurs
• 16:48   Re: Help specifying new web server/database machine Joshua D. Drake
• 16:54   Re: Postgresql on an AMD64 machine Bjoern Metzdorf
• 17:05   Re: Performance problems, bad estimates and plan Tom Lane
• 17:39   Re: Performance problems, bad estimates and plan Tom Lane
• 17:57   Re: Performance problems, bad estimates and plan Tom Lane
• 18:06   Re: Performance problems, bad estimates and plan Tom Lane
• 18:47   Re: full outer performance problem Kim Bisgaard
• 18:54   Re: full outer performance problem Kim Bisgaard
• 18:54   Re: Help specifying new web server/database machine Matthew Nuzum
• 19:34   Help with rewriting query Junaili Lie
• 19:56   Re: Help with rewriting query Tobias Brox
• 21:04   Recommendations for configuring a 200 GB database Kevin Grittner
• 21:14   Re: Postgresql on an AMD64 machine Sam Vilain
• 22:48   Re: Help with rewriting query Junaili Lie
• 23:33   Re: Help specifying new web server/database machine William Yu

9 June 2005

• 00:20   Re: Postgresql on an AMD64 machine Neil Conway
• 01:47   Re: Help with rewriting query Jim Johannsen
• 03:00   Re: Help with rewriting query Bruno Wolff III
• 03:57   Re: Importing from pg_dump slow, low Disk IO Steve Pollard
• 04:02   Re: Help with rewriting query Kevin Grittner
• 04:41   How to find the size of a database - reg. Shanmugasundaram Doraisamy
• 04:59   Re: How to find the size of a database - reg. Christopher Kings-Lynne
• 06:02   Query plan changes after pg_dump / pg_restore jonanews@oismail.com
• 07:33   Re: Query plan changes after pg_dump / pg_restore Dennis Bjorklund
• 08:07   Re: Query plan changes after pg_dump / pg_restore Jona
• 08:11   Re: Recommendations for configuring a 200 GB database Richard Huxton
• 08:23   Re: Query plan changes after pg_dump / pg_restore Christopher Kings-Lynne
• 08:50   Re: Query plan changes after pg_dump / pg_restore Jona
• 08:53   Re: Query plan changes after pg_dump / pg_restore Christopher Kings-Lynne
• 09:15   pg_autovacuum settings Michael Ryan S. Puncia
• 09:18   Re: Query plan changes after pg_dump / pg_restore Jona
• 10:09   postgresql.conf runtime statistics default Yann Michel
• 10:48   Re: Query plan changes after pg_dump / pg_restore Dennis Bjorklund
• 13:15   Re: postgresql.conf runtime statistics default Richard Huxton
• 13:35   Re: [Npgsql-general] index out of range Josh Close
• 13:38   Re: Query plan changes after pg_dump / pg_restore Jona
• 14:55   Re: Query plan changes after pg_dump / pg_restore Tom Lane
• 14:56   Re: Recommendations for configuring a 200 GB Kevin Grittner
• 15:01   Re: Recommendations for configuring a 200 GB Christopher Kings-Lynne
• 16:10   Re: Query plan changes after pg_dump / pg_restore Jona
• 16:37   random_page_cost = 1? Alex Stapleton
• 16:42   Re: Help specifying new web server/database machine Rory Campbell-Lange
• 16:55   Re: random_page_cost = 1? Tom Lane
• 17:25   Re: Help specifying new web server/database machine Matthew Nuzum
• 18:00   Re: Help specifying new web server/database machine Oliver Elphick
• 18:05   Re: timestamp indexing Jim C. Nasby
• 19:44   Re: timestamp indexing Tobias Brox
• 19:53   Re: Help specifying new web server/database machine William Yu
• 20:59   Re: Help specifying new web server/database machine Rory Campbell-Lange
• 21:25   Re: Help specifying new web server/database machine Rory Campbell-Lange

10 June 2005

• 01:26   Re: Help with rewriting query Junaili Lie
• 01:30   Re: Help with rewriting query Junaili Lie
• 04:57   Re: postgresql.conf runtime statistics default Yann Michel
• 06:03   Re: Importing from pg_dump slow, low Disk IO Steve Pollard
• 06:47   Re: Importing from pg_dump slow, low Disk IO Martin Fandel
• 07:20   Re: postgresql.conf runtime statistics default Richard Huxton
• 08:49   Re: Help with rewriting query Tobias Brox
• 09:05   Cleaning bloated pg_attribute Michal Taborsky
• 10:10   Re: Cleaning bloated pg_attribute Richard Huxton
• 10:15   Re: Importing from pg_dump slow, low Disk IO Martin Fandel
• 12:07   Re: Help with rewriting query Bruno Wolff III
• 12:34   Re: Whence the Opterons? Richard Rowell
• 15:00   Re: Whence the Opterons? Mohan, Ross
• 15:42   Index ot being used linux@alteeve.com
• 15:56   Re: Index ot being used Tobias Brox
• 15:57   Re: Index ot being used Jacques Caron
• 17:45   faster search Clark Slater
• 17:51   Re: faster search Steinar H. Gunderson
• 18:01   Re: faster search John A Meinel
• 18:05   Re: faster search Tobias Brox
• 19:50   Re: Help with rewriting query Kevin Grittner
• 20:12   Re: faster search Steve Atkins

11 June 2005

• 00:08   Re: faster search Clark Slater
• 00:14   Re: faster search Joshua D. Drake
• 00:20   Re: faster search Clark Slater
• 00:46   Re: faster search Joshua D. Drake
• 00:48   Re: faster search Joshua D. Drake
• 00:51   Re: faster search John A Meinel
• 00:52   Re: faster search Clark Slater
• 00:55   Re: faster search Joshua D. Drake
• 10:00   Re: Help with rewriting query Tobias Brox
• 11:12   Re: faster search Cosimo Streppone
• 16:49   Re: faster search Tom Lane

12 June 2005

• 14:12   Re: Index ot being used Madison Kelly
• 15:56   Re: Index ot being used Tom Lane
• 17:38   Re: Index ot being used Bruno Wolff III
• 17:40   Updates on large tables are extremely slow Yves Vindevogel
• 17:58   Re: Updates on large tables are extremely slow Jacques Caron
• 22:52   Re: Index ot being used Madison Kelly

13 June 2005

• 00:36   Resource Requirements elein@varlena.com (elein)
• 02:43   Re: Updates on large tables are extremely slow Mark Kirkwood
• 03:01   Re: Index ot being used Bruno Wolff III
• 03:14   Re: Index ot being used Bruno Wolff III
• 03:35   Re: Index ot being used Madison Kelly
• 03:43   Re: Index ot being used Madison Kelly
• 03:54   Re: Index ot being used Bruno Wolff III
• 04:29   Re: Index ot being used Madison Kelly
• 06:54   View not using index Yves Vindevogel
• 07:06   Re: View not using index Russell Smith
• 07:18   Re: View not using index Yves Vindevogel
• 07:19   Re: View not using index Russell Smith
• 07:35   Re: View not using index Yves Vindevogel
• 08:54   Re: Updates on large tables are extremely slow Mark Kirkwood
• 09:02   Re: Updates on large tables are extremely slow Yves Vindevogel
• 11:51   Fwd: Updates on large tables are extremely slow Yves Vindevogel
• 12:17   Re: Updates on large tables are extremely slow Yves Vindevogel
• 12:59   How to enhance the chance that data is in disk cache Jona
• 13:02   PostgreSQL using the wrong Index Alex Stapleton
• 13:08   Re: PostgreSQL using the wrong Index Alex Stapleton
• 13:29   Re: Index ot being used Bruno Wolff III
• 14:18   Re: View not using index Tom Lane
• 14:21   Re: Help with rewriting query Kevin Grittner
• 14:32   Re: Updates on large tables are extremely slow Tom Lane
• 14:34   Re: Index ot being used Kevin Grittner
• 14:51   Re: How to enhance the chance that data is in disk cache Tom Lane
• 14:54   Re: PostgreSQL using the wrong Index Tom Lane
• 15:01   Re: PostgreSQL using the wrong Index John A Meinel
• 15:01   Re: Index ot being used John A Meinel
• 15:20   Re: PostgreSQL using the wrong Index Alex Stapleton
• 15:40   Re: PostgreSQL using the wrong Index Wei Weng
• 15:49   Re: Index ot being used Bruno Wolff III
• 15:50   Fwd: Updates on large tables are extremely slow Yves Vindevogel
• 16:05   Re: Fwd: Updates on large tables are extremely slow Richard Huxton
• 16:22   Re: Index ot being used Tom Lane
• 16:46   Re: Updates on large tables are extremely slow Yves Vindevogel
• 16:47   Re: Index ot being used Kevin Grittner
• 16:50   Re: Index ot being used Bruno Wolff III
• 16:54   Re: Index ot being used Bruno Wolff III
• 16:55   Re: Updates on large tables are extremely slow Rod Taylor
• 17:06   Re: How to enhance the chance that data is in disk cache Jona
• 17:22   Re: Updates on large tables are extremely slow Yves Vindevogel
• 17:36   Re: Updates on large tables are extremely slow Jacques Caron
• 17:51   Re: Index ot being used Madison Kelly
• 17:57   Re: Index ot being used Madison Kelly
• 18:13   Re: Index ot being used Tom Lane
• 19:22   Re: Index ot being used Madison Kelly
• 19:56   System Requirement Saranya Sivakumar
• 20:10   Re: System Requirement Madison Kelly
• 20:46   Re: Index ot being used Bruno Wolff III
• 20:54   Re: Index ot being used Greg Stark
• 21:00   Re: Index ot being used Tom Lane
• 21:18   Pseudo-Solved was: (Re: Index ot being used) Madison Kelly
• 21:30   Re: Index ot being used Madison Kelly
• 22:04   Re: Resource Requirements Josh Berkus

14 June 2005

• 01:46   Re: Updates on large tables are extremely slow Christopher Kings-Lynne
• 08:32   Re: System Requirement hubert depesz lubaczewski
• 13:04   Re: System Requirement Saranya Sivakumar
• 16:40   regular expression search Pierre A. Fortier
• 22:36   Re: Most effective tuning choices for busy website? Mark Stosberg

15 June 2005

• 01:19   Re: regular expression search Christopher Kings-Lynne
• 02:51   SELECT LIMIT 1 VIEW Performance Issue K C Lau
• 09:06   Needed: Simplified guide to optimal memory configuration Todd Landfried
• 09:25   Re: Needed: Simplified guide to optimal memory configuration Dennis Bjorklund
• 14:18   Re: Needed: Simplified guide to optimal memory configuration Tom Lane
• 14:20   Re: Needed: Simplified guide to optimal memory configuration Bruno Wolff III
• 16:54   Re: Index ot being used Karim Nassar
• 17:33   Re: Index ot being used Madison Kelly
• 18:35   Re: Needed: Simplified guide to optimal memory configuration Josh Berkus

16 June 2005

• 14:46   Re: Needed: Simplified guide to optimal memory configuration Todd Landfried
• 17:01   Re: Needed: Simplified guide to optimal memory Mark Lewis
• 17:03   Re: Needed: Simplified guide to optimal memory configuration Bruno Wolff III
• 18:04   How to determine whether to VACUUM or CLUSTER ken shaw
• 19:28   How does the transaction buffer work? Veikko Mäkinen
• 19:36   Re: How does the transaction buffer work? John A Meinel
• 20:13   Re: How does the transaction buffer work? PFC
• 20:53   could not send data to client: Justin Davis
• 21:51   Re: How does the transaction buffer work? Josh Berkus

17 June 2005

• 02:15   Re: Needed: Simplified guide to optimal memory Todd Landfried
• 03:47   Re: How to determine whether to VACUUM or CLUSTER Tom Lane
• 04:08   Re: How does the transaction buffer work? Tom Lane
• 04:46   Re: Needed: Simplified guide to optimal memory Alvaro Herrera
• 05:07   Re: How does the transaction buffer work? Rod Taylor
• 12:49   Re: could not send data to client: Merlin Moncure
• 16:42   Re: Needed: Simplified guide to optimal memory Josh Berkus
• 19:34   Multiple disks: RAID 5 or PG Cluster Yves Vindevogel
• 20:22   Re: Multiple disks: RAID 5 or PG Cluster Vivek Khera
• 20:38   Re: Multiple disks: RAID 5 or PG Cluster mudfoot@rawbw.com
• 21:30   Fwd: Multiple disks: RAID 5 or PG Cluster Yves Vindevogel
• 21:31   Fwd: Multiple disks: RAID 5 or PG Cluster Yves Vindevogel

18 June 2005

• 16:00   Re: Multiple disks: RAID 5 or PG Cluster PFC
• 16:24   Re: Multiple disks: RAID 5 or PG Cluster Jacques Caron
• 16:42   Fwd: Multiple disks: RAID 5 or PG Cluster Yves Vindevogel
• 22:58   Re: Fwd: Multiple disks: RAID 5 or PG Cluster Michael Stone

19 June 2005

• 04:55   How to determine whether to VACUUM or CLUSTER Ken Shaw
• 04:55   Re: Most effective tuning choices for busy website? Christopher Weimann
• 04:58   Re: Multiple disks: RAID 5 or PG Cluster Alex Turner
• 05:54   Re: Fwd: Multiple disks: RAID 5 or PG Cluster Greg Stark

20 June 2005

• 06:53   Re: How to determine whether to VACUUM or CLUSTER Jim C. Nasby
• 14:44   autovacuum suggestions for 500,000,000+ row tables? Alex Stapleton
• 14:59   Re: autovacuum suggestions for 500,000,000+ row Jacques Caron
• 15:06   Re: autovacuum suggestions for 500,000,000+ row tables? Alex Stapleton
• 15:20   Re: autovacuum suggestions for 500,000,000+ row tables? John Arbash Meinel
• 17:46   Re: autovacuum suggestions for 500,000,000+ row tables? Josh Berkus
• 17:56   investigating slow queries through pg_stat_activity Dan Harris
• 18:46   Re: investigating slow queries through Jacques Caron
• 19:11   Re: investigating slow queries through pg_stat_activity Tom Lane
• 20:30   Re: investigating slow queries through pg_stat_activity George Essig

21 June 2005

• 10:05   Re: autovacuum suggestions for 500,000,000+ row tables? Alex Stapleton
• 14:01   Do Views execute underlying query everytime ?? Amit V Shah
• 14:34   Limit clause not using index Yves Vindevogel
• 14:40   Re: Limit clause not using index Bricklen Anderson
• 14:42   Re: Limit clause not using index John A Meinel
• 14:43   Re: Limit clause not using index Tom Lane
• 14:45   Re: Do Views execute underlying query everytime ?? Matthew Nuzum
• 14:49   Re: Do Views execute underlying query everytime ?? Amit V Shah
• 14:50   Re: Do Views execute underlying query everytime ?? Richard Huxton
• 14:58   Re: Limit clause not using index Yves Vindevogel
• 15:00   Re: Do Views execute underlying query everytime ?? PFC
• 15:01   Re: Do Views execute underlying query everytime ?? John A Meinel
• 15:05   Re: slow growing table Jone C
• 15:08   Re: Limit clause not using index Yves Vindevogel
• 15:10   Re: Limit clause not using index Yves Vindevogel
• 15:14   Re: Limit clause not using index John A Meinel
• 15:18   Another question on indexes (drop and recreate) Yves Vindevogel
• 15:19   Re: slow growing table John A Meinel
• 15:22   Re: Another question on indexes (drop and recreate) John A Meinel
• 15:31   Re: Limit clause not using index Tom Lane
• 15:33   Re: Another question on indexes (drop and recreate) Yves Vindevogel
• 15:47   Re: Do Views execute underlying query everytime ?? Amit V Shah
• 15:49   Re: Another question on indexes (drop and recreate) John A Meinel
• 16:05   Trying to figure out pgbench William Yu
• 16:09   unsubscribe Don Vaillancourt
• 16:12   Re: Trying to figure out pgbench Mohan, Ross
• 16:44   Re: Another question on indexes (drop and recreate) Yves Vindevogel
• 16:55   Re: Another question on indexes (drop and recreate) John A Meinel
• 16:59   Re: Do Views execute underlying query everytime ?? PFC
• 17:11   Re: autovacuum suggestions for 500,000,000+ row tables? Josh Berkus
• 17:58   Re: Do Views execute underlying query everytime ?? Matthew Nuzum
• 18:22   Configurator project launched Josh Berkus
• 19:10   Querying 19million records very slowly Kjell Tore Fossbakk
• 19:31   Re: Another question on indexes (drop and recreate) Yves Vindevogel
• 19:45   Re: Limit clause not using index Tobias Brox
• 19:46   Prepared statements vs. Stored Procedures Oliver Crosby
• 19:59   Re: Querying 19million records very slowly Paul Ramsey
• 20:39   Re: Prepared statements vs. Stored Procedures Tobias Brox
• 21:08   Re: Limit clause not using index Michael Fuhr
• 21:20   Re: Limit clause not using index Tom Lane
• 21:33   Re: Querying 19million records very slowly PFC
• 21:54   Re: Trying to figure out pgbench William Yu
• 22:08   Re: autovacuum suggestions for 500,000,000+ row tables? Alex Stapleton
• 22:23   Re: autovacuum suggestions for 500,000,000+ row tables? Steinar H. Gunderson
• 23:12   Re: Configurator project launched Josh Berkus
• 23:30   Re: Configurator project launched Joshua D. Drake

22 June 2005

• 00:50   Re: Configurator project launched Greg Sabino Mullane
• 03:55   Re: Limit clause not using index Tobias Brox
• 07:26   Re: Prepared statements vs. Stored Procedures Radu-Adrian Popescu
• 07:45   Re: Querying 19million records very slowly Kjell Tore Fossbakk
• 08:04   Re: Querying 19million records very slowly Tobias Brox
• 08:18   Re: Querying 19million records very slowly Kjell Tore Fossbakk
• 08:31   Re: Configurator project launched Andreas Pflug
• 08:39   Re: Querying 19million records very slowly Tobias Brox
• 08:55   Re: Querying 19million records very slowly Michael Glaesemann
• 09:10   Re: Querying 19million records very slowly Kjell Tore Fossbakk
• 09:15   Forums & tsearch2 - best practices reg. concurrency Markus Wollny
• 09:36   Re: Querying 19million records very slowly Tobias Brox
• 10:53   Re: Forums & tsearch2 - best practices reg. concurrency Oleg Bartunov
• 13:51   Re: Querying 19million records very slowly Tom Lane
• 14:19   Re: Querying 19million records very slowly Paul Ramsey
• 14:41   Re: Querying 19million records very slowly Kjell Tore Fossbakk
• 14:50   Performance Tuning Article Frank Wiles
• 15:27   Re: Querying 19million records very slowly Stefan Weiss
• 16:17   Re: Limit clause not using index Kevin Grittner
• 16:29   Re: Querying 19million records very slowly Tobias Brox
• 17:16   Re: Performance Tuning Article Josh Berkus
• 17:41   Re: Performance Tuning Article Frank Wiles
• 18:08   Re: Performance Tuning Article Karim Nassar
• 19:25   parameterized LIKE does not use index Kurt De Grave
• 21:07   Re: parameterized LIKE does not use index Josh Berkus

23 June 2005

• 01:06   Re: Performance Tuning Article Tobias Brox
• 02:31   Re: Performance Tuning Article Keith Worthington
• 08:33   Re: parameterized LIKE does not use index Kurt De Grave
• 09:22   Re: Performance Tuning Article Radu-Adrian Popescu
• 12:16   Re: Performance Tuning Article Keith Worthington
• 13:31   Re: Querying 19million records very slowly Kjell Tore Fossbakk
• 13:36   Re: Performance Tuning Article Dave Cramer
• 13:46   Re: Performance Tuning Article Radu-Adrian Popescu
• 13:47   Re: Performance Tuning Article Frank Wiles
• 14:19   Re: parameterized LIKE does not use index Bruno Wolff III
• 14:45   Re: Performance Tuning Article Michael Stone
• 15:10   select distinct on varchar - wild performance differences! Elliott Bennett
• 15:31   Re: Querying 19million records very slowly Tobias Brox
• 15:35   Re: select distinct on varchar - wild performance differences! Tom Lane
• 16:17   Re: Performance Tuning Article Dave Cramer
• 17:10   Re: select distinct on varchar - wild performance differences! Elliott Bennett
• 17:16   Re: Performance Tuning Article Tom Lane
• 18:55   Re: parameterized LIKE does not use index Josh Berkus
• 19:38   ETL optimization Bricklen Anderson
• 19:54   Re: ETL optimization Meetesh Karia
• 20:17   Re: ETL optimization Bricklen Anderson
• 21:56   Re: ETL optimization Jacques Caron
• 22:04   Re: ETL optimization Bricklen Anderson

24 June 2005

• 04:27   Re: ETL optimization Dennis Bjorklund
• 04:33   Postgres 8 vs Postgres 7.4/cygwin Scott Goldstein
• 05:02   Re: Postgres 8 vs Postgres 7.4/cygwin Christopher Kings-Lynne
• 13:40   Re: Postgres 8 vs Postgres 7.4/cygwin Tom Lane
• 18:18   Speed with offset clause Yves Vindevogel
• 18:54   max_connections / shared_buffers / effective_cache_size questions Puddle
• 18:55   Re: Speed with offset clause hubert depesz lubaczewski
• 19:16   Re: max_connections / shared_buffers / effective_cache_size John A Meinel
• 19:22   Re: Speed with offset clause John A Meinel
• 19:26   Re: max_connections / shared_buffers / Rod Taylor
• 19:50   Performance - moving from oracle to postgresql Greg Maples
• 19:58   Re: max_connections / shared_buffers / effective_cache_size questions Puddle
• 20:19   Fwd: Speed with offset clause Yves Vindevogel
• 20:24   Re: Speed with offset clause Yves Vindevogel
• 20:34   Re: Speed with offset clause Yves Vindevogel
• 21:18   Re: Needed: Simplified guide to optimal memory configuration Todd Landfried
• 22:01   Re: Performance Tuning Article Dmitri Bichko
• 22:04   Re: Performance - moving from oracle to postgresql Rod Taylor
• 23:41   Re: parameterized LIKE does not use index Jim C. Nasby

25 June 2005

• 01:09   Re: Configurator project launched Greg Sabino Mullane
• 07:48   Re: Configurator project launched Andreas Pflug
• 10:47   Re: Performance - moving from oracle to postgresql Radu-Adrian Popescu
• 11:44   Re: Speed with offset clause Radu-Adrian Popescu

27 June 2005

• 11:20   Insert performance vs Table size Praveen Raja
• 11:31   Re: Insert performance vs Table size 李江华
• 11:40   Re: Insert performance vs Table size Jacques Caron
• 11:46   Re: Insert performance vs Table size Praveen Raja
• 12:05   Re: Insert performance vs Table size Jacques Caron
• 12:41   Re: Performance - moving from oracle to postgresql Merlin Moncure
• 13:38   PERFORMANCE ISSUE ODBC x LIBPQ C++ Application grupos
• 14:29   Re: PERFORMANCE ISSUE ODBC x LIBPQ C++ Application Merlin Moncure
• 14:46   Re: PERFORMANCE ISSUE ODBC x LIBPQ C++ Application Eric Lauzon
• 18:14   Re: [HACKERS] How two perform TPC-H test on postgresql-8.0.2 Merlin Moncure
• 18:15   Re: ETL optimization Bricklen Anderson
• 20:47   perl garbage collector Jean-Max Reymond
• 21:11   Re: perl garbage collector Vivek Khera
• 22:20   Poor index choice -- multiple indexes of the same columns Karl O. Pinc
• 22:27   Forcing use of a particular index Karl O. Pinc
• 22:35   Re: Poor index choice -- multiple indexes of the same columns Josh Berkus
• 22:41   Re: Forcing use of a particular index Jacques Caron
• 22:41   Performance analysis of plpgsql code Karl O. Pinc
• 23:33   Re: Performance analysis of plpgsql code Michael Fuhr

28 June 2005

• 01:05   Re: Performance analysis of plpgsql code Karl O. Pinc
• 01:15   Re: Performance analysis of plpgsql code Michael Glaesemann
• 01:25   Faster drives for WAL than for data? Leigh Dyer
• 01:34   Re: Performance analysis of plpgsql code Michael Fuhr
• 01:47   Re: Poor index choice -- multiple indexes of the same Karl O. Pinc
• 02:14   Re: Performance analysis of plpgsql code Karl O. Pinc
• 02:22   Re: Poor index choice -- multiple indexes of the same Karl O. Pinc
• 02:37   How can I speed up this function? David Mitchell
• 02:49   Re: Performance analysis of plpgsql code Michael Fuhr
• 03:03   Re: How can I speed up this function? Christopher Kings-Lynne
• 03:11   Re: How can I speed up this function? David Mitchell
• 03:19   Re: How can I speed up this function? Christopher Kings-Lynne
• 03:21   Re: How can I speed up this function? Keith Worthington
• 03:32   Re: How can I speed up this function? David Mitchell
• 03:35   Re: How can I speed up this function? David Mitchell
• 04:07   Re: How can I speed up this function? Gnanavel Shanmugam
• 04:30   LIKE search with ending % not optimized in v8 Aditya Damle
• 04:32   Re: How can I speed up this function? David Mitchell
• 04:44   How are text columns stored? Meetesh Karia
• 04:44   select distinct on varchar -- wild performance differences! Elliott Bennett
• 04:54   parameterized LIKE does not use index Kurt De Grave
• 04:55   Postgresql7.4.5 running slow on plpgsql function Chun Yit(Chronos)
• 05:06   index selection by query planner Rohit Gaddi
• 05:06   index selection by query planner Rohit Gaddi
• 05:08   Too slow querying a table of 15 million records kjelle@bingon.no
• 05:20   slow simple update? Colin Taylor
• 06:19   Re: Too slow querying a table of 15 million records Tobias Brox
• 06:19   Re: How are text columns stored? Tom Lane
• 06:36   Re: perl garbage collector Tom Lane
• 07:16   Re: How can I speed up this function? Gnanavel Shanmugam
• 07:21   Re: LIKE search with ending % not optimized in v8 Michael Fuhr
• 07:39   Re: How can I speed up this function? David Mitchell
• 07:57   Re: How can I speed up this function? Gnanavel Shanmugam
• 08:33   Re: How can I speed up this function? Klint Gore
• 09:31   Re: Poor index choice -- multiple indexes of the same columns Tom Lane
• 09:47   Re: Too slow querying a table of 15 million records John A Meinel
• 09:48   Re: Postgresql7.4.5 running slow on plpgsql function Michael Fuhr
• 10:21   Re: Insert performance vs Table size Praveen Raja
• 10:45   Re: Insert performance vs Table size Jacques Caron
• 10:54   Re: Too slow querying a table of 15 million records Christopher Kings-Lynne
• 14:35   tricky query Merlin Moncure
• 14:35   ... Erik Westland
• 15:16   Re: tricky query Bruno Wolff III
• 15:20   Re: tricky query John A Meinel
• 15:27   Réf. : tricky query bsimon@loxane.com
• 15:43   Re: Insert performance vs Table size Tom Lane
• 16:01   Re: tricky query John A Meinel
• 16:01   Re: tricky query Sam Mason
• 16:07   Re: tricky query John A Meinel
• 16:22   Re: tricky query Merlin Moncure
• 16:24   Re: tricky query Merlin Moncure
• 16:35   Re: tricky query Merlin Moncure
• 16:50   read block size Michael Stone
• 16:57   Re: tricky query Cosimo Streppone
• 17:07   Re: read block size John A Meinel
• 17:11   Re: Too slow querying a table of 15 million records PFC
• 17:27   Re: read block size Michael Stone
• 17:43   Re: Poor index choice -- multiple indexes of the same Karl O. Pinc
• 17:43   Re: tricky query John A Meinel
• 18:15   Re: Too slow querying a table of 15 million records Tom Lane
• 18:49   Re: tricky query Sam Mason
• 19:20   Re: perl garbage collector Jean-Max Reymond
• 19:41   Re: tricky query Cosimo Streppone
• 19:44   Re: tricky query John A Meinel
• 19:44   Re: tricky query Merlin Moncure
• 19:48   Re: tricky query Bruno Wolff III
• 19:52   Re: tricky query Merlin Moncure
• 20:39   Re: tricky query Sebastian Hennebrueder
• 20:39   optimized counting of web statistics Billy extyeightysix
• 20:44   Re: optimized counting of web statistics Billy extyeightysix
• 21:55   Re: optimized counting of web statistics Matthew Nuzum
• 22:10   Re: perl garbage collector Jean-Max Reymond

29 June 2005

• 00:20   Re: optimized counting of web statistics Rudi Starcevic
• 02:55   Re: optimized counting of web statistics Matthew Nuzum
• 06:37   Re: tricky query Dawid Kuroczko
• 08:49   could not receive data from client: Connection timed out Error Shay Kachlon
• 09:04   Re: could not receive data from client: Connection timed out Error Martin Fandel
• 12:50   Re: Postgresql7.4.5 running slow on plpgsql function Michael Fuhr
• 15:10   Exclusive lock question Emil Briggs
• 15:27   Re: Exclusive lock question Tom Lane

30 June 2005

• 07:24   Vacuum becomes slow Martin Lesser
• 10:31   ODBC driver over network very slow Milan Sekanina
• 12:38   Re: slow simple update? philippe ventrillon
• 13:31   Re: Vacuum becomes slow Tom Lane
• 13:48   Re: ODBC driver over network very slow Tom Lane
• 14:10   Re: ODBC driver over network very slow Merlin Moncure
• 14:47   Re: ODBC driver over network very slow Kevin Grittner
• 15:42   start time very high Jean-Max Reymond
• 16:23   Re: start time very high Jean-Max Reymond
• 18:59   Re: start time very high Josh Berkus
• 21:01   Re: start time very high Tom Lane
• 22:24   ported application having performance issues John Mendenhall
• 22:35   Re: ported application having performance issues Joshua D. Drake
• 22:43   Re: ported application having performance issues Tom Lane
• 23:58   Re: ported application having performance issues John Mendenhall