Mailing lists [pgsql-performance]

2 July 2007

• 10:05   [PERFORMANCE] is it possible to force an index to be held in memory? valgog
• 10:07   slow query Vidhya Bondre
• 13:30   Re: slow query Nis Jørgensen
• 22:21   Re: PostgreSQL 8.0 occasionally slow down Greg Smith
• 23:25   Join with lower/upper limits doesn't scale well Craig James

3 July 2007

• 00:05   Re: Join with lower/upper limits doesn't scale well Gregory Stark
• 06:29   Delete Cascade FK speed issue Patric de Waha
• 11:34   Re: Delete Cascade FK speed issue Michael Fuhr
• 14:54   Filesystem Direct I/O and WAL sync option Dimitri
• 15:07   Re: Filesystem Direct I/O and WAL sync option Heikki Linnakangas
• 15:27   Re: Filesystem Direct I/O and WAL sync option Dimitri
• 16:01   Re: Delete Cascade FK speed issue Mark Lewis
• 17:03   Re: PostgreSQL 8.0 occasionally slow down Ho Fat Tsang
• 17:08   Re: PostgreSQL 8.0 occasionally slow down Ho Fat Tsang
• 17:14   Re: PostgreSQL 8.0 occasionally slow down Ho Fat Tsang
• 17:21   Re: PostgreSQL 8.0 occasionally slow down Ho Fat Tsang
• 17:25   Query is taking 5 HOURS to Complete on 8.1 version smiley2211
• 17:32   Re: Query is taking 5 HOURS to Complete on 8.1 version Bill Moran
• 18:55   Re: Query is taking 5 HOURS to Complete on 8.1 version smiley2211
• 19:18   Re: Query is taking 5 HOURS to Complete on 8.1 version Richard Huxton
• 19:23   Re: Query is taking 5 HOURS to Complete on 8.1 version smiley2211
• 20:17   Re: Query is taking 5 HOURS to Complete on 8.1 version Chris Hoover
• 20:18   Re: Query is taking 5 HOURS to Complete on 8.1 version smiley2211
• 20:29   Re: Query is taking 5 HOURS to Complete on 8.1 version Richard Huxton
• 20:29   Re: Query is taking 5 HOURS to Complete on 8.1 version Richard Huxton

4 July 2007

• 01:13   Re: Filesystem Direct I/O and WAL sync option Gregory Stark
• 08:02   Re: Delete Cascade FK speed issue Axel Rau
• 10:26   Re: Filesystem Direct I/O and WAL sync option Dimitri
• 10:45   Re: Filesystem Direct I/O and WAL sync option Gregory Stark

5 July 2007

• 12:01   Re: Filesystem Direct I/O and WAL sync option Dimitri
• 12:39   improvement suggestions for performance design tfinneid@ifi.uio.no
• 13:00   Re: improvement suggestions for performance design Heikki Linnakangas
• 13:36   Re: improvement suggestions for performance design tfinneid@ifi.uio.no
• 14:57   Re: improvement suggestions for performance design Y Sidhu
• 15:49   Re: improvement suggestions for performance design tfinneid@ifi.uio.no
• 16:10   Re: improvement suggestions for performance design Y Sidhu
• 17:49   Re: Query is taking 5 HOURS to Complete on 8.1 version smiley2211
• 18:05   Re: Query is taking 5 HOURS to Complete on 8.1 version Alvaro Herrera
• 18:47   Re: improvement suggestions for performance design Heikki Linnakangas
• 22:55   Re: improvement suggestions for performance design Thomas Finneid

6 July 2007

• 00:39   Re: PostgreSQL Configuration Tool for Dummies Magnus Hagander
• 02:28   Direct I/O lai yoke hman
• 02:44   Performance of PostgreSQL and Oracle lai yoke hman
• 03:59   Re: Performance of PostgreSQL and Oracle Tom Lane
• 04:26   Re: PostgreSQL Configuration Tool for Dummies Harald Armin Massa
• 11:30   Re: improvement suggestions for performance design Kalle Hallivuori
• 14:40   Re: Direct I/O Alvaro Herrera
• 14:42   Advice about how to delete Arnau
• 15:05   Re: Advice about how to delete Michael Glaesemann
• 15:56   Re: Advice about how to delete Arnau
• 16:03   Re: Direct I/O Jignesh K. Shah
• 16:19   Re: Advice about how to delete Heikki Linnakangas

