Mailing lists [pgsql-performance]

1 July 2005

• 08:57   Re: ported application having performance issues Dennis Bjorklund
• 13:33   planner picking more expensive plan Sam Mason
• 14:23   Re: planner picking more expensive plan Tom Lane
• 14:58   Re: planner picking more expensive plan Sam Mason
• 15:18   Re: planner picking more expensive plan John A Meinel
• 15:58   Re: planner picking more expensive plan Sam Mason

2 July 2005

• 00:52   Re: ported application having performance issues John Mendenhall
• 01:59   Planner constants for RAM resident databases Emil Briggs
• 02:08   Re: Planner constants for RAM resident databases Steve Atkins
• 02:41   Re: Planner constants for RAM resident databases John A Meinel
• 03:15   Re: Planner constants for RAM resident databases John A Meinel
• 05:24   Re: planner picking more expensive plan Dennis Bjorklund
• 12:09   B-Tree index not being used Madison Kelly
• 13:44   Re: Planner constants for RAM resident databases Emil Briggs
• 13:54   Re: B-Tree index not being used Tom Lane
• 15:20   Re: B-Tree index not being used Madison Kelly

3 July 2005

• 23:29   Re: investigating slow queries through pg_stat_activity Enrico Weigelt
• 23:46   plain inserts and deletes very slow Enrico Weigelt
• 23:54   Re: plain inserts and deletes very slow Steinar H. Gunderson
• 23:58   Re: plain inserts and deletes very slow Enrico Weigelt
• 23:58   Re: plain inserts and deletes very slow Enrico Weigelt

4 July 2005

• 00:50   Re: plain inserts and deletes very slow David Mitchell
• 01:03   Re: plain inserts and deletes very slow Enrico Weigelt
• 01:13   Re: plain inserts and deletes very slow David Mitchell
• 01:18   Re: plain inserts and deletes very slow Enrico Weigelt
• 03:09   Re: plain inserts and deletes very slow Alvaro Herrera
• 03:51   Re: plain inserts and deletes very slow David Mitchell
• 09:58   Re: plain inserts and deletes very slow Enrico Weigelt
• 10:00   Re: plain inserts and deletes very slow Enrico Weigelt
• 14:27   Re: plain inserts and deletes very slow Alvaro Herrera
• 19:55   Why the planner is not using the INDEX . David Gagnon
• 20:27   Re: Why the planner is not using the INDEX . Stephan Szabo
• 23:32   Re: plain inserts and deletes very slow Klint Gore

5 July 2005

• 00:25   Re: Why the planner is not using the INDEX . David Gagnon
• 01:12   Re: Why the planner is not using the INDEX . Christopher Kings-Lynne
• 12:32   Re: Why the planner is not using the INDEX . Bruno Wolff III
• 14:02   Re: Why the planner is not using the INDEX . Stephan Szabo
• 16:10   Re: Why the planner is not using the INDEX . Tom Lane
• 16:15   Heavy virtual memory usage on production system Alexander Stanier
• 16:55   Re: Heavy virtual memory usage on production system Tom Lane
• 17:49   Re: Why the planner is not using the INDEX . David Gagnon
• 21:31   Re: Planner constants for RAM resident databases Josh Berkus

6 July 2005

• 12:04   Re: Heavy virtual memory usage on production system Alexander Stanier
• 14:15   Re: Heavy virtual memory usage on production system Tom Lane
• 14:50   Re: Heavy virtual memory usage on production system Alexander Stanier
• 15:06   Re: Heavy virtual memory usage on production system Tom Lane
• 17:15   Data Warehousing Tuning Paul Johnson
• 17:58   Storing data and indexes in different disks Alvaro Nunes Melo
• 18:44   Re: Storing data and indexes in different disks Dmitri Bichko
• 19:49   ALTER TABLE tabla ALTER COLUMN columna SET STATISTICS number Dario
• 20:08   Re: ALTER TABLE tabla ALTER COLUMN columna SET STATISTICS number Michael Fuhr
• 21:19   CURSOR slowes down a WHERE clause 100 times? Niccolo Rigacci
• 21:29   Re: CURSOR slowes down a WHERE clause 100 times? John A Meinel
• 22:05   join and query planner Dario
• 22:34   Re: join and query planner Stephan Szabo

7 July 2005

