Mailing lists [pgsql-performance]

1 July 2005

• 05:57   Re: ported application having performance issues Dennis Bjorklund
• 10:33   planner picking more expensive plan Sam Mason
• 11:23   Re: planner picking more expensive plan Tom Lane
• 11:58   Re: planner picking more expensive plan Sam Mason
• 12:18   Re: planner picking more expensive plan John A Meinel
• 12:58   Re: planner picking more expensive plan Sam Mason
• 21:52   Re: ported application having performance issues John Mendenhall
• 22:59   Planner constants for RAM resident databases Emil Briggs
• 23:08   Re: Planner constants for RAM resident databases Steve Atkins
• 23:41   Re: Planner constants for RAM resident databases John A Meinel

2 July 2005

• 00:15   Re: Planner constants for RAM resident databases John A Meinel
• 02:24   Re: planner picking more expensive plan Dennis Bjorklund
• 09:09   B-Tree index not being used Madison Kelly
• 10:44   Re: Planner constants for RAM resident databases Emil Briggs
• 10:54   Re: B-Tree index not being used Tom Lane
• 12:20   Re: B-Tree index not being used Madison Kelly

3 July 2005

• 20:29   Re: investigating slow queries through pg_stat_activity Enrico Weigelt
• 20:46   plain inserts and deletes very slow Enrico Weigelt
• 20:54   Re: plain inserts and deletes very slow Steinar H. Gunderson
• 20:58   Re: plain inserts and deletes very slow Enrico Weigelt
• 20:58   Re: plain inserts and deletes very slow Enrico Weigelt
• 21:50   Re: plain inserts and deletes very slow David Mitchell
• 22:03   Re: plain inserts and deletes very slow Enrico Weigelt
• 22:13   Re: plain inserts and deletes very slow David Mitchell
• 22:18   Re: plain inserts and deletes very slow Enrico Weigelt

4 July 2005

• 00:09   Re: plain inserts and deletes very slow Alvaro Herrera
• 00:51   Re: plain inserts and deletes very slow David Mitchell
• 06:58   Re: plain inserts and deletes very slow Enrico Weigelt
• 07:00   Re: plain inserts and deletes very slow Enrico Weigelt
• 11:27   Re: plain inserts and deletes very slow Alvaro Herrera
• 16:55   Why the planner is not using the INDEX . David Gagnon
• 17:27   Re: Why the planner is not using the INDEX . Stephan Szabo
• 20:32   Re: plain inserts and deletes very slow Klint Gore
• 21:25   Re: Why the planner is not using the INDEX . David Gagnon
• 22:12   Re: Why the planner is not using the INDEX . Christopher Kings-Lynne

5 July 2005

• 09:32   Re: Why the planner is not using the INDEX . Bruno Wolff III
• 11:02   Re: Why the planner is not using the INDEX . Stephan Szabo
• 13:10   Re: Why the planner is not using the INDEX . Tom Lane
• 13:15   Heavy virtual memory usage on production system Alexander Stanier
• 13:55   Re: Heavy virtual memory usage on production system Tom Lane
• 14:49   Re: Why the planner is not using the INDEX . David Gagnon
• 18:31   Re: Planner constants for RAM resident databases Josh Berkus

6 July 2005

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

7 July 2005

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

8 July 2005