8 July 2007

• 10:06   Re: improvement suggestions for performance design Thomas Finneid
• 16:25   Re: improvement suggestions for performance design Kalle Hallivuori

9 July 2007

• 15:57   PostgreSQL publishes first real benchmark Jignesh K. Shah
• 16:21   Re: PostgreSQL publishes first real benchmark Jonah H. Harris
• 16:26   Re: PostgreSQL publishes first real benchmark Joshua D. Drake
• 16:28   Re: PostgreSQL publishes first real benchmark Heikki Linnakangas
• 16:52   Re: PostgreSQL publishes first real benchmark Steinar H. Gunderson
• 17:00   Re: PostgreSQL publishes first real benchmark Joshua D. Drake
• 17:48   Re: PostgreSQL publishes first real benchmark Jignesh K. Shah
• 18:23   Re: PostgreSQL publishes first real benchmark Magnus Hagander
• 18:38   Re: PostgreSQL publishes first real benchmark Vivek Khera
• 18:55   Re: PostgreSQL publishes first real benchmark Greg Smith
• 19:05   Re: PostgreSQL publishes first real benchmark Jonah H. Harris
• 19:16   Re: PostgreSQL publishes first real benchmark Joshua D. Drake
• 19:18   Re: PostgreSQL publishes first real benchmark Jonah H. Harris
• 20:32   Re: Filesystem Direct I/O and WAL sync option Jim C. Nasby
• 20:46   Re: Filesystem Direct I/O and WAL sync option Jonah H. Harris
• 20:53   Re: PostgreSQL publishes first real benchmark Jim C. Nasby
• 21:48   Re: rtree/gist index taking enormous amount of space in 8.2.3 Dolafi, Tom

10 July 2007

• 08:01   Re: PostgreSQL publishes first real benchmark Heiko W.Rupp
• 12:53   Re: Filesystem Direct I/O and WAL sync option Dimitri
• 14:47   Query Analyser Gauri Kanekar
• 15:05   tuning a function to insert/retrieve values from a reference table Marc Mamin
• 15:41   Re: tuning a function to insert/retrieve values from a reference table Tom Lane

11 July 2007