• 00:05   Re: Data Warehousing Tuning Frank Wosczyna
• 00:37   Re: Data Warehousing Tuning Josh Berkus
• 07:42   Re: CURSOR slowes down a WHERE clause 100 times? Niccolo Rigacci
• 08:13   Re: CURSOR slowes down a WHERE clause 100 times? Niccolo Rigacci
• 09:15   Re: CURSOR slowes down a WHERE clause 100 times? Richard Huxton
• 10:07   Re: CURSOR slowes down a WHERE clause 100 times? Niccolo Rigacci
• 11:19   How to speed up delete Bendik Rognlien Johansen
• 12:42    Jean-Max Reymond
• 12:49   Surprizing performances for Postgres on Centrino Jean-Max Reymond
• 12:55   Re: How to speed up delete PFC
• 13:03   Re: PFC
• 13:14   Need suggestion high-level suggestion on how to solve a performance problem Madison Kelly
• 13:48   Re: Surprizing performances for Postgres on Centrino Dawid Kuroczko
• 13:59   Re: CURSOR slowes down a WHERE clause 100 times? Tom Lane
• 14:02   Re: How to speed up delete Tom Lane
• 14:03   Re: Surprizing performances for Postgres on Centrino Steinar H. Gunderson
• 14:09   Re: Surprizing performances for Postgres on Centrino Alvaro Herrera
• 14:23   Re: Surprizing performances for Postgres on Centrino Jean-Max Reymond
• 14:55   Re: Surprizing performances for Postgres on Centrino Richard Huxton
• 15:07   Re: How to speed up delete Bendik Rognlien Johansen
• 22:21   Re: Need suggestion high-level suggestion on how to solve a performance problem PFC
• 23:29   Re: Need suggestion high-level suggestion on how to solve Madison Kelly
• 23:58   Re: Need suggestion high-level suggestion on how to solve a performance problem PFC

8 July 2005

• 01:02   Re: Need suggestion high-level suggestion on how to solve a performance problem Josh Berkus
• 01:33   Mount database on RAM disk? Stuart Bishop
• 03:05   Re: Mount database on RAM disk? Joshua D. Drake
• 04:04   Re: Mount database on RAM disk? Chris Browne
• 14:07   Re: Mount database on RAM disk? Rod Taylor
• 14:47   Re: plain inserts and deletes very slow Enrico Weigelt
• 15:01   Re: Select performance vs. mssql Enrico Weigelt
• 15:44   Re: Need help to decide Mysql vs Postgres Enrico Weigelt
• 16:08   Re: Need help to decide Mysql vs Postgres Mark Lewis
• 16:23   Re: Need help to decide Mysql vs Postgres Moises Alberto Lindo Gutarra
• 16:25   cost-based vacuum Ian Westmacott
• 16:37   Re: Why the planner is not using the INDEX . Enrico Weigelt
• 17:19   Re: Mount database on RAM disk? Josh Berkus
• 17:48   Re: cost-based vacuum Tom Lane
• 19:21   Re: Mount database on RAM disk? Merlin Moncure
• 21:47   Re: Select performance vs. mssql Jochem van Dieten
• 23:57   How to revoke a password Bailey, Larry

9 July 2005

• 00:09   Re: How to revoke a password Joshua D. Drake
• 00:16   Re: How to revoke a password Bailey, Larry
• 00:17   Re: How to revoke a password Alvaro Herrera
• 00:56   Re: How to revoke a password Joshua D. Drake
• 00:58   Re: How to revoke a password Michael Fuhr
• 21:48   Re: Mount database on RAM disk? Alex Stapleton

10 July 2005

• 04:50   Re: Mount database on RAM disk? Christopher Browne

11 July 2005

• 11:31   Re: cost-based vacuum Simon Riggs
• 12:59   Question Alejandro Lemus
• 13:07   Re: cost-based vacuum Ian Westmacott
• 13:29   Re: cost-based vacuum Tom Lane
• 13:30   Re: Question Richard Huxton
• 13:35   Re: Question Magnus Hagander
• 14:51   Re: cost-based vacuum Simon Riggs
• 23:26   Re: Question Gregory S. Williamson
• 23:28   join and query planner Dario Pudlo
• 23:28   Sorting on longer key is faster ? jobapply
• 23:29   Re: Data Warehousing Tuning Alexander Kirpa
• 23:39   Re: join and query planner John A Meinel
• 23:42   Re: Sorting on longer key is faster ? John A Meinel
• 23:47   Re: Sorting on longer key is faster ? Tom Lane

12 July 2005