• 00:05   Re: Mount database on RAM disk? Joshua D. Drake
• 01:04   Re: Mount database on RAM disk? Chris Browne
• 11:07   Re: Mount database on RAM disk? Rod Taylor
• 11:47   Re: plain inserts and deletes very slow Enrico Weigelt
• 12:01   Re: Select performance vs. mssql Enrico Weigelt
• 12:44   Re: Need help to decide Mysql vs Postgres Enrico Weigelt
• 13:08   Re: Need help to decide Mysql vs Postgres Mark Lewis
• 13:23   Re: Need help to decide Mysql vs Postgres Moises Alberto Lindo Gutarra
• 13:25   cost-based vacuum Ian Westmacott
• 13:37   Re: Why the planner is not using the INDEX . Enrico Weigelt
• 14:19   Re: Mount database on RAM disk? Josh Berkus
• 14:48   Re: cost-based vacuum Tom Lane
• 16:21   Re: Mount database on RAM disk? Merlin Moncure
• 18:47   Re: Select performance vs. mssql Jochem van Dieten
• 20:57   How to revoke a password Bailey, Larry
• 21:09   Re: How to revoke a password Joshua D. Drake
• 21:16   Re: How to revoke a password Bailey, Larry
• 21:17   Re: How to revoke a password Alvaro Herrera
• 21:56   Re: How to revoke a password Joshua D. Drake
• 21:58   Re: How to revoke a password Michael Fuhr

9 July 2005

• 18:48   Re: Mount database on RAM disk? Alex Stapleton

10 July 2005

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

11 July 2005

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

12 July 2005

• 09:58   Re: cost-based vacuum Simon Riggs
• 11:35   Re: join and query planner Bruno Wolff III
• 13:22   Projecting currentdb to more users Yves Vindevogel
• 14:51   Re: cost-based vacuum Ian Westmacott
• 15:01   Re: Projecting currentdb to more users Matthew Nuzum
• 15:25   Re: Projecting currentdb to more users Mohan, Ross
• 18:23   General DB Tuning Brent Henry
• 18:54   Re: General DB Tuning Tom Arthurs
• 20:32   Re: General DB Tuning Brent Henry
• 21:37   Re: General DB Tuning Tom Arthurs
• 22:05   Re: General DB Tuning Dennis
• 22:14   Re: General DB Tuning Christopher Kings-Lynne
• 22:30   Re: General DB Tuning Tom Arthurs
• 22:36   Re: General DB Tuning Brent Henry
• 22:49   Re: General DB Tuning Christopher Kings-Lynne
• 22:53   Re: General DB Tuning Tom Arthurs

13 July 2005

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

14 July 2005

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

15 July 2005

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

16 July 2005

• 05:12   more filesystem benchmarks Jeffrey W. Baker
• 08:01   Re: more filesystem benchmarks Michael Stone
• 18:15   Re: Really bad diskio Ron Wills
• 18:42   Questions about temporary tables and performance Steven Rosenstein

17 July 2005

• 01:45   Re: Questions about temporary tables and performance Tom Lane
• 14:08   Impact of checkpoint_segments under continual load conditions Christopher Petrilli
• 15:16   Re: Impact of checkpoint_segments under continual load conditions Tom Lane

18 July 2005

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

19 July 2005

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

20 July 2005

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

21 July 2005

• 12:58   What is best way to stream terabytes of data into postgresql? Jeffrey Tenny
• 14:45   Re: Optimizer seems to be way off, why? Greg Stark
• 15:28   Re: What is best way to stream terabytes of data into Frank Wosczyna
• 21:23   Re: What is best way to stream terabytes of data into postgresql? Josh Berkus

22 July 2005

• 10:06   Planner doesn't look at LIMIT? Dawid Kuroczko
• 10:17   Re: Planner doesn't look at LIMIT? PFC
• 11:40   Re: Planner doesn't look at LIMIT? Tom Lane
• 11:48   Another index question Madison Kelly
• 11:51   Re: Planner doesn't look at LIMIT? Sam Mason
• 12:11   Solved (was: Re: Another index question) Madison Kelly
• 13:09   Re: Planner doesn't look at LIMIT? Dawid Kuroczko
• 13:20   Re: Planner doesn't look at LIMIT? Tom Lane
• 14:12   Re: [PATCHES] COPY FROM performance improvements Joshua D. Drake
• 14:32   Re: [HACKERS] Planner doesn't look at LIMIT? Simon Riggs
• 15:06   Re: [HACKERS] Planner doesn't look at LIMIT? Tom Lane
• 16:47   Re: [PATCHES] COPY FROM performance improvements Mark Wong
• 17:49   Re: Planner doesn't look at LIMIT? Dawid Kuroczko