• 00:47   Equivalent queries produce different plans Craig James
• 01:00   Re: Equivalent queries produce different plans Craig James
• 01:25   Re: Equivalent queries produce different plans Tom Lane
• 13:03   best use of an EMC SAN Dave Cramer
• 13:19   Re: best use of an EMC SAN Dan Gorman
• 14:05   Re: best use of an EMC SAN Gregory Stark
• 14:06   Re: Query Analyser Michael Fuhr
• 14:14   Re: best use of an EMC SAN Dave Cramer
• 14:46   Re: PostgreSQL publishes first real benchmark Philippe Amelant
• 14:47   WALL on controller without battery? Francisco Reyes
• 15:02   Re: best use of an EMC SAN Cott Lang
• 15:21   TIMING A QUERY ??? smiley2211
• 15:33   Re: best use of an EMC SAN Andrew Sullivan
• 15:35   Two questions.. shared_buffers and long reader issue Patric de Waha
• 15:36   Re: WALL on controller without battery? Andrew Sullivan
• 15:39   Re: TIMING A QUERY ??? Andrew Sullivan
• 15:48   Re: PostgreSQL publishes first real benchmark Jignesh K. Shah
• 15:51   Re: Two questions.. shared_buffers and long reader issue Bryan Murphy
• 15:52   Weird row estimate Marc Cousin
• 16:06   Re: PostgreSQL publishes first real benchmark Heikki Linnakangas
• 16:09   Re: WALL on controller without battery? Alan Hodgson
• 16:11   Re: TIMING A QUERY ??? Tom Lane
• 16:11   Re: TIMING A QUERY ??? Gregory Stark
• 16:33   Re: PostgreSQL publishes first real benchmark Jignesh K. Shah
• 16:58   Re: Two questions.. shared_buffers and long reader issue Tom Lane
• 16:58   Re: Two questions.. shared_buffers and long reader issue Andrew Sullivan
• 16:59   Re: PostgreSQL publishes first real benchmark André Gomes Lamas Otero
• 17:02   Re: TIMING A QUERY ??? Andrew Sullivan
• 17:07   Re: PostgreSQL publishes first real benchmark Tom Lane
• 17:44   Re: best use of an EMC SAN Chris Browne
• 17:58   Re: best use of an EMC SAN Jim Nasby
• 18:27   Re: best use of an EMC SAN Andrew Sullivan
• 18:33   bitmap-index-scan slower than normal index scan Andreas Kretschmer
• 18:34   Re: PostgreSQL publishes first real benchmark Jignesh K. Shah
• 18:35   Re: best use of an EMC SAN Greg Smith
• 18:45   Re: best use of an EMC SAN Dave Cramer
• 18:52   Re: bitmap-index-scan slower than normal index scan Alex Deucher
• 18:54   Re: WALL on controller without battery? Greg Smith
• 19:32   Re: bitmap-index-scan slower than normal index scan A. Kretschmer
• 19:39   Re: WALL on controller without battery? Francisco Reyes
• 19:43   Re: WALL on controller without battery? Joshua D. Drake
• 20:01   Re: bitmap-index-scan slower than normal index scan Alex Deucher
• 20:02   Re: bitmap-index-scan slower than normal index scan Alex Deucher
• 20:04   Re: bitmap-index-scan slower than normal index scan Tom Lane
• 20:17   Re: bitmap-index-scan slower than normal index scan Andreas Kretschmer
• 20:35   Re: WALL on controller without battery? Francisco Reyes
• 20:35   Re: Weird row estimate Tom Lane
• 20:49   Re: Two questions.. shared_buffers and long reader issue Patric de Waha
• 21:11   TRUNCATE TABLE Adriaan van Os
• 21:54   Re: TRUNCATE TABLE Tom Lane
• 22:16   Re: TRUNCATE TABLE Gregory Stark
• 23:01   Re: WALL on controller without battery? Greg Smith

12 July 2007

• 00:27   Re: WALL on controller without battery? Francisco Reyes
• 03:10   Estimating WAL volume Greg Smith
• 05:15   Re: bitmap-index-scan slower than normal index scan A. Kretschmer
• 07:28   pg_restore causes 100 Craig James
• 07:37   Re: TRUNCATE TABLE Adriaan van Os
• 08:40   one column from huge view Marcin Stępnicki
• 08:51   Re: one column from huge view Heikki Linnakangas
• 08:55   Re: Weird row estimate Marc Cousin
• 09:08   Re: PostgreSQL publishes first real benchmark Stefan Kaltenbrunner
• 10:45   Re: PostgreSQL publishes first real benchmark Gregory Stark
• 12:39   Re: TIMING A QUERY ??? smiley2211
• 12:51   Re: one column from huge view Michael Fuhr
• 12:56   Re: one column from huge view Heikki Linnakangas
• 14:27   Re: pg_restore causes 100 Tom Lane
• 14:48   Re: one column from huge view Tom Lane
• 15:01   Re: PostgreSQL publishes first real benchmark Greg Smith
• 19:20   Re: TRUNCATE TABLE Tom Lane

13 July 2007