• 01:48   Re: Sorting on longer key is faster ? John A Meinel
• 01:52   Re: Sorting on longer key is faster ? John A Meinel
• 12:58   Re: cost-based vacuum Simon Riggs
• 14:35   Re: join and query planner Bruno Wolff III
• 16:22   Projecting currentdb to more users Yves Vindevogel
• 17:51   Re: cost-based vacuum Ian Westmacott
• 18:01   Re: Projecting currentdb to more users Matthew Nuzum
• 18:25   Re: Projecting currentdb to more users Mohan, Ross
• 21:23   General DB Tuning Brent Henry
• 21:54   Re: General DB Tuning Tom Arthurs
• 23:32   Re: General DB Tuning Brent Henry

13 July 2005

• 00:37   Re: General DB Tuning Tom Arthurs
• 01:05   Re: General DB Tuning Dennis
• 01:14   Re: General DB Tuning Christopher Kings-Lynne
• 01:30   Re: General DB Tuning Tom Arthurs
• 01:36   Re: General DB Tuning Brent Henry
• 01:49   Re: General DB Tuning Christopher Kings-Lynne
• 01:53   Re: General DB Tuning Tom Arthurs
• 05:18   Re: Projecting currentdb to more users Jean-Max Reymond
• 08:21   size of cache Jean-Max Reymond
• 09:58   large table vs multiple smal tables Nicolas Beaume
• 10:07   Re: General DB Tuning Mark Rae
• 13:45   (pas de sujet) Nicolas Beaume
• 15:56   Re: cost-based vacuum Simon Riggs
• 16:08   Re: size of cache Simon Riggs
• 16:11   Re: General DB Tuning Simon Riggs
• 18:40   Re: cost-based vacuum Ian Westmacott
• 18:54   Quad Opteron stuck in the mud Dan Harris
• 18:59   Re: cost-based vacuum Tom Lane
• 19:09   Re: Quad Opteron stuck in the mud Dan Harris
• 19:11   Re: Quad Opteron stuck in the mud John A Meinel
• 19:15   performance problems ... 100 cpu utilization Dennis
• 19:16   Re: Quad Opteron stuck in the mud Dan Harris
• 20:17   Re: Quad Opteron stuck in the mud Stephen Frost
• 20:18   Re: Quad Opteron stuck in the mud Alvaro Herrera
• 20:20   Re: Quad Opteron stuck in the mud Dan Harris
• 20:40   Re: cost-based vacuum Simon Riggs
• 20:49   Re: Quad Opteron stuck in the mud Vivek Khera
• 21:46   Re: cost-based vacuum Ian Westmacott
• 22:51   Re: Quad Opteron stuck in the mud Simon Riggs

14 July 2005

• 00:07   Slow Query Marc McIntyre
• 03:21   Re: performance problems ... 100 cpu utilization Qingqing Zhou
• 04:28   Re: performance problems ... 100 cpu utilization Dennis
• 05:07   Re: performance problems ... 100 cpu utilization David Mitchell
• 05:08   lots of updates on small table alison@mirrabooka.com (Alison Winters)
• 05:58   Profiler for PostgreSQL Agha Asif Raza
• 06:13   Re: Quad Opteron stuck in the mud Greg Stark
• 06:24   Re: Profiler for PostgreSQL Christopher Kings-Lynne
• 06:27   Re: Profiler for PostgreSQL Bruce Momjian
• 06:28   Re: Quad Opteron stuck in the mud Dan Harris
• 06:33   JFS fastest filesystem for PostgreSQL? Jeffrey W. Baker
• 06:54   Re: performance problems ... 100 cpu utilization Dennis
• 07:07   Re: JFS fastest filesystem for PostgreSQL? Dmitri Bichko
• 08:03   Re: JFS fastest filesystem for PostgreSQL? Dawid Kuroczko
• 08:05   slow joining very large table to smaller ones Dan Harris
• 09:56   Re: JFS fastest filesystem for PostgreSQL? mudfoot@rawbw.com
• 10:30   Re: JFS fastest filesystem for PostgreSQL? Michael Stone
• 11:20   Re: Slow Query Ragnar Hafstað
• 12:18   Re: JFS fastest filesystem for PostgreSQL? Grega Bremec
• 13:21   Re: JFS fastest filesystem for PostgreSQL? Michael Stone
• 13:27   Re: JFS fastest filesystem for PostgreSQL? Jeffrey W. Baker
• 15:43   Re: slow joining very large table to smaller ones John A Meinel
• 15:47   Re: Quad Opteron stuck in the mud Alvaro Herrera
• 16:06   Re: Quad Opteron stuck in the mud Dan Harris
• 16:26   Re: lots of updates on small table Alvaro Herrera
• 16:41   Re: lots of updates on small table Rod Taylor
• 18:27   Re: large table vs multiple smal tables Jim C. Nasby
• 18:29   Re: JFS fastest filesystem for PostgreSQL? Jim C. Nasby
• 18:37   Re: JFS fastest filesystem for PostgreSQL? Joshua D. Drake
• 20:47   Re: Quad Opteron stuck in the mud Greg Stark
• 20:48   Re: Profiler for PostgreSQL Simon Riggs
• 22:30   Re: slow joining very large table to smaller ones Dan Harris
• 22:46   Re: slow joining very large table to smaller ones John A Meinel
• 22:47   Re: slow joining very large table to smaller ones Michael Stone
• 23:08   Re: slow joining very large table to smaller ones Tom Lane
• 23:14   Re: slow joining very large table to smaller ones John A Meinel
• 23:30   Re: slow joining very large table to smaller ones Tom Lane
• 23:40   Re: slow joining very large table to smaller ones John A Meinel
• 23:42   Re: lots of updates on small table alison@mirrabooka.com (Alison Winters)
• 23:52   Re: lots of updates on small table John A Meinel
• 23:57   Re: lots of updates on small table Tom Lane