23 July 2005

• 07:42   Re: [HACKERS] Planner doesn't look at LIMIT? Sam Mason
• 13:50   re: performance decrease after reboot John Mendenhall
• 14:03   Re: re: performance decrease after reboot Luke Lonergan
• 17:37   Re: Huge performance problem between 7.4.1 and 8.0.3 - CS Robert Creager
• 21:36   Re: Looking for tips Marc Mamin
• 21:39   Re: [PATCHES] COPY FROM performance improvements Luke Lonergan
• 21:41   Re: [PATCHES] COPY FROM performance improvements Luke Lonergan
• 21:42   Size of empty varchar and size of index Achim Luber

25 July 2005

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

26 July 2005

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

27 July 2005

• 04:28   Re: [IMPORTANT] - My application performance Dawid Kuroczko
• 04:56   Inherited Table Query Planning (fwd) Jens-Wolfhard Schicke
• 11:22   Re: Inherited Table Query Planning (fwd) Tom Lane
• 13:20   Re: "Vacuum Full Analyze" taking so long Tomeh, Husam
• 13:28   Re: [Bizgres-general] Re: faster INSERT with possible Josh Berkus
• 15:28   Re: [Bizgres-general] Re: faster INSERT with possible Kris Jurka
• 17:29   wal_buffer tests in Josh Berkus
• 18:21   Re: Mirroring PostgreSQL database Sebastian Hennebrueder
• 18:38   Re: [Bizgres-general] Re: faster INSERT with possible Simon Riggs
• 18:53   Re: [Bizgres-general] Re: faster INSERT with possible PFC
• 19:35   Performance problems testing with Spamassassin 3.1.0 Bayes module. Matthew Schumacher
• 21:09   Re: Performance problems testing with Spamassassin 3.1.0 Bayes module. Josh Berkus
• 21:41   Re: [Bizgres-general] Re: faster INSERT with possible Tom Lane
• 22:59   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher
• 23:11   Re: Performance problems testing with Spamassassin 3.1.0 Bayes module. Josh Berkus
• 23:17   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher

28 July 2005

• 02:16   Left joining against two empty tables makes a query SLOW Chris Travers
• 03:19   Re: Performance problems testing with Spamassassin 3.1.0 Bayes module. Tom Lane
• 03:29   Re: Performance problems testing with Spamassassin 3.1.0 Karim Nassar
• 06:22   Finding bottleneck Kari Lavikka
• 06:35   Re: Finding bottleneck Gavin Sherry
• 06:56   Re: Left joining against two empty tables makes a query SLOW Gnanavel S
• 08:52   Re: Finding bottleneck Claus Guttesen
• 09:20   Re: Performance problems testing with Spamassassin 3.1.0 Bayes module. Merlin Moncure
• 10:02   Re: Finding bottleneck Merlin Moncure
• 11:38   Fwd: Help with view performance problem Chris Hoover
• 13:13   Re: Fwd: Help with view performance problem Dan Harris
• 14:00   Unable to explain DB error Steven Rosenstein
• 14:02   Re: Left joining against two empty tables makes a query Chris Travers
• 14:35   Re: Fwd: Help with view performance problem Chris Hoover
• 15:14   Re: Left joining against two empty tables makes a query Tom Lane
• 15:19   Re: Unable to explain DB error Tom Lane
• 15:27   Re: Finding bottleneck Luke Lonergan
• 20:06   Two queries are better than one? Karim Nassar
• 20:43   Re: [PATCHES] COPY FROM performance improvements Mark Wong
• 20:57   Re: [PATCHES] COPY FROM performance improvements Joshua D. Drake
• 21:13   Re: Performance problems testing with Spamassassin 3.1.0 Matthew Schumacher
• 22:55   Re: Two queries are better than one? Michael Fuhr
• 23:01   Re: Two queries are better than one? John A Meinel
• 23:04   Re: Two queries are better than one? Karim Nassar

29 July 2005

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

30 July 2005

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

31 July 2005

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