• 07:47   Re: TRUNCATE TABLE Adriaan van Os
• 09:02   Re: TRUNCATE TABLE Gregory Stark
• 09:05   Re: TRUNCATE TABLE Jean-Max Reymond
• 09:21   Re: TRUNCATE TABLE Thomas Samson
• 10:29   Re: PostgreSQL publishes first real benchmark Philippe Amelant
• 12:08   Re: PostgreSQL publishes first real benchmark Ray Stell
• 12:45   Re: TRUNCATE TABLE Michael Stone
• 14:40   Re: TRUNCATE TABLE Tom Lane
• 16:18   Re: TRUNCATE TABLE Adriaan van Os
• 16:29   Re: TRUNCATE TABLE Steinar H. Gunderson
• 16:30   Re: TRUNCATE TABLE Tom Lane
• 16:53   Database Statistics??? smiley2211
• 17:13   Re: TRUNCATE TABLE Jim C. Nasby
• 17:35   Re: TRUNCATE TABLE Alvaro Herrera
• 18:13   Re: Database Statistics??? Tom Arthurs
• 18:25   Re: Database Statistics??? Ansgar -59cobalt- Wiechers
• 18:28   Re: Database Statistics??? smiley2211
• 18:33   Re: Database Statistics??? Mario Weilguni
• 19:12   Re: TRUNCATE TABLE Pavel Stehule
• 19:32   Re: TRUNCATE TABLE Adriaan van Os
• 21:05   Re: Database Statistics??? Alvaro Herrera

14 July 2007

• 08:30   Re: FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950 Hannes Dorbath
• 08:34   Re: FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950 Steinar H. Gunderson
• 09:58   Re: FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950 Gregory Stark
• 10:20   Re: FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950 Hannes Dorbath
• 15:51   Vacuum full considered useful ;) Patric de Waha
• 16:24   Re: Vacuum full considered useful ;) Joshua D. Drake
• 16:34   Re: Vacuum full considered useful ;) Tom Lane
• 16:34   Re: Vacuum full considered useful ;) Guillaume Lelarge

15 July 2007

• 02:26   Re: Vacuum full considered useful ;) Vivek Khera
• 16:38   slony over LAN and VPN angga erwina
• 16:42   slony over VPN and LAN angga erwina

16 July 2007

• 08:01   Re: Estimating WAL volume Simon Riggs
• 21:02   Re: FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950 Jim C. Nasby
• 21:40   Re: TRUNCATE TABLE Jim C. Nasby

17 July 2007

• 00:18   Re: TRUNCATE TABLE Tom Lane
• 14:31   Postgres configuration for 64 CPUs, 128 GB RAM... Marc Mamin
• 15:04   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Stefan Kaltenbrunner
• 15:48   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Jim C. Nasby
• 16:18   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Gregory Stark
• 16:46   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Greg Smith
• 17:43   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Strong, David
• 18:02   Re: Postgres configuration for 64 CPUs, 128 GB RAM... PFC
• 18:51   large number of connected connections to postgres database (v8.0) Fei Liu
• 19:39   insert vs select into performance Thomas Finneid
• 19:55   Re: insert vs select into performance Michael Glaesemann
• 20:17   Re: insert vs select into performance Arjen van der Meijden
• 20:31   Re: insert vs select into performance Tom Lane
• 20:50   Re: insert vs select into performance Thomas Finneid
• 20:58   Re: insert vs select into performance Thomas Finneid
• 20:59   Re: insert vs select into performance Michael Stone
• 20:59   Re: insert vs select into performance Mark Lewis
• 21:01   Re: insert vs select into performance Thomas Finneid
• 21:07   Re: insert vs select into performance Michael Glaesemann
• 21:11   Re: insert vs select into performance Thomas Finneid
• 21:13   Re: insert vs select into performance PFC
• 21:27   Re: insert vs select into performance Thomas Finneid
• 21:44   importance of fast disks with pg Thomas Finneid
• 21:54   Re: importance of fast disks with pg Dan Harris
• 22:29   ionice to make vacuum friendier? Ron Mayer

18 July 2007