15 July 2005

• 00:12   Re: slow joining very large table to smaller ones Dan Harris
• 00:28   Re: lots of updates on small table Alvaro Herrera
• 00:37   Re: lots of updates on small table Alvaro Herrera
• 00:43   Re: performance problems ... 100 cpu utilization David Mitchell
• 02:26   Re: lots of updates on small table alison@mirrabooka.com (Alison Winters)
• 03:50   Re: slow joining very large table to smaller ones Dan Harris
• 04:12   Re: slow joining very large table to smaller ones John A Meinel
• 05:05   Indexing Function called on VACUUM and sorting ? jobapply
• 05:05   Re: large table vs multiple smal tables Kenneth Marshall
• 05:06   PostgresSQL vs. Firebird Relaxin
• 05:08   JFS fastest filesystem for PostgreSQL? Jeffrey W. Baker
• 05:08   Indexing Function called on VACUUM and sorting ? jobapply
• 05:08   Functional index is 5 times slower than the basic one jobapply
• 07:01   What's a lot of connections? Karim Nassar
• 07:14   Re: What's a lot of connections? Jeffrey W. Baker
• 08:20   Re: Profiler for PostgreSQL Andreas Pflug
• 09:17   Re: PostgresSQL vs. Firebird Chris Mair
• 14:16   Re: What's a lot of connections? Tom Lane
• 15:10   Re: slow joining very large table to smaller ones Dan Harris
• 15:21   Re: slow joining very large table to smaller ones Dan Harris
• 16:03   Re: performance problems ... 100 cpu utilization Dennis
• 16:44   Re: slow joining very large table to smaller ones Bruno Wolff III
• 17:39   Re: slow joining very large table to smaller ones PFC
• 20:39   Really bad diskio Ron Wills
• 20:45   Re: Really bad diskio Joshua D. Drake
• 21:01   Re: Really bad diskio Jeffrey W. Baker
• 21:04   Re: Really bad diskio Ron Wills
• 21:07   Re: Really bad diskio Dan Harris
• 21:10   Re: Really bad diskio Alvaro Herrera
• 21:18   Re: Really bad diskio Jeffrey W. Baker
• 21:29   Re: Really bad diskio Ron Wills
• 21:48   Re: Really bad diskio Ron Wills
• 21:54   Re: Really bad diskio Jeffrey W. Baker
• 22:11   Re: Really bad diskio Ron Wills

16 July 2005

• 00:06   Re: slow joining very large table to smaller ones John A Meinel
• 08:12   more filesystem benchmarks Jeffrey W. Baker
• 11:01   Re: more filesystem benchmarks Michael Stone
• 21:15   Re: Really bad diskio Ron Wills
• 21:42   Questions about temporary tables and performance Steven Rosenstein

17 July 2005

• 04:45   Re: Questions about temporary tables and performance Tom Lane
• 17:08   Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 18:16   Re: Impact of checkpoint_segments under continual load conditions Tom Lane

18 July 2005

