Mailing lists [pgsql-performance]

1 March 2005

• 00:24   wal_sync_methods Stefan Hans
• 00:47   Re: High end server and storage for a PostgreSQL OLTP system Cosimo Streppone
• 01:16   Re: High end server and storage for a PostgreSQL OLTP system Tom Lane
• 02:59   Inheritence versus delete from Sven Willenberger
• 04:09   Re: Inheritence versus delete from Tom Lane
• 04:41   Re: Inheritence versus delete from John Arbash Meinel
• 08:27   Re: seq scan cache vs. index cache smackdown PFC
• 12:34   multi billion row tables: possible or insane? Ramon Bastiaans
• 16:35   Re: multi billion row tables: possible or insane? Jeff
• 17:01   Re: multi billion row tables: possible or insane? Markus Schaber
• 18:19   Re: multi billion row tables: possible or insane? John Arbash Meinel
• 18:40   Re: multi billion row tables: possible or insane? Vig, Sandor (G/FI-2)
• 18:52   Re: multi billion row tables: possible or insane? John Arbash Meinel
• 18:54   Re: multi billion row tables: possible or insane? Andras Kadinger
• 18:58   Re: multi billion row tables: possible or insane? Alan Stange
• 19:27   Re: Inheritence versus delete from Sven Willenberger
• 19:27   Re: multi billion row tables: possible or insane? Markus Schaber
• 19:41   Re: Inheritence versus delete from John Arbash Meinel
• 19:45   Re: multi billion row tables: possible or insane? John Arbash Meinel

2 March 2005

• 03:44   Confusion about locales and 'like' indexes Dan Harris
• 03:58   Re: Inheritence versus delete from Gaetano Mendola
• 04:07   Re: multi billion row tables: possible or insane? Josh Berkus
• 04:42   Re: Confusion about locales and 'like' indexes Tom Lane
• 06:17   Re: multi billion row tables: possible or insane? Alan Stange
• 09:00   What is the postgres sql command for last_user_id ??? amrit@health2.moph.go.th
• 09:00   Re: multi billion row tables: possible or insane? Thomas Ganss
• 09:51   Help with tuning this query Ken Egervari
• 11:13   Re: What is the postgres sql command for last_user_id ??? Michael Fuhr
• 11:58   Re: Help with tuning this query Richard Huxton
• 19:13   Re: Help with tuning this query Bricklen Anderson
• 19:18   Re: Help with tuning this query Bruce Momjian
• 19:57   Re: Help with tuning this query John Arbash Meinel
• 20:23   Re: Help with tuning this query Ken Egervari
• 20:38   Re: Help with tuning this query John Arbash Meinel
• 20:52   Performance tradeoff Shawn Chisholm
• 21:11   Re: Help with tuning this query Ragnar Hafstað
• 21:28   Re: Help with tuning this query Ken Egervari
• 21:47   Re: Help with tuning this query Ragnar Hafstað
• 21:56   Re: Help with tuning this query Ken Egervari
• 23:06   Re: Help with tuning this query (with explain analyze finally) Ken Egervari
• 23:29   Re: Help with tuning this query (with explain analyze finally) Tom Lane
• 23:38   Re: Help with tuning this query (with explain analyze finally) Ken Egervari

3 March 2005

• 01:29   Re: Help with tuning this query (with explain analyze finally) Tom Lane
• 02:01   Re: Help with tuning this query (with explain analyze finally) Dave Held
• 02:25   Re: Help with tuning this query (with explain analyze finally) John A Meinel
• 04:20   Re: Help with tuning this query (with explain analyze finally) Ken Egervari
• 05:51   Re: Help with tuning this query (more musings) Ken Egervari
• 05:52   Re: Help with tuning this query (Some musings) Ken Egervari
• 07:30   Re: Help with tuning this query Mark Kirkwood
• 08:05   Re: Help with tuning this query (more musings) John A Meinel
• 08:32   Re: Performance tradeoff Josh Berkus
• 08:37   Re: Help with tuning this query Josh Berkus
• 08:53   Re: Help with tuning this query (with explain analyze finally) Josh Berkus
• 09:35   Re: Help with tuning this query (more musings) Ken Egervari
• 09:59   Re: Help with tuning this query (with explain analyze finally) Ken Egervari
• 10:06   Re: Help with tuning this query (more musings) Richard Huxton
• 12:21   Re: Help with tuning this query (with explain analyze finally) Ken Egervari
• 19:38   name search query speed Jeremiah Jahn
• 20:00   Re: name search query speed Ken Egervari
• 20:24   Re: name search query speed Jeremiah Jahn
• 20:36   Re: Help with tuning this query (with explain analyze finally) Josh Berkus
• 20:45   Re: name search query speed Josh Berkus
• 20:46   Re: name search query speed John A Meinel
• 21:37   Re: name search query speed Markus Schaber
• 23:14   Re: name search query speed Jeremiah Jahn
• 23:19   Re: name search query speed Jeremiah Jahn
• 23:26   Re: name search query speed Dave Held
• 23:47   Re: name search query speed Jeremiah Jahn

4 March 2005

• 00:37   Re: name search query speed John Arbash Meinel
• 01:03   Re: name search query speed Markus Schaber
• 02:42   Re: Help with tuning this query (with explain analyze finally) Ken Egervari
• 03:22   Re: Help with tuning this query (with explain analyze finally) John Arbash Meinel
• 05:58   Re: name search query speed William Yu
• 08:22   Re: Help with tuning this query (with explain analyze finally) Ken Egervari
• 14:26   Query's fast standalone - slow as a subquery. Ron Mayer
• 18:23   Re: Query's fast standalone - slow as a subquery. Tom Lane
• 18:56   Re: Help with tuning this query (with explain analyze finally) Richard Huxton
• 19:36   Re: Help with tuning this query (with explain analyze finally) Ken
• 19:57   Re: Help with tuning this query (with explain analyze finally) John Arbash Meinel
• 20:07   Re: Help with tuning this query (with explain analyze finally) John Arbash Meinel
• 20:53   Select in FOR LOOP Performance Charles Joseph
• 21:29   Re: Select in FOR LOOP Performance Tom Lane
• 21:30   Re: Help with tuning this query (with explain analyze finally) Josh Berkus
• 22:56   Re: Help with tuning this query (with explain analyze finally) John A Meinel
• 23:59   MAIN vs. PLAIN Dave Held

5 March 2005

• 00:56   Re: name search query speed stig erikson
• 00:57   Re: What is the postgres sql command for last_user_id ??? stig erikson
• 01:07   Re: multi billion row tables: possible or insane? Jim C. Nasby
• 03:16   Re: multi billion row tables: possible or insane? Alex Turner
• 07:34   Re: MAIN vs. PLAIN Tom Lane
• 21:39   Query Optimization - Hash Join estimate off? mark.lubratt@indeq.com