• 07:36   Re: TRUNCATE TABLE Adriaan van Os
• 08:58   Re: importance of fast disks with pg Heikki Linnakangas
• 09:04   Re: ionice to make vacuum friendier? Heikki Linnakangas
• 11:05   Re: insert vs select into performance PFC
• 11:32   Re: insert vs select into performance Michael Stone
• 11:33   Re: insert vs select into performance Michael Stone
• 13:36   How to use a trigger to write rows to a remote server Michael Dengler
• 13:47   Re: How to use a trigger to write rows to a remote server Heikki Linnakangas
• 14:02   Re: How to use a trigger to write rows to a remote server Csaba Nagy
• 14:52   Re: How to use a trigger to write rows to a remote server Tom Lane
• 15:46   Re: How to use a trigger to write rows to a remote server Adam Tauno Williams
• 16:14   Parrallel query execution for UNION ALL Queries Benjamin Arai
• 16:22   Re: Parrallel query execution for UNION ALL Queries Jonah H. Harris
• 16:30   Re: Parrallel query execution for UNION ALL Queries Scott Marlowe
• 16:31   Re: How to use a trigger to write rows to a remote server Michael Dengler
• 17:06   Re: How to use a trigger to write rows to a remote server Erik Jones
• 17:08   When/if to Reindex Steven Flatt
• 18:48   Re: ionice to make vacuum friendier? Jim C. Nasby
• 18:50   Re: Parrallel query execution for UNION ALL Queries Jim C. Nasby
• 18:53   Re: When/if to Reindex Jim C. Nasby
• 19:08   Re: insert vs select into performance Thomas Finneid
• 19:12   Re: insert vs select into performance Thomas Finneid
• 19:14   Re: insert vs select into performance Thomas Finneid
• 19:25   Re: improvement suggestions for performance design Thomas Finneid
• 19:29   Re: insert vs select into performance Adriaan van Os
• 19:59   Re: insert vs select into performance Heikki Linnakangas
• 21:30   Optmal tags design? lists@on-track.ca
• 21:52   Re: Optmal tags design? Mark Lewis
• 21:54   Re: Optmal tags design? Bryan Murphy

19 July 2007

• 07:23   Re: improvement suggestions for performance design Kalle Hallivuori
• 10:14   Re: [GENERAL] Parrallel query execution for UNION ALL Queries Dimitri Fontaine
• 14:39   Re: [GENERAL] Parrallel query execution for UNION ALL Queries Luke Lonergan
• 15:28   User concurrency thresholding: where do I look? Josh Berkus
• 15:42   Re: User concurrency thresholding: where do I look? Joshua D. Drake
• 15:49   Re: User concurrency thresholding: where do I look? Alvaro Herrera
• 16:21   Re: User concurrency thresholding: where do I look? Josh Berkus
• 16:44   Is it possible to know where is the "deadlock" Arnau
• 17:03   Re: Is it possible to know where is the "deadlock" Bill Moran
• 17:05   Re: Is it possible to know where is the "deadlock" Claus Guttesen
• 17:25   Re: User concurrency thresholding: where do I look? Tom Lane
• 17:33   Trying to tune postgres, how is this config? Pat Maddox
• 17:37   Re: User concurrency thresholding: where do I look? Alvaro Herrera
• 17:45   Re: User concurrency thresholding: where do I look? Tom Lane
• 18:27   Re: User concurrency thresholding: where do I look? Joshua D. Drake
• 19:04   Re: User concurrency thresholding: where do I look? Greg Smith

20 July 2007

• 00:41   Improving select peformance Carlos H. Reimer
• 01:18   Re: User concurrency thresholding: where do I look? Josh Berkus
• 01:19   Problems with posting Carlos H. Reimer
• 01:31   Re: Improving select peformance Tom Lane
• 01:45   Re: User concurrency thresholding: where do I look? Tom Lane
• 04:37   Re: User concurrency thresholding: where do I look? Josh Berkus
• 04:59   8.2 -> 8.3 performance numbers Jim Nasby
• 11:46   Re: User concurrency thresholding: where do I look? Gregory Stark
• 15:43   Simple query showing 270 hours of CPU time Dan Harris
• 16:42   Re: Simple query showing 270 hours of CPU time Tom Lane
• 16:53   Re: Simple query showing 270 hours of CPU time PFC
• 17:05   Re: 8.2 -> 8.3 performance numbers Josh Berkus
• 17:05   Re: User concurrency thresholding: where do I look? Greg Smith
• 17:18   Re: User concurrency thresholding: where do I look? Josh Berkus
• 17:21   Re: Simple query showing 270 hours of CPU time Dan Harris
• 18:09   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 18:12   Re: Simple query showing 270 hours of CPU time Tom Lane
• 18:18   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 18:24   Re: User concurrency thresholding: where do I look? Tom Lane
• 18:32   Re: 8.2 -> 8.3 performance numbers Jim Nasby
• 18:56   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 19:13   Re: User concurrency thresholding: where do I look? Tom Lane
• 19:46   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 20:16   Re: User concurrency thresholding: where do I look? Tom Lane
• 20:51   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 20:57   Re: User concurrency thresholding: where do I look? Tom Lane
• 21:24   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 23:24   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Josh Berkus
• 23:27   Re: large number of connected connections to postgres database (v8.0) Josh Berkus