• 03:34   Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Robert Creager
• 03:49   Re: Huge performance problem between 7.4.1 and 8.0.3 - Matthew T. O'Connor
• 04:11   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 04:11   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Tom Lane
• 04:18   Re: Huge performance problem between 7.4.1 and 8.0.3 - David Mitchell
• 04:18   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Tom Lane
• 04:18   Re: Huge performance problem between 7.4.1 and 8.0.3 - Matthew T. O'Connor
• 04:33   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 05:02   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 05:09   Re: Huge performance problem between 7.4.1 and 8.0.3 - Jeffrey W. Baker
• 05:09   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 05:27   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 05:43   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 05:56   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 06:07   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 07:51   Re: slow joining very large table to smaller ones Dawid Kuroczko
• 13:23   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Tom Lane
• 13:41   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 13:47   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 14:03   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Tom Lane
• 14:31   Re: Huge performance problem between 7.4.1 and 8.0.3 - Matthew T. O'Connor
• 14:53   Re: Huge performance problem between 7.4.1 and 8.0.3 - Tom Lane
• 17:50   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Robert Creager
• 17:52   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Tom Lane
• 17:57   Re: join and query planner Kevin Grittner
• 18:21   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Robert Creager
• 18:32   Re: Impact of checkpoint_segments under continual load conditions Vivek Khera
• 18:46   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 19:24   Re: join and query planner Dario
• 19:29   Insert performance (OT?) Yves Vindevogel
• 19:32   Re: Impact of checkpoint_segments under continual load conditions Tom Lane
• 19:36   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 20:32   Re: Impact of checkpoint_segments under continual load conditions Tom Lane
• 20:47   Re: join and query planner Kevin Grittner
• 23:31   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli

19 July 2005

• 08:35   Re: Insert performance (OT?) Yves Vindevogel
• 09:49   Re: Insert performance (OT?) Richard Huxton
• 10:21   Fwd: Insert performance (OT?) Yves Vindevogel
• 11:00   Re: Insert performance (OT?) Richard Huxton
• 13:38   Re: Insert performance (OT?) Yves Vindevogel
• 14:49   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 15:04   Re: Impact of checkpoint_segments under continual load conditions Tom Lane
• 15:33   Re: Impact of checkpoint_segments under continual load conditions PFC
• 15:44   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 15:57   Re: Impact of checkpoint_segments under continual load conditions Tom Lane
• 16:25   Re: Impact of checkpoint_segments under continual load conditions PFC
• 16:27   Re: Impact of checkpoint_segments under continual load conditions PFC
• 16:31   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 16:35   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 16:42   Re: Impact of checkpoint_segments under continual load conditions Tom Lane
• 16:50   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Robert Creager
• 16:54   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Tom Lane
• 16:55   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 17:05   Re: Impact of checkpoint_segments under continual load conditions Tom Lane
• 17:14   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 17:43   Looking for tips Oliver Crosby
• 17:50   Re: Looking for tips Joshua D. Drake
• 17:58   Re: Looking for tips John A Meinel
• 18:10   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Robert Creager
• 18:10   Re: Impact of checkpoint_segments under continual load conditions Tom Lane
• 18:15   Re: Looking for tips Richard Huxton
• 18:22   Re: Looking for tips Oliver Crosby
• 18:23   context-switching issue on Xeon Sailer, Denis (YBUSA-CDR)
• 18:38   Re: context-switching issue on Xeon David Hodgkinson
• 18:40   Re: context-switching issue on Xeon Tom Lane
• 18:42   Re: Looking for tips PFC
• 18:42   Re: Looking for tips Oliver Crosby
• 18:45   Re: Looking for tips Oliver Crosby
• 18:50   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 18:53   Re: Impact of checkpoint_segments under continual load conditions Tom Lane
• 18:58   Re: Looking for tips Kevin Grittner
• 19:02   Re: Looking for tips Tom Lane
• 19:05   Re: Impact of checkpoint_segments under continual load conditions PFC
• 19:12   Re: Looking for tips Oliver Crosby
• 19:12   Re: Looking for tips Steinar H. Gunderson
• 19:14   Re: Looking for tips PFC
• 19:16   Re: Looking for tips Tom Lane
• 19:22   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 19:34   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Robert Creager
• 19:36   Re: Looking for tips Steinar H. Gunderson
• 19:53   Re: Looking for tips Jeff Trout
• 20:08   Re: Looking for tips Oliver Crosby
• 20:19   Re: Looking for tips Dawid Kuroczko
• 20:28   Re: Looking for tips PFC
• 20:29   Re: Looking for tips Oliver Crosby
• 20:30   Re: Looking for tips Christopher Weimann
• 20:45   Re: Looking for tips Sven Willenberger
• 21:04   Re: Looking for tips Oliver Crosby
• 21:06   performance decrease after reboot John Mendenhall
• 21:14   Re: Looking for tips Sven Willenberger
• 21:41   Re: join and query planner Dario
• 23:01   Re: Looking for tips PFC

20 July 2005

