Mailing lists [pgsql-performance]

2 July 2007

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

3 July 2007

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

4 July 2007

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

5 July 2007

• 09:01   Re: Filesystem Direct I/O and WAL sync option Dimitri
• 09:39   improvement suggestions for performance design tfinneid@ifi.uio.no
• 10:00   Re: improvement suggestions for performance design Heikki Linnakangas
• 10:36   Re: improvement suggestions for performance design tfinneid@ifi.uio.no
• 11:57   Re: improvement suggestions for performance design Y Sidhu
• 12:49   Re: improvement suggestions for performance design tfinneid@ifi.uio.no
• 13:10   Re: improvement suggestions for performance design Y Sidhu
• 14:49   Re: Query is taking 5 HOURS to Complete on 8.1 version smiley2211
• 15:05   Re: Query is taking 5 HOURS to Complete on 8.1 version Alvaro Herrera
• 15:47   Re: improvement suggestions for performance design Heikki Linnakangas
• 19:55   Re: improvement suggestions for performance design Thomas Finneid
• 21:39   Re: PostgreSQL Configuration Tool for Dummies Magnus Hagander
• 23:28   Direct I/O lai yoke hman
• 23:44   Performance of PostgreSQL and Oracle lai yoke hman

6 July 2007

• 00:59   Re: Performance of PostgreSQL and Oracle Tom Lane
• 01:26   Re: PostgreSQL Configuration Tool for Dummies Harald Armin Massa
• 08:30   Re: improvement suggestions for performance design Kalle Hallivuori
• 11:40   Re: Direct I/O Alvaro Herrera
• 11:42   Advice about how to delete Arnau
• 12:05   Re: Advice about how to delete Michael Glaesemann
• 12:56   Re: Advice about how to delete Arnau
• 13:03   Re: Direct I/O Jignesh K. Shah
• 13:19   Re: Advice about how to delete Heikki Linnakangas

8 July 2007

• 07:06   Re: improvement suggestions for performance design Thomas Finneid
• 13:25   Re: improvement suggestions for performance design Kalle Hallivuori

9 July 2007

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

10 July 2007

• 05:01   Re: PostgreSQL publishes first real benchmark Heiko W.Rupp
• 09:53   Re: Filesystem Direct I/O and WAL sync option Dimitri
• 11:47   Query Analyser Gauri Kanekar
• 12:05   tuning a function to insert/retrieve values from a reference table Marc Mamin
• 12:41   Re: tuning a function to insert/retrieve values from a reference table Tom Lane
• 21:47   Equivalent queries produce different plans Craig James
• 22:00   Re: Equivalent queries produce different plans Craig James
• 22:25   Re: Equivalent queries produce different plans Tom Lane

11 July 2007

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

12 July 2007

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

13 July 2007

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

14 July 2007

• 05:30   Re: FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950 Hannes Dorbath
• 05:34   Re: FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950 Steinar H. Gunderson
• 06:58   Re: FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950 Gregory Stark
• 07:20   Re: FORGOT TO CONFIGURE RAID! DELL POWEREDGE 2950 Hannes Dorbath
• 12:51   Vacuum full considered useful ;) Patric de Waha
• 13:24   Re: Vacuum full considered useful ;) Joshua D. Drake
• 13:34   Re: Vacuum full considered useful ;) Tom Lane
• 13:34   Re: Vacuum full considered useful ;) Guillaume Lelarge
• 23:26   Re: Vacuum full considered useful ;) Vivek Khera

15 July 2007

• 13:38   slony over LAN and VPN angga erwina
• 13:42   slony over VPN and LAN angga erwina

16 July 2007

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

17 July 2007

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

18 July 2007

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

19 July 2007

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

20 July 2007

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

21 July 2007

• 00:57   Re: User concurrency thresholding: where do I look? David Boreham
• 01:26   Re: User concurrency thresholding: where do I look? Tom Lane

22 July 2007

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

23 July 2007

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

24 July 2007

• 01:04   Second SpecJAppserver2004 with PostgreSQL Jignesh K. Shah
• 04:33   Re: disable archiving valgog
• 04:40   Re: multicolumn index column order Valentine Gogichashvili
• 04:57   Re: multicolumn index column order andrew@pillette.com
• 05:12   Query performance issue Jonathan Gray
• 05:42   Re: Query performance issue Chris
• 05:48   Re: Query performance issue Chris
• 06:19   Re: Query performance issue Jonathan Gray
• 06:34   Re: Query performance issue Chris
• 06:50   Re: Query performance issue Jonathan Gray
• 11:39   Re: Postgres configuration for 64 CPUs, 128 GB RAM... Marc Mamin
• 14:04   Table Statistics with pgAdmin III Campbell, Lance
• 14:24   Re: Table Statistics with pgAdmin III Jean-Max Reymond
• 14:50   Re: Table Statistics with pgAdmin III Dave Page
• 15:27   index over timestamp not being used Arnau
• 15:40   Re: Table Statistics with pgAdmin III Campbell, Lance
• 16:25   Re: index over timestamp not being used Tom Lane
• 16:31   Re: index over timestamp not being used Arnau
• 16:43   Re: index over timestamp not being used Tom Lane
• 22:28   Re: 8.2 -> 8.3 performance numbers Merlin Moncure
• 22:40   Performance issue with 8.2.3 - "C" application Karl Denninger
• 23:46   Re: Performance issue with 8.2.3 - "C" application Tom Lane
• 23:55   Re: Performance issue with 8.2.3 - "C" application Karl Denninger

25 July 2007

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

26 July 2007

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

27 July 2007

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

28 July 2007

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

29 July 2007

• 01:51   Re: select on 1milion register = 6s Scott Marlowe
• 11:22   Questions on Tags table schema Jay Kang
• 13:35   Re: RES: select on 1milion register = 6s Decibel!
• 13:44   RES: RES: select on 1milion register = 6s Bruno Rodrigues Siqueira
• 15:02   Re: select on 1milion register = 6s Alvaro Herrera
• 22:29   Re: RES: RES: select on 1milion register = 6s Decibel!

30 July 2007

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

31 July 2007

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