21 July 2007

• 00:19   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Gavin M. Roy
• 03:57   Re: User concurrency thresholding: where do I look? David Boreham
• 04:26   Re: User concurrency thresholding: where do I look? Tom Lane

22 July 2007

• 15:41   Simple select hangs while CPU close to 100% Jozsef Szalay
• 15:52   Re: Simple select hangs while CPU close to 100% Pavel Stehule
• 16:44   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Luke Lonergan
• 18:35   Re: Simple select hangs while CPU close to 100% Adam Tauno Williams

23 July 2007

• 08:50   Re: User concurrency thresholding: where do I look? Simon Riggs
• 11:52   Re: insert vs select into performance Michael Stone
• 14:13   Re: User concurrency thresholding: where do I look? Tom Lane
• 14:38   Re: User concurrency thresholding: where do I look? Simon Riggs
• 14:55   Re: User concurrency thresholding: where do I look? Tom Lane
• 15:47   Re: User concurrency thresholding: where do I look? Simon Riggs
• 16:36   Re: User concurrency thresholding: where do I look? Tom Lane
• 16:47   multicolumn index column order valgog
• 17:00   Re: multicolumn index column order Tom Lane
• 17:13   Re: multicolumn index column order valgog
• 17:24   disable archiving Paul van den Bogaard
• 17:34   Re: disable archiving Alvaro Herrera
• 17:37   Re: disable archiving A. Kretschmer
• 17:39   Re: disable archiving Arjen van der Meijden
• 17:42   Re: disable archiving Paul van den Bogaard
• 17:50   Re: User concurrency thresholding: where do I look? Simon Riggs
• 17:50   Re: User concurrency thresholding: where do I look? Simon Riggs
• 18:19   Re: User concurrency thresholding: where do I look? Tom Lane
• 18:30   Re: User concurrency thresholding: where do I look? Simon Riggs

24 July 2007

• 04:04   Second SpecJAppserver2004 with PostgreSQL Jignesh K. Shah
• 07:33   Re: disable archiving valgog
• 07:40   Re: multicolumn index column order Valentine Gogichashvili
• 07:57   Re: multicolumn index column order andrew@pillette.com
• 08:12   Query performance issue Jonathan Gray
• 08:42   Re: Query performance issue Chris
• 08:48   Re: Query performance issue Chris
• 09:19   Re: Query performance issue Jonathan Gray
• 09:34   Re: Query performance issue Chris
• 09:50   Re: Query performance issue Jonathan Gray
• 14:39   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Marc Mamin
• 17:04   Table Statistics with pgAdmin III Campbell, Lance
• 17:24   Re: Table Statistics with pgAdmin III Jean-Max Reymond
• 17:50   Re: Table Statistics with pgAdmin III Dave Page
• 18:27   index over timestamp not being used Arnau
• 18:40   Re: Table Statistics with pgAdmin III Campbell, Lance
• 19:25   Re: index over timestamp not being used Tom Lane
• 19:31   Re: index over timestamp not being used Arnau
• 19:43   Re: index over timestamp not being used Tom Lane

25 July 2007