• 01:51   Re: Looking for tips Oliver Crosby
• 04:49   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 15:25   Optimizer seems to be way off, why? Dirk Lutzebäck
• 15:53   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 16:17   Re: Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 17:20   Re: Optimizer seems to be way off, why? Richard Huxton
• 19:16   Re: Optimizer seems to be way off, why? Dirk Lutzebäck
• 20:28   Re: performance decrease after reboot John Mendenhall
• 20:58   Re: Optimizer seems to be way off, why? John A Meinel

21 July 2005

• 15:58   What is best way to stream terabytes of data into postgresql? Jeffrey Tenny
• 17:45   Re: Optimizer seems to be way off, why? Greg Stark
• 18:28   Re: What is best way to stream terabytes of data into Frank Wosczyna

22 July 2005

• 00:23   Re: What is best way to stream terabytes of data into postgresql? Josh Berkus
• 13:06   Planner doesn't look at LIMIT? Dawid Kuroczko
• 13:17   Re: Planner doesn't look at LIMIT? PFC
• 14:40   Re: Planner doesn't look at LIMIT? Tom Lane
• 14:48   Another index question Madison Kelly
• 14:51   Re: Planner doesn't look at LIMIT? Sam Mason
• 15:11   Solved (was: Re: Another index question) Madison Kelly
• 16:09   Re: Planner doesn't look at LIMIT? Dawid Kuroczko
• 16:20   Re: Planner doesn't look at LIMIT? Tom Lane
• 17:12   Re: [PATCHES] COPY FROM performance improvements Joshua D. Drake
• 17:32   Re: [HACKERS] Planner doesn't look at LIMIT? Simon Riggs
• 18:06   Re: [HACKERS] Planner doesn't look at LIMIT? Tom Lane
• 19:47   Re: [PATCHES] COPY FROM performance improvements Mark Wong
• 20:49   Re: Planner doesn't look at LIMIT? Dawid Kuroczko

23 July 2005

• 10:42   Re: [HACKERS] Planner doesn't look at LIMIT? Sam Mason
• 16:50   re: performance decrease after reboot John Mendenhall
• 17:03   Re: re: performance decrease after reboot Luke Lonergan
• 20:37   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager

24 July 2005

• 00:36   Re: Looking for tips Marc Mamin
• 00:39   Re: [PATCHES] COPY FROM performance improvements Luke Lonergan
• 00:41   Re: [PATCHES] COPY FROM performance improvements Luke Lonergan
• 00:42   Size of empty varchar and size of index Achim Luber

25 July 2005

• 08:26   Coraid/AoE device experience? Dan Harris
• 12:37   Mirroring PostgreSQL database Shashi Kanth Boddula
• 13:16   Re: Mirroring PostgreSQL database Richard Huxton
• 15:20   Re: Mirroring PostgreSQL database Christopher Kings-Lynne
• 16:03   Re: Mirroring PostgreSQL database Joshua D. Drake
• 21:31   "Vacuum Full Analyze" taking so long Tomeh, Husam
• 22:39   COPY insert performance Chris Isaacson
• 23:20   Re: "Vacuum Full Analyze" taking so long Tomeh, Husam
• 23:32   Re: COPY insert performance John A Meinel
• 23:37   Re: "Vacuum Full Analyze" taking so long Michael Stone

26 July 2005

• 00:10   Re: "Vacuum Full Analyze" taking so long Luke Lonergan
• 02:10   Re: "Vacuum Full Analyze" taking so long Luke Lonergan
• 02:11   Re: COPY insert performance Luke Lonergan
• 02:21   Re: "Vacuum Full Analyze" taking so long John A Meinel
• 09:58   Re: "Vacuum Full Analyze" taking so long Jochem van Dieten
• 12:12   Re: COPY insert performance Gavin Sherry
• 12:15   Re: COPY insert performance Chris Isaacson
• 12:23   Re: COPY insert performance Chris Isaacson
• 12:27   Re: COPY insert performance Chris Isaacson
• 14:23   Re: COPY insert performance Jeff Trout
• 15:22   Re: Looking for tips Vivek Khera
• 16:34   Cheap RAM disk? John A Meinel
• 16:49   faster INSERT with possible pre-existing row? Dan Harris
• 17:04   Re: Cheap RAM disk? Chris Browne
• 17:20   Re: faster INSERT with possible pre-existing row? John A Meinel
• 17:43   Re: Cheap RAM disk? Jeffrey W. Baker
• 17:49   Re: Cheap RAM disk? Vivek Khera
• 18:17   Re: Cheap RAM disk? PFC
• 18:23   Re: Cheap RAM disk? Luke Lonergan
• 18:28   Re: Cheap RAM disk? John A Meinel
• 18:47   Re: faster INSERT with possible pre-existing row? Luke Lonergan
• 19:02   Re: faster INSERT with possible pre-existing row? Sven Willenberger
• 19:10   Re: Cheap RAM disk? Alex Turner
• 19:12   Re: Cheap RAM disk? Alex Turner
• 19:15   Re: Cheap RAM disk? John A Meinel
• 19:27   Re: Cheap RAM disk? Michael Stone
• 19:30   Re: [Bizgres-general] Re: faster INSERT with possible Luke Lonergan
• 19:35   [IMPORTANT] - My application performance Roberto Germano Vieweg Neto
• 19:35   Re: faster INSERT with possible pre-existing row? Matthew Nuzum
• 19:51   Re: faster INSERT with possible pre-existing row? John A Meinel
• 20:02   Re: Cheap RAM disk? Richard_D_Levine@raytheon.com
• 20:05   Re: [IMPORTANT] - My application performance Jim C. Nasby
• 21:03   RES: [IMPORTANT] - My application performance Alvaro Neto
• 22:29   Re: faster INSERT with possible pre-existing row? Mark Lewis
• 23:04   Re: Cheap RAM disk? Chris Browne