7 March 2005

• 09:33   How to Partition? xsk
• 11:55   Re: [pgsql-hackers-win32] Help with tuning this query (with explain analyze finally) Magnus Hagander
• 17:11   Re: [pgsql-hackers-win32] Help with tuning this query (with explain analyze finally) Tom Lane
• 17:46   Re: [pgsql-hackers-win32] Help with tuning this query (with explain analyze finally) Tom Lane
• 17:47   Re: [pgsql-hackers-win32] Help with tuning this query (with explain analyze finally) Magnus Hagander
• 17:49   Tuning, configuration for 7.3.5 on a Sun E4500 
• 19:35   Re: [pgsql-hackers-win32] Help with tuning this query (with John A Meinel
• 20:03   Re: [pgsql-hackers-win32] Help with tuning this query (with explain analyze finally) Tom Lane
• 20:04   Help trying to tune query that executes 40x slower than in SqlServer Hugo Ferreira
• 20:24   Re: [pgsql-hackers-win32] Help with tuning this query (with John A Meinel
• 20:28   Re: Help trying to tune query that executes 40x slower than in SqlServer Josh Berkus
• 20:31   Re: Tuning, configuration for 7.3.5 on a Sun E4500 Josh Berkus
• 20:45   Re: Help trying to tune query that executes 40x slower than in SqlServer Hugo Ferreira
• 21:02   Re: Help trying to tune query that executes 40x slower than in SqlServer Tom Lane
• 21:05   Re: [pgsql-hackers-win32] Help with tuning this query (with Greg Stark

8 March 2005

• 01:30   Re: [pgsql-hackers-win32] Help with tuning this query (with Dave Held
• 01:34   Re: [pgsql-hackers-win32] Help with tuning this query (with explain analyze finally) Dave Held
• 01:48   Re: [pgsql-hackers-win32] Help with tuning this query (with John A Meinel
• 01:56   Re: [pgsql-hackers-win32] Help with tuning this query (with Tom Lane
• 02:15   Re: [pgsql-hackers-win32] Help with tuning this query (with Greg Stark
• 03:12   Re: [pgsql-hackers-win32] Help with tuning this query (with Dave Held
• 03:29   Re: [pgsql-hackers-win32] Help with tuning this query (with Dave Held
• 04:38   Re: [pgsql-hackers-win32] Help with tuning this query (with Steinar H. Gunderson
• 05:02   Re: [pgsql-hackers-win32] Help with tuning this query (with Tom Lane
• 05:06   Re: [pgsql-hackers-win32] Help with tuning this query (with Steinar H. Gunderson
• 06:53   Re: [pgsql-hackers-win32] Help with tuning this query (with PFC
• 07:25   adding 'limit' leads to very slow query Michael McFarland
• 07:25   Help with slow running query jesse d
• 07:26   Re: [pgsql-hackers-win32] Help with tuning this query (with Dave Page
• 07:26   performance problems Michael Zoephel
• 07:36   Re: [pgsql-hackers-win32] Help with tuning this query (with John A Meinel
• 07:46   Re: adding 'limit' leads to very slow query John A Meinel
• 10:03   Re: adding 'limit' leads to very slow query Stephan Szabo
• 10:47   Re: Tuning, configuration for 7.3.5 on a Sun E4500 
• 12:05   Re: [pgsql-hackers-win32] Help with tuning this query (with Magnus Hagander
• 13:32   bad plan Gaetano Mendola
• 14:40   Re: bad plan Richard Huxton
• 15:20   pl/pgsql faster than raw SQL? Markus Bertheau ☭
• 15:22   Re: bad plan Gaetano Mendola
• 15:48   Re: pl/pgsql faster than raw SQL? Richard Huxton
• 16:20   Re: bad plan Richard Huxton
• 18:10   Re: pl/pgsql faster than raw SQL? John A Meinel
• 20:11   Re: Tuning, configuration for 7.3.5 on a Sun E4500 Josh Berkus
• 21:35   Re: bad plan Gaetano Mendola
• 21:36   index scan on =, but not < ? Rick Schumeyer
• 21:52   Re: index scan on =, but not < ? Thomas F.O'Connell
• 22:01   Re: index scan on =, but not < ? John Arbash Meinel
• 22:02   Re: index scan on =, but not < ? Rick Schumeyer
• 22:05   Re: index scan on =, but not < ? Dennis Bjorklund
• 22:20   Re: bad plan Richard Huxton
• 23:01   Re: bad plan Tom Lane
• 23:14   Why would writes to pgsql_tmp bottleneck at 1mb/s? Josh Berkus
• 23:25   Re: bad plan Richard Huxton
• 23:42   Re: bad plan Tom Lane

9 March 2005

• 03:04   Query Optimization James G Wilkinson
• 03:13   Re: Why would writes to pgsql_tmp bottleneck at 1mb/s? Josh Berkus
• 03:40   Re: Why would writes to pgsql_tmp bottleneck at 1mb/s? Josh Berkus
• 03:47   Re: bad plan Gaetano Mendola
• 03:58   Re: pl/pgsql faster than raw SQL? Gaetano Mendola
• 04:02   vacuum full, why multiple times ? Gaetano Mendola
• 04:13   Re: Why would writes to pgsql_tmp bottleneck at 1mb/s? Aaron Birkland
• 04:28   Re: pl/pgsql faster than raw SQL? John A Meinel
• 04:46   Re: Query Optimization John A Meinel
• 05:15   Re: vacuum full, why multiple times ? Michael Fuhr
• 06:07   64bit Opteron multi drive raid. Help with best config settings David B
• 06:49   Re: 64bit Opteron multi drive raid. Help with best config Karim Nassar
• 07:22   Re: index scan on =, but not < ? Bruno Wolff III
• 07:28   Re: Why would writes to pgsql_tmp bottleneck at 1mb/s? Tom Lane
• 07:33   Re: Why would writes to pgsql_tmp bottleneck at 1mb/s? Josh Berkus
• 07:38   Re: Why would writes to pgsql_tmp bottleneck at 1mb/s? Tom Lane
• 07:55   Re: index scan on =, but not < ? Jim C. Nasby
• 08:04   Re: index scan on =, but not < ? Bruno Wolff III
• 09:56   Re: Why would writes to pgsql_tmp bottleneck at 1mb/s? Josh Berkus
• 14:21   Re: pl/pgsql faster than raw SQL? Gaetano Mendola
• 14:27   Re: vacuum full, why multiple times ? Gaetano Mendola
• 15:08   Re: Help trying to tune query that executes 40x slower than in SqlServer Hugo Ferreira
• 15:30   Re: vacuum full, why multiple times ? Richard Huxton
• 17:30   Re: vacuum full, why multiple times ? Gaetano Mendola
• 18:17   Re: vacuum full, why multiple times ? Tom Lane
• 19:17   Re: vacuum full, why multiple times ? Gaetano Mendola
• 20:22   Re: index scan on =, but not < ? Jim C. Nasby
• 20:25   How to speed up tsearch2 indexing Werner Bohl
• 20:41   Re: How to speed up tsearch2 indexing Oleg Bartunov
• 23:20   Re: How to speed up tsearch2 indexing Werner Bohl
• 23:27   Re: How to speed up tsearch2 indexing Oleg Bartunov

10 March 2005

• 01:08   Re: Help trying to tune query that executes 40x slower than in SqlServer Russell Smith
• 03:06   Re: index scan on =, but not < ? David Brown
• 03:24   Re: index scan on =, but not < ? David Brown
• 04:59   Re: Help trying to tune query that executes 40x slower Jim Johannsen
• 08:29   Multi-line requests in COPY ... FROM STDIN Mischa
• 10:41   What's better: Raid 0 or disk for seperate pg_xlog Karim Nassar
• 17:14   Re: What's better: Raid 0 or disk for seperate pg_xlog David Brown
• 18:27   Re: What's better: Raid 0 or disk for seperate pg_xlog John A Meinel
• 19:41   Re: What's better: Raid 0 or disk for seperate pg_xlog Mario Weilguni
• 22:47   Re: What's better: Raid 0 or disk for seperate pg_xlog Karim Nassar
• 22:56   Re: What's better: Raid 0 or disk for seperate pg_xlog John Arbash Meinel

11 March 2005

• 11:06   Re: What's better: Raid 0 or disk for seperate pg_xlog Richard Huxton
• 14:53   Statistics not working?? Hugo Ferreira
• 15:03   Re: Statistics not working?? Oleg Bartunov
• 16:05   Re: [GENERAL] more execution time Richard Huxton
• 16:45   What is the number of rows in explain? Joost Kraaijeveld
• 17:43   Re: What is the number of rows in explain? John A Meinel
• 18:41   Performance tuning Jacques Caron
• 21:48   Query performance Lou O'Quin
• 22:10   Re: Query performance Tom Lane
• 22:38   Re: Query performance Lou O'Quin
• 23:14   Questions about 2 databases. jelle
• 23:21   Re: Query performance Tom Lane
• 23:33   Re: Questions about 2 databases. Tom Lane
• 23:35   Re: Query performance Lou O'Quin
• 23:53   Re: Questions about 2 databases. Richard_D_Levine@raytheon.com

12 March 2005

• 00:13   Postgres on RAID5 Arshavir Grigorian
• 00:47   Re: Questions about 2 databases. jelle
• 01:07   Re: Postgres on RAID5 Tom Lane
• 01:29   Re: Postgres on RAID5 Arshavir Grigorian
• 01:36   Re: Postgres on RAID5 Alvaro Herrera
• 01:37   Re: Postgres on RAID5 Tom Lane
• 03:23   Re: Postgres on RAID5 Arshavir Grigorian
• 04:27   Re: Postgres on RAID5 Josh Berkus
• 05:47   Re: Questions about 2 databases. PFC
• 05:52   Re: Postgres on RAID5 PFC
• 06:50   Re: Postgres on RAID5 Alex Turner
• 07:04   Re: Postgres on RAID5 Joshua D. Drake
• 16:08   One tuple per transaction Tambet Matiisen

13 March 2005

• 01:06   Re: One tuple per transaction Josh Berkus
• 08:40   Index use and slow queries Tom Pfeifer
• 09:08   Re: Index use and slow queries Russell Smith
• 09:26   Re: Index use and slow queries Tom Lane
• 18:32   How to read query plan Miroslav Šulc
• 19:24   Re: How to read query plan John Arbash Meinel
• 19:51   Re: How to read query plan Ragnar Hafstað
• 20:10   Re: How to read query plan Miroslav Šulc
• 20:21   Re: One tuple per transaction Tambet Matiisen
• 20:23   Re: How to read query plan Miroslav Šulc
• 20:30   Re: How to read query plan John Arbash Meinel
• 20:50   Re: How to read query plan John Arbash Meinel
• 21:10   Re: How to read query plan Miroslav Šulc
• 22:07   Re: How to read query plan Miroslav Šulc
• 22:16   Re: How to read query plan Tom Lane
• 22:26   Re: How to read query plan John Arbash Meinel
• 22:44   Re: How to read query plan Miroslav Šulc
• 22:51   Re: How to read query plan Miroslav Šulc
• 22:54   Re: How to read query plan Tom Lane
• 23:03   Re: How to read query plan Miroslav Šulc
• 23:26   Re: How to read query plan Tom Lane

14 March 2005

• 03:08   Re: How to read query plan Tom Lane
• 05:20   Re: One tuple per transaction Qingqing Zhou
• 05:20   Re: cpu_tuple_cost Daniel Schuchardt
• 05:20   Re: Postgres on RAID5 Alexander Kirpa
• 05:20   cpu_tuple_cost Daniel Schuchardt
• 05:23   Re: adding 'limit' leads to very slow query Michael McFarland
• 05:23   Postgres on RAID5 Arshavir Grigorian
• 05:23   more execution time ALÝ ÇELÝK
• 07:36   Re: Postgres on RAID5 Greg Stark
• 08:00   Re: [HACKERS] How to read query plan Tom Lane
• 09:29   Re: cpu_tuple_cost Tom Lane
• 10:16   column name is "LIMIT" Gourish Singbal
• 10:22   Re: column name is "LIMIT" Christopher Kings-Lynne
• 10:25   Re: column name is "LIMIT" Russell Smith
• 11:43   Re: How to read query plan Miroslav Šulc
• 11:44   Re: [HACKERS] How to read query plan Miroslav Šulc
• 11:51   Re: column name is "LIMIT" Gourish Singbal
• 11:55   Re: column name is "LIMIT" Christopher Kings-Lynne
• 11:58   Re: How to read query plan Miroslav Šulc
• 12:02   Re: How to read query plan Christopher Kings-Lynne
• 12:08   Re: How to read query plan PFC
• 12:09   Re: How to read query plan Miroslav Šulc
• 12:17   Re: How to read query plan Miroslav Šulc
• 12:41   Re: Performance tuning Richard Huxton
• 17:51   Re: adding 'limit' leads to very slow query Stephan Szabo
• 18:03   Re: How to read query plan Tom Lane
• 18:04   Re: [HACKERS] How to read query plan Tom Lane
• 18:10   Re: How to read query plan Harald Fuchs
• 18:21   Re: How to read query plan Miroslav Šulc
• 18:29   Re: How to read query plan Miroslav Šulc
• 18:54   Re: How to read query plan John Arbash Meinel
• 18:59   Re: How to read query plan Greg Stark
• 19:23   Re: How to read query plan Tom Lane
• 19:33   Re: How to read query plan Miroslav Šulc
• 19:36   Re: How to read query plan John Arbash Meinel
• 19:50   Bad Performance[2] Gaetano Mendola
• 19:50   Re: How to read query plan Kaloyan Iliev Iliev
• 20:08   Re: How to read query plan Miroslav Šulc
• 20:24   Avoiding tuple construction/deconstruction during joining Tom Lane
• 21:29   Re: column name is "LIMIT" Robert Treat
• 21:55   Re: Postgres on RAID5 Arshavir Grigorian
• 21:56   Re: column name is "LIMIT" Jan Wieck
• 22:12   Re: Avoiding tuple construction/deconstruction during joining Miroslav Šulc
• 22:22   Re: Avoiding tuple construction/deconstruction during joining Tom Lane
• 22:28   Re: column name is "LIMIT" Bryan Encina
• 22:30   Re: column name is "LIMIT" Tom Lane
• 22:32   Re: Avoiding tuple construction/deconstruction during joining Miroslav Šulc
• 22:53   Re: Postgres on RAID5 Alex Turner
• 23:17   Re: Postgres on RAID5 Greg Stark
• 23:54   Re: Postgres on RAID5 Arshavir Grigorian

15 March 2005

• 00:04   Re: Postgres on RAID5 Arshavir Grigorian
• 00:11   Re: Postgres on RAID5 Jim Buttafuoco
• 00:18   Re: Postgres on RAID5 Merlin Moncure
• 00:31   Re: Postgres on RAID5 Alex Turner
• 00:44   Re: Postgres on RAID5 Alex Turner
• 02:16   Re: column name is "LIMIT" Jan Wieck
• 05:05   Re: cpu_tuple_cost Greg Sabino Mullane
• 05:18   Re: cpu_tuple_cost Bruce Momjian
• 05:23   Re: cpu_tuple_cost Tom Lane
• 08:30   Re: cpu_tuple_cost Gregory Stark
• 09:11   Re: cpu_tuple_cost Josh Berkus
• 12:01   Re: One tuple per transaction Tambet Matiisen
• 12:37   Re: One tuple per transaction Richard Huxton
• 13:24   Re: One tuple per transaction Tambet Matiisen
• 15:35   Re: Changing the random_page_cost default (was: cpu_tuple_cost) Greg Sabino Mullane
• 16:31   Re: Changing the random_page_cost default (was: cpu_tuple_cost) Jeff Hoffmann
• 16:44   interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync Chris Mair
• 16:52   Re: interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync Magnus Hagander
• 16:55   Re: interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync Bruce Momjian
• 18:24   Re: Changing the random_page_cost default (was: cpu_tuple_cost) Tom Lane
• 18:25   Slow loads when indexes added. Stef
• 20:17   Re: Avoiding tuple construction/deconstruction during joining PFC
• 22:53   Re: Avoiding tuple construction/deconstruction during joining PFC

16 March 2005

• 00:21   Performance problem on delete from for 10k rows. May takes 20 minutes through JDBC interface David Gagnon
• 00:47   Re: One tuple per transaction Robert Treat
• 01:44   Re: Changing the random_page_cost default (was: Mark Kirkwood
• 02:38   Re: Performance problem on delete from for 10k rows. May takes 20 minutes through JDBC interface Michael Fuhr
• 02:41   Re: cpu_tuple_cost David Brown
• 02:51   Re: Performance problem on delete from for 10k rows. Rod Taylor
• 02:51   Re: One tuple per transaction Tom Lane
• 03:06   Re: One tuple per transaction Alvaro Herrera
• 04:03   Re: Changing the random_page_cost default (was: cpu_tuple_cost) Greg Sabino Mullane
• 07:45   Re: One tuple per transaction Tom Lane
• 10:24   Re: cpu_tuple_cost Greg Stark
• 11:00   Re: Slow loads when indexes added. Stef
• 12:42   Re: cpu_tuple_cost Magnus Hagander
• 16:17   Re: Performance problem on delete from for 10k rows. May David Gagnon
• 17:06   Re: Performance problem on delete from for 10k rows. May Dave Cramer
• 17:23   Re: Performance problem on delete from for 10k rows. May David Gagnon
• 17:35   Re: Performance problem on delete from for 10k rows. May Alvaro Herrera
• 17:56   Re: Performance problem on delete from for 10k rows. May Dave Cramer
• 18:11   Re: Performance problem on delete from for 10k rows. May David Gagnon
• 18:43   Re: cpu_tuple_cost Greg Stark
• 19:09   multi-column index Daniel Crisan
• 19:28   Re: Performance problem on delete from for 10k rows. May Stephan Szabo
• 20:00   Re: Performance problem on delete from for 10k rows. May David Gagnon
• 20:59   Speeding up select distinct Laurent Martelli
• 21:04   Re: cpu_tuple_cost Josh Berkus
• 21:07   Re: Speeding up select distinct PFC
• 21:10   Re: multi-column index Josh Berkus
• 21:11   Re: Speeding up select distinct Rod Taylor
• 21:19   Re: Speeding up select distinct Merlin Moncure
• 21:30   Re: Speeding up select distinct Laurent Martelli
• 21:31   Re: Speeding up select distinct Laurent Martelli
• 21:38   Re: Speeding up select distinct Laurent Martelli
• 21:41   Re: Speeding up select distinct Rod Taylor
• 21:57   Re: Speeding up select distinct Merlin Moncure
• 22:46   Re: cpu_tuple_cost Greg Stark
• 23:10   Help to find out problem with joined tables Rodrigo Moreno
• 23:35   Re: Performance problem on delete from for 10k rows. May Stephan Szabo
• 23:42   Re: cpu_tuple_cost Tom Lane

17 March 2005

• 03:26   Re: multi-column index David Brown
• 05:29   Re: Speeding up select distinct Greg Stark
• 06:19   Re: multi-column index Tom Lane
• 07:42   Re: Help to find out problem with joined tables Michael Fuhr
• 09:16   Join method influences scan method? mark.lubratt@indeq.com
• 09:41   Re: Join method influences scan method? Tom Lane
• 11:09   Re: index scan on =, but not < ? Manfred Koizar
• 11:18   Re: cpu_tuple_cost Manfred Koizar
• 11:48   Re: multi-column index Manfred Koizar
• 11:55   Re: multi-column index Christopher Kings-Lynne
• 14:15   Re: multi-column index Manfred Koizar
• 15:03   2 rows expected on a primary key Gaetano Mendola
• 16:15   TOP 10 SQL commands and more Ales Vojacek
• 17:00   queries on huge tables Lending, Rune
• 18:56   Building a DB with performance in mind Alexander Ranaldi
• 19:09   Re: Building a DB with performance in mind Steinar H. Gunderson
• 19:21   Re: Building a DB with performance in mind John Arbash Meinel
• 20:10   RES: Help to find out problem with joined tables Rodrigo Moreno
• 20:48   Re: TOP 10 SQL commands and more Josh Berkus
• 20:55   Re: cpu_tuple_cost Josh Berkus
• 20:58   Re: cpu_tuple_cost Tom Lane
• 21:15   Re: multi-column index Tom Lane
• 21:27   Re: cpu_tuple_cost Michael Fuhr

18 March 2005

• 12:10   Re: One tuple per transaction Hannu Krosing
• 13:31   Re: multi-column index Manfred Koizar
• 13:40   Re: multi-column index Manfred Koizar

19 March 2005

• 16:16   Re: queries on huge tables Mike Rylander
• 23:02   What needs to be done for real Partitioning? Josh Berkus
• 23:49   Re: What needs to be done for real Partitioning? Tom Lane

20 March 2005

• 01:25   Re: What needs to be done for real Partitioning? PFC
• 01:52   Re: What needs to be done for real Partitioning? Stacy White
• 01:56   Re: What needs to be done for real Partitioning? Alvaro Herrera
• 02:04   Re: What needs to be done for real Partitioning? Tom Lane
• 02:30   Re: What needs to be done for real Partitioning? Josh Berkus
• 02:35   Re: What needs to be done for real Partitioning? Steve Atkins
• 02:52   Re: What needs to be done for real Partitioning? PFC
• 03:03   Re: What needs to be done for real Partitioning? Tom Lane
• 03:06   Re: What needs to be done for real Partitioning? Tom Lane
• 03:16   Re: What needs to be done for real Partitioning? Steinar H. Gunderson
• 07:29   Re: What needs to be done for real Partitioning? Alvaro Herrera
• 07:43   Re: What needs to be done for real Partitioning? Rod Taylor
• 07:48   Re: What needs to be done for real Partitioning? Tom Lane
• 09:14   Re: What needs to be done for real Partitioning? Greg Stark
• 13:20   Re: What needs to be done for real Partitioning? PFC
• 20:58   Re: What needs to be done for real Partitioning? Tom Lane
• 22:58   Re: What needs to be done for real Partitioning? Stacy White
• 23:04   Re: What needs to be done for real Partitioning? Josh Berkus
• 23:23   Re: What needs to be done for real Partitioning? Oleg Bartunov

21 March 2005

• 01:18   Re: What needs to be done for real Partitioning? Greg Stark
• 02:02   Re: What needs to be done for real Partitioning? Tom Lane
• 02:05   Re: What needs to be done for real Partitioning? Tom Lane
• 02:15   Re: What needs to be done for real Partitioning? Greg Stark
• 07:01   Re: What needs to be done for real Partitioning? Greg Stark
• 07:04   View vs function Keith Worthington
• 07:07   Re: What needs to be done for real Partitioning? Greg Stark
• 07:41   Re: View vs function Bruno Wolff III
• 07:46   Re: cpu_tuple_cost Daniel Schuchardt
• 07:46   Re: Postgres on RAID5 David Dougall
• 07:47   Effect of Stripe Size (was Postgres on RAID5) Ruth Ivimey-Cook
• 07:48   Re: Postgres on RAID5 Michael Tokarev
• 07:49   Which one is faster: one way reading ="single pass reading" Rosny
• 07:49   Re: interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync Qingqing Zhou
• 07:49   Hardware impact on performances Camille Chafer
• 07:50   Re: Questions about 2 databases. Mirko Zeibig
• 07:51   Re: Postgres on RAID5 Michael Tokarev
• 07:52   Re: column name is "LIMIT" Qingqing Zhou
• 07:52   Re: Postgres on RAID5 Guy
• 07:52   Re: Postgres on RAID5 (possible sync blocking read type David Greaves
• 08:13   Re: What needs to be done for real Partitioning? Stacy White
• 08:13   Re: View vs function Neil Conway
• 08:38   Re: What needs to be done for real Partitioning? Stacy White
• 09:40   Re: View vs function Tom Lane
• 12:55   Re: Hardware impact on performances Richard Huxton
• 13:06   What about utility to calculate planner cost constants? Tambet Matiisen
• 17:59   Re: column name is "LIMIT" Jan Wieck
• 19:30   Re: column name is "LIMIT" Tom Lane
• 20:51   Re: What about utility to calculate planner cost constants? Josh Berkus
• 20:55   Re: What needs to be done for real Partitioning? Josh Berkus
• 21:18   Re: What about utility to calculate planner cost constants? Thomas F.O'Connell

22 March 2005

• 01:07   Re: What needs to be done for real Partitioning? Jim C. Nasby
• 01:11   Re: What needs to be done for real Partitioning? Jim C. Nasby
• 02:44   Re: What about utility to calculate planner cost constants? Josh Berkus
• 02:51   Re: What needs to be done for real Partitioning? Jim C. Nasby
• 07:43   Re: What about utility to calculate planner cost constants? Greg Stark
• 11:35   Re: What needs to be done for real Partitioning? Simon Riggs
• 12:23   best practices with index on varchar column Layet Benjamin
• 12:49   Re: best practices with index on varchar column Dawid Kuroczko
• 12:58   Re: What about utility to calculate planner cost constants? Dawid Kuroczko
• 13:49   Re: best practices with index on varchar column PFC
• 14:29   Re: What needs to be done for real Partitioning? Hannu Krosing
• 14:29   Re: What needs to be done for real Partitioning? Hannu Krosing
• 14:29   Re: What needs to be done for real Partitioning? Hannu Krosing
• 14:29   Re: What needs to be done for real Partitioning? Hannu Krosing
• 14:33   Re: What needs to be done for real Partitioning? Hannu Krosing
• 14:56   Re: What about utility to calculate planner cost constants? Richard Huxton
• 15:28   Tsearch2 performance on big database Rick Jansen
• 15:36   Re: Tsearch2 performance on big database Oleg Bartunov
• 15:48   Re: Tsearch2 performance on big database Mike Rylander
• 16:10   Re: What needs to be done for real Partitioning? Alvaro Herrera
• 16:24   Re: Tsearch2 performance on big database Oleg Bartunov
• 16:25   Re: Tsearch2 performance on big database Rick Jansen
• 16:50   Re: What about utility to calculate planner cost constants? Christopher Browne
• 17:56   Planner issue Alex Turner
• 18:00   Re: What about utility to calculate planner cost constants? Bruno Wolff III
• 18:30   Re: Tsearch2 performance on big database Mike Rylander
• 18:45   Re: Tsearch2 performance on big database Oleg Bartunov
• 18:59   Re: What needs to be done for real Partitioning? Hannu Krosing
• 19:06   Re: Tsearch2 performance on big database Rick Jansen
• 19:20   Re: What about utility to calculate planner cost constants? Greg Stark
• 19:23   Re: Planner issue Joshua D. Drake
• 19:38   Re: Tsearch2 performance on big database Oleg Bartunov
• 20:02   Re: What needs to be done for real Partitioning? Josh Berkus
• 20:30   Re: What about utility to calculate planner cost constants? Greg Stark
• 20:53   Re: What about utility to calculate planner cost constants? Richard Huxton
• 21:08   Re: best practices with index on varchar column Tom Lane
• 21:09   CPU 0.1% IOWAIT 99% for decisonnal queries Patrick Vedrines
• 21:29   Re: CPU 0.1% IOWAIT 99% for decisonnal queries Gustavo F Nobrega - Planae
• 21:34   Re: What about utility to calculate planner cost constants? Tom Lane
• 21:51   Re: [ADMIN] Too slow Thomas F.O'Connell
• 21:57   Re: CPU 0.1% IOWAIT 99% for decisonnal queries Richard Huxton
• 21:57   Re: What about utility to calculate planner cost constants? Tom Lane
• 22:36   Re: Planner issue Alex Turner
• 23:07   Re: Planner issue Ragnar Hafstað
• 23:44   PostgreSQL on Solaris 8 and ufs Brandon Metcalf

23 March 2005

• 00:02   Re: PostgreSQL on Solaris 8 and ufs Alan Stange
• 00:03   Re: PostgreSQL on Solaris 8 and ufs Sven Willenberger
• 00:07   Re: PostgreSQL on Solaris 8 and ufs Brandon Metcalf
• 00:23   Re: PostgreSQL on Solaris 8 and ufs Brandon Metcalf
• 00:26   Re: PostgreSQL on Solaris 8 and ufs Mark Kirkwood
• 00:28   Re: What about utility to calculate planner cost constants? Greg Stark
• 00:49   Re: What about utility to calculate planner cost constants? Tom Lane
• 01:17   Re: What about utility to calculate planner cost constants? Dave Held
• 01:19   Re: CPU 0.1% IOWAIT 99% for decisonnal queries Simon Riggs
• 01:35   Re: What about utility to calculate planner cost constants? Dave Held
• 01:58   Re: What about utility to calculate planner cost constants? Ron Mayer
• 02:08   Re: Planner issue Ron Mayer
• 02:09   Re: Planner issue Ron Mayer
• 03:04   Re: What about utility to calculate planner cost constants? Chris Browne
• 04:25   Re: What needs to be done for real Partitioning? Bruce Momjian
• 04:32   Hardware questions Junaili Lie
• 05:17   Re: Hardware questions Karim Nassar
• 11:52   Re: Tsearch2 performance on big database Rick Jansen
• 12:16   Re: best practices with index on varchar column Michael Ryan S. Puncia
• 12:35   Re: best practices with index on varchar column Dawid Kuroczko
• 12:40   Re: Tsearch2 performance on big database Oleg Bartunov
• 13:03   SQL function inlining (was: View vs function) Tambet Matiisen
• 14:31   Re: best practices with index on varchar column Richard Huxton
• 19:55   Re: SQL function inlining (was: View vs function) Tom Lane
• 19:58   Re: PostgreSQL on Solaris 8 and ufs Andrew Sullivan
• 20:16   Re: PostgreSQL on Solaris 8 and ufs Brandon Metcalf
• 20:33   Re: PostgreSQL on Solaris 8 and ufs Tom Arthurs
• 20:55   Re: PostgreSQL on Solaris 8 and ufs Andrew Sullivan
• 20:59   Re: PostgreSQL on Solaris 8 and ufs Andrew Sullivan

24 March 2005

• 02:35   Re: PostgreSQL on Solaris 8 and ufs Josh Berkus
• 12:35   Re: CPU 0.1% IOWAIT 99% for decisonnal queries Patrick Vedrines
• 12:49   Re: CPU 0.1% IOWAIT 99% for decisonnal queries Patrick Vedrines
• 13:10   Re: CPU 0.1% IOWAIT 99% for decisonnal queries Patrick Vedrines
• 13:41   Re: Tsearch2 performance on big database Rick Jansen
• 13:52   Re: Tsearch2 performance on big database Oleg Bartunov
• 13:58   Re: Tsearch2 performance on big database Rick Jansen
• 14:53   Re: CPU 0.1% IOWAIT 99% for decisonnal queries Gustavo Franklin Nóbrega - Planae
• 16:32   clear function cache (WAS: SQL function inlining) Enrico Weigelt
• 16:42   Re: clear function cache (WAS: SQL function inlining) Alvaro Herrera
• 16:48   Re: View columns calculated Enrico Weigelt
• 17:05   Re: CPU 0.1% IOWAIT 99% for decisonnal queries Patrick Vedrines
• 17:12   Re: clear function cache (WAS: SQL function inlining) Enrico Weigelt
• 17:29   Re: CPU 0.1% IOWAIT 99% for decisonnal queries Gustavo Franklin Nóbrega - Planae
• 17:58   Re: clear function cache (WAS: SQL function inlining) Stephan Szabo
• 21:19   pg_autovacuum not having enough suction ? Otto Blomqvist
• 22:08   Preventing query from hogging server Matthew Nuzum
• 22:24   Re: Preventing query from hogging server Rosser Schwarz
• 22:33   Re: pg_autovacuum not having enough suction ? Tom Lane
• 22:43   Re: Preventing query from hogging server Tom Lane
• 22:53   Re: Preventing query from hogging server Matthew Nuzum
• 22:55   Re: Preventing query from hogging server Matthew Nuzum
• 23:02   Re: Preventing query from hogging server Tom Lane
• 23:13   Re: Preventing query from hogging server Matthew Nuzum
• 23:19   Re: Preventing query from hogging server Tom Lane

25 March 2005

• 00:57   Re: CPU 0.1% IOWAIT 99% for decisonnal queries Simon Riggs
• 02:00   Re: pg_autovacuum not having enough suction ? Otto Blomqvist
• 02:40   Re: pg_autovacuum not having enough suction ? Matthew T. O'Connor
• 02:58   Re: pg_autovacuum not having enough suction ? Matthew T. O'Connor
• 03:07   Delete query takes exorbitant amount of time Karim Nassar
• 03:52   Re: Delete query takes exorbitant amount of time Tom Lane
• 04:25   Re: Delete query takes exorbitant amount of time Mark Lewis
• 04:45   Re: Delete query takes exorbitant amount of time Karim Nassar
• 04:48   Re: Delete query takes exorbitant amount of time Tom Lane
• 05:35   Re: Delete query takes exorbitant amount of time Tom Lane
• 06:37   Re: Delete query takes exorbitant amount of time Christopher Kings-Lynne
• 06:38   Re: Delete query takes exorbitant amount of time Christopher Kings-Lynne
• 06:38   Re: Delete query takes exorbitant amount of time Christopher Kings-Lynne
• 06:56   Re: Delete query takes exorbitant amount of time Vivek Khera
• 08:25   Re: Delete query takes exorbitant amount of time Josh Berkus
• 08:38   Re: Delete query takes exorbitant amount of time Oleg Bartunov
• 09:15   Re: Delete query takes exorbitant amount of time Tom Lane
• 09:58   Re: Delete query takes exorbitant amount of time Tom Lane
• 13:19   Re: [BUGS] BUG #1552: massive performance hit between 7.4 and 8.0.1 Simon Riggs
• 17:41   Re: [BUGS] BUG #1552: massive performance hit between 7.4 and 8.0.1 Tom Lane
• 18:12   Re: Delete query takes exorbitant amount of time Simon Riggs
• 18:12   Script for getting a table of reponse-time breakdown Jack Xue
• 18:17   Re: Delete query takes exorbitant amount of time Tom Lane
• 18:39   Re: [BUGS] BUG #1552: massive performance hit Simon Riggs
• 19:02   Re: Delete query takes exorbitant amount of time Simon Riggs
• 19:23   Re: Delete query takes exorbitant amount of time Stephan Szabo
• 20:39   Re: Delete query takes exorbitant amount of time Josh Berkus
• 20:41   Re: Script for getting a table of reponse-time breakdown Josh Berkus
• 21:00   Re: Script for getting a table of reponse-time breakdown Jack Xue
• 21:07   Re: Script for getting a table of reponse-time breakdown Josh Berkus
• 21:25   Re: pg_autovacuum not having enough suction ? Otto Blomqvist
• 21:26   Re: Delete query takes exorbitant amount of time Simon Riggs
• 21:47   Re: Delete query takes exorbitant amount of time Tom Lane
• 22:46   Re: pg_autovacuum not having enough suction ? Matthew T. O'Connor
• 22:55   Re: pg_autovacuum not having enough suction ? Tom Lane
• 23:20   Re: pg_autovacuum not having enough suction ? Otto Blomqvist
• 23:23   lazy_update_relstats considered harmful (was Re: pg_autovacuum not having enough suction ?) Tom Lane
• 23:30   Re: Delete query takes exorbitant amount of time Simon Riggs
• 23:31   Re: pg_autovacuum not having enough suction ? Otto Blomqvist

26 March 2005

• 00:04   Re: pg_autovacuum not having enough suction ? Matthew T. O'Connor
• 00:10   Re: Delete query takes exorbitant amount of time Stephan Szabo
• 00:12   Re: [HACKERS] lazy_update_relstats considered harmful (was Re: Matthew T. O'Connor
• 00:25   Re: Delete query takes exorbitant amount of time Tom Lane
• 00:44   Re: Delete query takes exorbitant amount of time Karim Nassar
• 00:51   Re: Delete query takes exorbitant amount of time Simon Riggs
• 01:21   Re: lazy_update_relstats considered harmful (was Re: Simon Riggs
• 01:36   Re: lazy_update_relstats considered harmful (was Re: pg_autovacuum not having enough suction ?) Tom Lane
• 02:06   Re: pg_autovacuum not having enough suction ? Tom Lane
• 02:13   Re: pg_autovacuum not having enough suction ? Bruce Momjian
• 02:17   Re: pg_autovacuum not having enough suction ? Joshua D. Drake
• 02:18   Re: pg_autovacuum not having enough suction ? Tom Lane
• 02:21   Re: pg_autovacuum not having enough suction ? Bruce Momjian
• 02:31   Re: pg_autovacuum not having enough suction ? Otto Blomqvist
• 03:24   How to improve db performance with $7K? Steve Poe
• 03:59   Re: How to improve db performance with $7K? Tom Lane
• 04:03   Re: How to improve db performance with $7K? Will LaShell
• 04:13   Re: How to improve db performance with $7K? Joshua D. Drake
• 04:32   Re: How to improve db performance with $7K? Steve Poe
• 09:34   Re: Delete query takes exorbitant amount of time Christopher Kings-Lynne
• 11:25   Re: How to improve db performance with $7K? Steve Poe
• 12:59   Re: How to improve db performance with $7K? Bjoern Metzdorf
• 18:55   Re: Delete query takes exorbitant amount of time Stephan Szabo
• 22:33   Re: Delete query takes exorbitant amount of time Karim Nassar
• 23:56   Re: How to improve db performance with $7K? Josh Berkus

27 March 2005

• 00:16   Re: How to improve db performance with $7K? Steve Poe
• 00:31   Re: How to improve db performance with $7K? Steve Poe
• 03:18   Re: Delete query takes exorbitant amount of time Stephan Szabo
• 03:42   Re: Delete query takes exorbitant amount of time Karim Nassar
• 19:05   Re: Delete query takes exorbitant amount of time Stephan Szabo
• 19:23   Re: How to improve db performance with $7K? Alexander Kirpa
• 19:23   Configuration/Tuning of server/DB Reid Thompson
• 19:23   Re: Delete query takes exorbitant amount of time Karim Nassar
• 19:25   Re: [BUGS] BUG #1552: massive performance hit between 7.4 Karim Nassar
• 19:26   Re: Delete query takes exorbitant amount of time Karim Nassar
• 19:26   Re: pg_autovacuum not having enough suction ? Matthew T. O'Connor
• 19:26   Query Optimizer Failure / Possible Bug Hannes Dorbath
• 19:27   Re: Hardware questions Dave Cramer
• 19:28   Re: What about utility to calculate planner cost constants? Kenneth Marshall

28 March 2005

• 14:22   Re: Delete query takes exorbitant amount of time Simon Riggs
• 19:34   NFS RAID 0/5 Rudi Starcevic
• 19:44   Re: Configuration/Tuning of server/DB Thomas F.O'Connell
• 20:27   Re: Delete query takes exorbitant amount of time Stephan Szabo
• 21:36   Re: Delete query takes exorbitant amount of time Mark Lewis
• 22:22   Sluggish server performance Patrick Hatcher
• 22:39   Re: Sluggish server performance Jacques Caron
• 22:39   Re: Sluggish server performance Joshua D. Drake
• 23:27   Re: Delete query takes exorbitant amount of time Simon Riggs
• 23:46   Re: Query Optimizer Failure / Possible Bug Josh Berkus

29 March 2005

• 00:09   Re: which dual-CPU hardware/OS is fastest for PostgreSQL? Greg Stark
• 00:24   Re: which dual-CPU hardware/OS is fastest for PostgreSQL? Steve Poe
• 00:57   Re: which dual-CPU hardware/OS is fastest for PostgreSQL? Joshua D. Drake
• 01:06   Re: Preventing query from hogging server Jim C. Nasby
• 01:09   Re: Delete query takes exorbitant amount of time Simon Riggs
• 01:36   Re: which dual-CPU hardware/OS is fastest for PostgreSQL? Greg Stark
• 02:43   Re: How to improve db performance with $7K? Cott Lang
• 02:59   JDBC best practice Dave Held
• 03:01   Re: Delete query takes exorbitant amount of time Simon Riggs
• 03:38   Re: which dual-CPU hardware/OS is fastest for PostgreSQL? Bruce Momjian
• 04:39   Re: which dual-CPU hardware/OS is fastest for PostgreSQL? Klint Gore
• 04:51   Re: which dual-CPU hardware/OS is fastest for PostgreSQL? Greg Stark
• 06:53   Re: JDBC best practice Kris Jurka
• 08:31   Re: How to improve db performance with $7K? Steve Poe
• 13:50   Re: How to improve db performance with $7K? PFC
• 15:31   Re: Delete query takes exorbitant amount of time Simon Riggs
• 16:17   Re: How to improve db performance with $7K? Dave Cramer
• 17:50   Re: Delete query takes exorbitant amount of time Stephan Szabo
• 18:20   Re: Delete query takes exorbitant amount of time Stephan Szabo
• 18:29   Re: Delete query takes exorbitant amount of time Tom Lane
• 18:41   Re: Delete query takes exorbitant amount of time Tom Lane
• 18:53   Re: How to improve db performance with $7K? Cott Lang
• 18:56   Re: Delete query takes exorbitant amount of time Tom Lane
• 19:21   Re: Delete query takes exorbitant amount of time Simon Riggs
• 19:26   Re: Delete query takes exorbitant amount of time Simon Riggs
• 19:32   Re: Delete query takes exorbitant amount of time Tom Lane
• 20:03   Re: Delete query takes exorbitant amount of time Simon Riggs
• 20:33   Re: Delete query takes exorbitant amount of time Stephan Szabo
• 20:38   Re: Delete query takes exorbitant amount of time Stephan Szabo
• 21:19   Re: Delete query takes exorbitant amount of time Simon Riggs
• 21:32   Re: Delete query takes exorbitant amount of time Tom Lane
• 22:11   Re: How to improve db performance with $7K? Greg Stark
• 22:33   Million of rows Vinicius Bernardi
• 22:55   Re: Delete query takes exorbitant amount of time Simon Riggs
• 23:08   Re: Million of rows Michael Fuhr

30 March 2005

• 01:10   Re: Million of rows Vinicius Bernardi
• 04:49   VACUUM on duplicate DB gives FSM and total pages discrepancies Karim Nassar
• 15:03   Reading recommendations Marc Burgauer
• 16:37   Weird index scan Tambet Matiisen
• 19:19   Re: VACUUM on duplicate DB gives FSM and total pages discrepancies Alvaro Herrera
• 19:58   Re: Reading recommendations Michael Fuhr
• 20:29   Re: Reading recommendations Richard_D_Levine@Raytheon.com
• 20:41   Re: Reading recommendations Mohan, Ross
• 20:52   Re: Reading recommendations Steve Wampler
• 20:58   Re: Reading recommendations Mohan, Ross
• 21:23   Dynamic query perormance Keith Worthington
• 21:42   Re: Weird index scan G u i d o B a r o s i o
• 21:44   Re: Reading recommendations Bruno Wolff III
• 22:05   Re: Dynamic query perormance John Arbash Meinel
• 22:34   Re: Dynamic query perormance PFC

31 March 2005

• 00:12   Re: Reading recommendations Richard_D_Levine@raytheon.com
• 00:36   Left Outer Join much faster than non-outer Join? rm_pg@cheapcomplexdevices.com
• 00:50   Re: Left Outer Join much faster than non-outer Join? Ron Mayer
• 00:58   Re: Reading recommendations Steve Wampler
• 01:01   Re: PostgreSQL on Solaris 8 and ufs Brandon Metcalf
• 03:10   Re: Reading recommendations Mohan, Ross
• 05:50   fine tuning for logging server Florin Andrei
• 05:59   Re: fine tuning for logging server John Arbash Meinel
• 06:03   Re: fine tuning for logging server Florin Andrei
• 06:12   Re: fine tuning for logging server John Arbash Meinel
• 06:24   Re: fine tuning for logging server Florin Andrei
• 06:30   Re: fine tuning for logging server Florin Andrei
• 06:34   Re: fine tuning for logging server John Arbash Meinel
• 06:41   Re: fine tuning for logging server John Arbash Meinel
• 08:08   Re: Left Outer Join much faster than non-outer Join? Tom Lane
• 11:03   Re: Left Outer Join much faster than non-outer Join? Ron Mayer
• 12:14   Re: Left Outer Join much faster than non-outer Join? Ron Mayer
• 12:30   Re: Left Outer Join much faster than non-outer Join? Patrick Vedrines
• 13:01   Re: fine tuning for logging server PFC
• 17:19   Re: Reading recommendations Richard_D_Levine@Raytheon.com
• 17:48   Re: Reading recommendations Stefan Weiss
• 19:01   Re: fine tuning for logging server Michael Adler
• 19:48   Re: Reading recommendations Steve Wampler
• 22:03   Re: Left Outer Join much faster than non-outer Join? Simon Riggs
• 22:24   Re: Reading recommendations Richard_D_Levine@raytheon.com
• 22:52   How to speed up word count with tsearch2? Yudie Pg
• 23:05   Very long time to execute and Update, suggestions? Madison Kelly
• 23:07   Postgresql.conf setting recommendations for 8.0.1 Pallav Kalva
• 23:52   Re: Very long time to execute and Update, suggestions? Madison Kelly
• 23:58   How to speed up word count in tsearch2? Yudie Pg