• 01:28   Re: 8.2 -> 8.3 performance numbers Merlin Moncure
• 01:40   Performance issue with 8.2.3 - "C" application Karl Denninger
• 02:46   Re: Performance issue with 8.2.3 - "C" application Tom Lane
• 02:55   Re: Performance issue with 8.2.3 - "C" application Karl Denninger
• 03:15   Re: Performance issue with 8.2.3 - "C" application Merlin Moncure
• 03:16   Re: Performance issue with 8.2.3 - "C" application Karl Denninger
• 03:25   Re: Performance issue with 8.2.3 - "C" application Tom Lane
• 03:35   Re: Performance issue with 8.2.3 - "C" application Karl Denninger
• 06:18   Re: Performance issue with 8.2.3 - "C" application Nis Jørgensen
• 07:59   Re: Performance issue with 8.2.3 - "C" application Gregory Stark
• 08:34   Re: multicolumn index column order valgog
• 09:00   Re: Table Statistics with pgAdmin III Dave Page
• 12:53   Re: [pgsql-advocacy] 8.2 -> 8.3 performance numbers Simon Riggs
• 13:04   Re: index over timestamp not being used Mario Weilguni
• 13:07   Re: [pgsql-advocacy] 8.2 -> 8.3 performance numbers Mario Weilguni
• 13:35   Re: index over timestamp not being used Ansgar -59cobalt- Wiechers
• 14:08   Re: [pgsql-advocacy] 8.2 -> 8.3 performance numbers Simon Riggs
• 14:09   Re: [pgsql-advocacy] 8.2 -> 8.3 performance numbers Merlin Moncure
• 14:21   Re: [pgsql-advocacy] 8.2 -> 8.3 performance numbers Simon Riggs
• 14:43   Re: [pgsql-advocacy] 8.2 -> 8.3 performance numbers Gregory Stark
• 17:37   Re: Simple select hangs while CPU close to 100% Jozsef Szalay
• 17:42   Re: Simple select hangs while CPU close to 100% Pavel Stehule
• 17:51   Re: Simple select hangs while CPU close to 100% Jozsef Szalay
• 17:59   Re: Simple select hangs while CPU close to 100% Bill Moran
• 18:12   Re: Simple select hangs while CPU close to 100% Bill Moran
• 18:48   Re: Simple select hangs while CPU close to 100% Jozsef Szalay
• 18:53   Affect of Reindexing on Vacuum Times Y Sidhu
• 19:06   Re: Simple select hangs while CPU close to 100% Pavel Stehule
• 20:28   Re: Simple select hangs while CPU close to 100% Bill Moran
• 20:43   Insert Statements Hanging Pallav Kalva
• 20:55   Re: Insert Statements Hanging Alan Hodgson
• 21:01   Re: Performance issue with 8.2.3 - "C" application Karl Denninger
• 22:59   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 23:24   Re: User concurrency thresholding: where do I look? Tom Lane

26 July 2007

• 08:44   performance of postgresql in replication using slony angga erwina
• 13:24   disk filling up Brandon Shalton
• 13:34   Re: disk filling up Bill Moran
• 14:30   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 14:37   Re: disk filling up Mark Lewis
• 14:40   Re: User concurrency thresholding: where do I look? Tom Lane
• 14:45   Re: disk filling up Joshua D. Drake
• 15:25   Re: User concurrency thresholding: where do I look? Simon Riggs
• 15:27   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 15:43   Re: User concurrency thresholding: where do I look? Tom Lane
• 15:50   Re: User concurrency thresholding: where do I look? Simon Riggs
• 17:21   Re: performance of postgresql in replication using slony Jeff Davis
• 19:04   Re: performance of postgresql in replication using slony Chris Browne
• 19:44   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 20:02   Re: User concurrency thresholding: where do I look? Robert Lor
• 20:04   Re: User concurrency thresholding: where do I look? Simon Riggs
• 21:18   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 22:43   update, truncate and vacuum Scott Feldstein
• 23:17   Re: update, truncate and vacuum Luke Lonergan
• 23:28   Re: Affect of Reindexing on Vacuum Times Jim Nasby
• 23:59   Re: update, truncate and vacuum Dave Dutcher

27 July 2007

• 01:03   Re: disk filling up Mark Kirkwood
• 03:43   Re: disk filling up Yudhvir Singh Sidhu
• 08:58   Re: User concurrency thresholding: where do I look? Alvaro Herrera
• 09:14   Re: User concurrency thresholding: where do I look? Simon Riggs
• 09:14   Re: User concurrency thresholding: where do I look? Simon Riggs
• 12:45   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 13:44   Re: disk filling up Merlin Moncure
• 17:27   Slow query with backwards index scan Tilmann Singer
• 18:27   Re: How to use a trigger to write rows to a remote server Merlin Moncure
• 18:29   Re: Slow query with backwards index scan Nis Jørgensen
• 19:11   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 20:05   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 21:32   Vacuum looping? Steven Flatt