27 July 2005

• 01:52   Re: faster INSERT with possible pre-existing row? Christopher Kings-Lynne
• 01:59   Re: [IMPORTANT] - My application performance Christopher Kings-Lynne
• 07:28   Re: [IMPORTANT] - My application performance Dawid Kuroczko
• 07:56   Inherited Table Query Planning (fwd) Jens-Wolfhard Schicke
• 14:22   Re: Inherited Table Query Planning (fwd) Tom Lane
• 16:20   Re: "Vacuum Full Analyze" taking so long Tomeh, Husam
• 16:28   Re: [Bizgres-general] Re: faster INSERT with possible Josh Berkus
• 18:28   Re: [Bizgres-general] Re: faster INSERT with possible Kris Jurka
• 20:29   wal_buffer tests in Josh Berkus
• 21:21   Re: Mirroring PostgreSQL database Sebastian Hennebrueder
• 21:38   Re: [Bizgres-general] Re: faster INSERT with possible Simon Riggs
• 21:53   Re: [Bizgres-general] Re: faster INSERT with possible PFC
• 22:35   Performance problems testing with Spamassassin 3.1.0 Bayes module. Matthew Schumacher

28 July 2005

• 00:09   Re: Performance problems testing with Spamassassin 3.1.0 Bayes module. Josh Berkus
• 00:41   Re: [Bizgres-general] Re: faster INSERT with possible Tom Lane
• 01:59   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher
• 02:11   Re: Performance problems testing with Spamassassin 3.1.0 Bayes module. Josh Berkus
• 02:17   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher
• 05:16   Left joining against two empty tables makes a query SLOW Chris Travers
• 06:19   Re: Performance problems testing with Spamassassin 3.1.0 Bayes module. Tom Lane
• 06:29   Re: Performance problems testing with Spamassassin 3.1.0 Karim Nassar
• 09:22   Finding bottleneck Kari Lavikka
• 09:35   Re: Finding bottleneck Gavin Sherry
• 09:56   Re: Left joining against two empty tables makes a query SLOW Gnanavel S
• 11:52   Re: Finding bottleneck Claus Guttesen
• 12:20   Re: Performance problems testing with Spamassassin 3.1.0 Bayes module. Merlin Moncure
• 13:02   Re: Finding bottleneck Merlin Moncure
• 14:38   Fwd: Help with view performance problem Chris Hoover
• 16:13   Re: Fwd: Help with view performance problem Dan Harris
• 17:00   Unable to explain DB error Steven Rosenstein
• 17:02   Re: Left joining against two empty tables makes a query Chris Travers
• 17:35   Re: Fwd: Help with view performance problem Chris Hoover
• 18:14   Re: Left joining against two empty tables makes a query Tom Lane
• 18:19   Re: Unable to explain DB error Tom Lane
• 18:27   Re: Finding bottleneck Luke Lonergan
• 23:06   Two queries are better than one? Karim Nassar
• 23:43   Re: [PATCHES] COPY FROM performance improvements Mark Wong
• 23:57   Re: [PATCHES] COPY FROM performance improvements Joshua D. Drake

29 July 2005

• 00:13   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher
• 01:55   Re: Two queries are better than one? Michael Fuhr
• 02:01   Re: Two queries are better than one? John A Meinel
• 02:04   Re: Two queries are better than one? Karim Nassar
• 03:57   Re: Performance problems testing with Spamassassin 3.1.0 Gavin Sherry
• 04:03   Re: [PATCHES] COPY FROM performance improvements Luke Lonergan
• 04:06   Re: Left joining against two empty tables makes a query SLOW Gnanavel S
• 04:07   Re: [PATCHES] COPY FROM performance improvements Luke Lonergan
• 04:12   Re: Two queries are better than one? Gnanavel S
• 04:23   Re: Two queries are better than one? Karim Nassar
• 04:25   Re: Left joining against two empty tables makes a query Neil Conway
• 04:39   Re: Two queries are better than one? Gnanavel S
• 05:10   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher
• 05:23   Re: Left joining against two empty tables makes a query Chris Travers
• 05:50   Re: Performance problems testing with Spamassassin 3.1.0 Andrew McMillan
• 05:58   Re: Performance problems testing with Spamassassin 3.1.0 Gavin Sherry
• 06:49   Re: Performance problems testing with Spamassassin 3.1.0 Dennis Bjorklund
• 07:01   Re: Performance problems testing with Spamassassin Luke Lonergan
• 12:37   Re: [PATCHES] COPY FROM performance improvements Bruce Momjian
• 13:23   Re: Performance problems testing with Spamassassin Alvaro Herrera
• 14:06   Re: BUG #1797: Problem using Limit in a function, seqscan Bruno Wolff III
• 14:12   Re: Performance problems testing with Spamassassin Tom Lane
• 16:45   Performance problems on 4/8way Opteron (dualcore) HP DL585 Dirk Lutzebäck
• 16:46   Re: Performance problems testing with Spamassassin Josh Berkus
• 16:50   ltree <@ operator selectivity causes very slow plan Matteo Beccati
• 17:11   Re: Performance problems testing with Spamassassin Luke Lonergan
• 17:14   Re: Performance problems testing with Spamassassin Luke Lonergan
• 17:35   Re: Performance problems testing with Spamassassin 3.1.0 Josh Berkus
• 17:38   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher
• 17:43   Re: Performance problems on 4/8way Opteron (dualcore) HP DL585 Josh Berkus
• 17:54   Re: [PATCHES] COPY FROM performance improvements Luke Lonergan
• 18:30   Re: Performance problems testing with Spamassassin 3.1.0 John Arbash Meinel
• 18:56   Re: Performance problems on 4/8way Opteron (dualcore) HP Jeffrey W. Baker
• 19:02   Re: Performance problems testing with Spamassassin Luke Lonergan
• 19:17   Re: Performance problems testing with Spamassassin Matthew Schumacher
• 19:22   Re: Performance problems on 4/8way Opteron (dualcore) J. Andrew Rogers
• 19:24   Re: Performance problems testing with Spamassassin 3.1.0 PFC
• 20:20   Re: Performance problems testing with Spamassassin 3.1.0 Andrew McMillan
• 20:31   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher
• 21:02   Re: Performance problems testing with Spamassassin 3.1.0 Tom Lane
• 21:48   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher
• 23:19   Re: Left joining against two empty tables makes a query Dario

30 July 2005

• 00:41   Re: Performance problems testing with Spamassassin Karim Nassar
• 07:57   Re: Performance problems on 4/8way Opteron (dualcore) William Yu
• 08:46   Re: Performance problems testing with Spamassassin Matthew Schumacher
• 10:36   Re: Performance problems testing with Spamassassin Karim Nassar
• 18:29   Re: Performance problems testing with Spamassassin 3.1.0 Tom Lane
• 21:06   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher

31 July 2005

• 05:27   Re: Performance problems testing with Spamassassin 3.1.0 John Arbash Meinel
• 05:32   Re: Performance problems testing with Spamassassin 3.1.0 John Arbash Meinel
• 10:11   Re: Performance problems on 4/8way Opteron (dualcore) HP Dirk Lutzebäck
• 10:12   Re: Performance problems on 4/8way Opteron (dualcore) HP Dirk Lutzebäck
• 15:29   Re: Performance problems on 4/8way Opteron (dualcore) J. Andrew Rogers
• 15:52   Re: Performance problems testing with Spamassassin 3.1.0 John Arbash Meinel
• 16:51   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher
• 17:10   Re: Performance problems testing with Spamassassin 3.1.0 Jim C. Nasby
• 18:19   Re: Performance problems testing with Spamassassin 3.1.0 Andreas Pflug
• 21:12   Re: Performance problems on 4/8way Opteron (dualcore) William Yu