28 July 2007

• 13:16   Re: Slow query with backwards index scan Tilmann Singer
• 14:37   Re: Vacuum looping? Tom Lane
• 16:36   Re: Vacuum looping? Jim C. Nasby
• 19:04   Re: Slow query with backwards index scan andrew@pillette.com
• 19:27   Re: Slow query with backwards index scan Tilmann Singer
• 19:27   select on 1milion register = 6s Bruno Rodrigues Siqueira
• 19:51   Re: select on 1milion register = 6s Craig James
• 19:57   Re: select on 1milion register = 6s Hervé Piedvache
• 19:58   Re: Slow query with backwards index scan Craig James
• 20:04   Re: Slow query with backwards index scan Jeremy Harris
• 20:12   RES: select on 1milion register = 6s Bruno Rodrigues Siqueira
• 20:44   Re: Slow query with backwards index scan andrew@pillette.com
• 20:54   Re: Slow query with backwards index scan Tilmann Singer
• 22:30   Re: RES: select on 1milion register = 6s Ragnar
• 22:39   RES: RES: select on 1milion register = 6s Bruno Rodrigues Siqueira
• 22:40   RES: select on 1milion register = 6s Bruno Rodrigues Siqueira
• 23:07   RES: select on 1milion register = 6s Bruno Rodrigues Siqueira

29 July 2007

• 04:51   Re: select on 1milion register = 6s Scott Marlowe
• 14:22   Questions on Tags table schema Jay Kang
• 16:35   Re: RES: select on 1milion register = 6s Decibel!
• 16:44   RES: RES: select on 1milion register = 6s Bruno Rodrigues Siqueira
• 18:02   Re: select on 1milion register = 6s Alvaro Herrera

30 July 2007

• 01:29   Re: RES: RES: select on 1milion register = 6s Decibel!
• 06:54   Re: RES: RES: select on 1milion register = 6s Decibel!
• 07:21   Re: Questions on Tags table schema Richard Huxton
• 10:13   Re: Questions on Tags table schema Jay Kang
• 10:28   Re: Questions on Tags table schema Richard Huxton
• 10:49   Re: Questions on Tags table schema Richard Huxton
• 11:26   Re: Questions on Tags table schema Jay Kang
• 11:57   Re: Questions on Tags table schema Richard Huxton
• 15:01   Re: Questions on Tags table schema Richard Huxton
• 16:04   Re: Vacuum looping? Steven Flatt
• 16:31   Re: Slow query with backwards index scan Nis Jørgensen
• 19:10   Re: Slow query with backwards index scan Tilmann Singer
• 19:23   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 20:06   Re: Slow query with backwards index scan Nis Jørgensen
• 20:40   Re: Questions on Tags table schema Ron Mayer
• 20:57   Re: multicolumn index column order Lew
• 21:26   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Dimitri
• 21:42   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Luke Lonergan

31 July 2007

• 01:08   Query optimization.... Karl Denninger
• 05:22   Re: disk filling up Tom Lane
• 05:24   Re: Vacuum looping? Decibel!
• 08:23   Seq scan on join table despite index and high statistics Henrik Zagerholm
• 14:15   Using EXECUTE in a function Andreas Tille
• 14:36   Semantics of PostgreSQL Server Log Stats Camilo Porto
• 15:13   Re: deadlock detected when calling function (Call function_name) Sachchida Ojha
• 15:28   Re: deadlock detected when calling function (Call function_name) Alvaro Herrera
• 16:16   Re: disk filling up Merlin Moncure
• 16:39   Re: deadlock detected when calling function (Callfunction_name) Sachchida Ojha
• 18:22   Re: Semantics of PostgreSQL Server Log Stats Bruce Momjian
• 21:32   Re: User concurrency thresholding: where do I look? Josh Berkus
• 21:46   Re: User concurrency thresholding: where do I look? Jignesh K. Shah
• 22:15   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Dimitri