Mailing lists [pgsql-performance]

1 May 2006

• 00:36   Re: query performance question Dave Dutcher
• 08:13   Super-smack? Scott Sipe
• 11:35   Re: Easy question mlartz@gmail.com
• 11:55   Re: Super-smack? Steinar H. Gunderson
• 13:06   Re: Super-smack? Steve Woodcock
• 15:15   Re: Super-smack? Tom Lane
• 15:55   Re: Worsening performance with 7.4 on flash-based system Scott Marlowe
• 17:00   Re: Super-smack? Mikael Carneholm
• 17:34   Cluster vs. non-cluster query planning Nolan Cafferky
• 17:43   Re: Super-smack? Tom Lane
• 18:08   Re: hardare config question Erik Myllymaki
• 18:16   Re: hardare config question Mark Lewis
• 18:29   Re: hardare config question Vivek Khera
• 18:45   Re: hardare config question Erik Myllymaki
• 18:46   Re: hardare config question Tom Arthurs
• 18:50   Re: hardare config question Luke Lonergan
• 18:52   Re: hardare config question Scott Marlowe
• 19:02   Postgres 7.4 and vacuum_cost_delay. Chris Mckenzie
• 19:41   Re: hardare config question Erik Myllymaki
• 19:48   Re: Cluster vs. non-cluster query planning Nolan Cafferky
• 20:30   Re: Cluster vs. non-cluster query planning Tom Lane
• 21:08   Re: Cluster vs. non-cluster query planning Nolan Cafferky
• 21:33   Re: Hardware: HP StorageWorks MSA 1500 Mikael Carneholm
• 23:35   Re: Cluster vs. non-cluster query planning Tom Lane

2 May 2006

• 00:02   Re: Cluster vs. non-cluster query planning Nolan Cafferky
• 02:14   Why is plan (and performance) different on partitioned table? Mark Liberman
• 02:59   Re: Why is plan (and performance) different on partitioned table? Tom Lane
• 04:44   Re: Why is plan (and performance) different on partitioned table? Tom Lane
• 17:15   Re: Easy question Jim C. Nasby
• 17:16   Re: Why so slow? Markus Schaber
• 17:16   Re: Slow restoration question Jim C. Nasby
• 18:27   postgresql transaction id monitoring with nagios Tony Wasson
• 18:41   Re: Slow restoration question Brendan Duddridge
• 18:49   Re: Slow restoration question Mark Lewis
• 18:50   Re: postgresql transaction id monitoring with nagios Vivek Khera
• 19:03   Re: postgresql transaction id monitoring with nagios Alvaro Herrera
• 19:06   Re: postgresql transaction id monitoring with nagios Tony Wasson
• 19:07   Re: postgresql transaction id monitoring with nagios Alvaro Herrera
• 19:12   Re: postgresql transaction id monitoring with nagios Vivek Khera
• 19:28   Re: Why is plan (and performance) different on partitioned table? Mark Liberman
• 19:34   Re: Slow restoration question Will Reese
• 20:13   Re: Why so slow? Jim C. Nasby
• 20:17   Re: Why so slow? Jim C. Nasby
• 20:19   Re: postgresql transaction id monitoring with nagios Bruno Wolff III
• 20:28   Re: Why is plan (and performance) different on partitioned table? Tom Lane
• 20:29   Re: Performance Issues on Opteron Dual Core Jim C. Nasby
• 20:36   Re: Super-smack? Jim C. Nasby
• 20:50   Re: postgresql transaction id monitoring with nagios Tony Wasson
• 21:30   Re: Cluster vs. non-cluster query planning Jim C. Nasby
• 21:39   Re: Postgres 7.4 and vacuum_cost_delay. Jim C. Nasby
• 21:42   Re: postgresql transaction id monitoring with nagios Jim C. Nasby
• 21:46   Re: postgresql transaction id monitoring with nagios Jim C. Nasby
• 21:47   Re: Postgres 7.4 and vacuum_cost_delay. Chris Mckenzie
• 21:53   Re: Slow restoration question Jim C. Nasby
• 22:50   Re: Performance Issues on Opteron Dual Core Jan de Visser
• 22:54   Re: Postgres 7.4 and vacuum_cost_delay. Jim C. Nasby
• 22:56   Nested loop join and date range query Ian Burrell
• 22:56   Re: Performance Issues on Opteron Dual Core Jim C. Nasby
• 23:00   Re: Postgres 7.4 and vacuum_cost_delay. Steinar H. Gunderson
• 23:20   Killing long-running queries Dan Harris
• 23:28   Re: Why so slow? Bill Moran
• 23:30   Re: Killing long-running queries Tom Lane
• 23:44   Re: Killing long-running queries Tony Wasson
• 23:49   Re: PL/pgSQL Loop Vs. Batch Update David Wheeler
• 23:53   Re: PL/pgSQL Loop Vs. Batch Update David Wheeler
• 23:53   Re: Killing long-running queries Dan Harris
• 23:59   Re: Killing long-running queries Devrim GUNDUZ

3 May 2006

• 01:17   Re: PL/pgSQL Loop Vs. Batch Update David Wheeler
• 02:09   Re: Killing long-running queries Will Reese
• 02:10   Re: Slow restoration question Brendan Duddridge
• 03:04   Re: Nested loop join and date range query Tom Lane
• 06:10   Re: Easy question Bert
• 06:15   Re: Slow restoration question Eric Lam
• 06:16   Lot'sa joins - performance tip-up, please? Mario Splivalo
• 06:17   Re: Running on an NFS Mounted Directory Fortuitous Technologies
• 06:18   Re: Performance Issues on Opteron Dual Core Gregory Stewart
• 06:19   Re: Performance Issues on Opteron Dual Core Gregory Stewart
• 06:49   Re: Easy question Chris
• 07:29   Re: Performance Issues on Opteron Dual Core Magnus Hagander
• 11:22   Re: Why so slow? Michael Stone
• 12:19   Re: Slow restoration question Michael Stone
• 12:30   Re: Performance Issues on Opteron Dual Core Jan de Visser
• 13:49   Re: Slow restoration question Jeff Trout
• 14:16   Re: Slow restoration question Vivek Khera
• 14:47   Re: Slow restoration question Jeff Trout
• 15:20   Re: Lot'sa joins - performance tip-up, please? Dave Dutcher
• 16:02   Re: Slow restoration question Michael Stone
• 16:07   Re: Slow restoration question Scott Marlowe
• 17:06   Re: Slow restoration question Michael Stone
• 17:54   Re: Nested loop join and date range query Ian Burrell
• 17:58   Re: Lot'sa joins - performance tip-up, please? Tom Lane
• 18:08   Re: Slow restoration question Jim C. Nasby
• 19:27   Re: Slow restoration question Michael Stone
• 19:40   Re: Slow restoration question Scott Marlowe
• 20:53   Re: Slow restoration question Michael Stone
• 21:30   Re: Slow restoration question Scott Marlowe
• 22:02   Re: Slow restoration question Michael Stone

4 May 2006

• 12:28   Re: Postgres 7.4 and vacuum_cost_delay. Andrew Sullivan
• 14:49   Re: Postgres 7.4 and vacuum_cost_delay. Chris Mckenzie
• 17:47   Re: Performance Issues on Opteron Dual Core Jim C. Nasby
• 17:49   Re: Performance Issues on Opteron Dual Core Jim C. Nasby
• 17:54   Re: Why so slow? Jim C. Nasby

5 May 2006

• 07:51   Re: Performance Issues on Opteron Dual Core Magnus Hagander
• 09:50   Re: Super-smack? Bruce Momjian
• 11:54   Memory and/or cache issues? mcelroy, tim
• 13:25   Re: Memory and/or cache issues? Tom Lane
• 13:31   Re: Memory and/or cache issues? Alvaro Herrera
• 13:31   Re: Memory and/or cache issues? mcelroy, tim
• 13:44   Re: Memory and/or cache issues? Tom Lane
• 14:12   Re: Memory and/or cache issues? mcelroy, tim
• 14:24   Re: Memory and/or cache issues? Michael Stone
• 14:31   Re: Memory and/or cache issues? Dave Dutcher
• 14:32   Re: Memory and/or cache issues? mcelroy, tim
• 14:40   Re: Memory and/or cache issues? Michael Stone
• 14:41   Re: Memory and/or cache issues? mcelroy, tim
• 14:50   Re: Memory and/or cache issues? mcelroy, tim
• 14:53   Re: Memory and/or cache issues? mcelroy, tim
• 14:54   Re: Memory and/or cache issues? Michael Stone
• 15:16   Re: Memory and/or cache issues? Craig A. James
• 16:33   Re: Memory and/or cache issues? Gábriel Ákos
• 17:10   Re: Memory and/or cache issues? Michael Stone

6 May 2006

• 00:31   Re: Memory and/or cache issues? Jim C. Nasby
• 00:33   Re: Memory and/or cache issues? Jim C. Nasby
• 00:35   Re: Memory and/or cache issues? Jim C. Nasby
• 04:34   Re: Memory and/or cache issues? David Boreham
• 14:59   Re: Memory and/or cache issues? mcelroy, tim

7 May 2006

• 01:34   pg_dump index creation order Ed L.
• 03:09   Re: pg_dump index creation order Ed L.
• 17:08   Re: pg_dump index creation order Jim C. Nasby

8 May 2006

• 09:06   extremely slow when execute select/delete for certain tables only... kah_hang_ang@toray.com.my
• 09:21   Re: extremely slow when execute select/delete for certain Markus Schaber
• 11:00   Query runs 38 seconds for small database! Andrus
• 14:47   Re: Query runs 38 seconds for small database! Tom Lane
• 15:06   Re: Memory and/or cache issues? Vivek Khera
• 16:18   Re: Query runs 38 seconds for small database! Andrus
• 16:27   Re: Query runs 38 seconds for small database! Tom Lane
• 17:06   Re: Query runs 38 seconds for small database! Andrus
• 17:27   Re: extremely slow when execute select/delete for certain Jim C. Nasby
• 17:28   Re: Query runs 38 seconds for small database! Jim C. Nasby
• 17:29   performance question (something to do w/ parameterized stmts?, wrong index types?) Jeffrey Tenny
• 17:31   Re: Memory and/or cache issues? Jim C. Nasby
• 17:38   Re: performance question (something to do w/ parameterized stmts?, wrong index types?) Jim C. Nasby
• 17:38   Re: Query runs 38 seconds for small database! Andrus
• 17:42   Re: performance question (something to do w/ Mark Lewis
• 17:46   Re: Query runs 38 seconds for small database! Jim C. Nasby
• 17:50   Re: performance question (something to do w/ Jim C. Nasby
• 18:00   Re: performance question (something to do w/ Tom Lane
• 18:10   Re: Query runs 38 seconds for small database! Andrus
• 19:19   Re: Query runs 38 seconds for small database! Jan de Visser
• 19:38   Re: Memory and/or cache issues? Vivek Khera
• 19:43   Re: performance question (something to do w/ parameterized Jeffrey Tenny
• 19:48   Re: Query runs 38 seconds for small database! Tom Lane
• 19:51   Re: performance question (something to do w/ parameterized Jeffrey Tenny
• 20:03   Re: Query runs 38 seconds for small database! Alvaro Herrera
• 20:09   Re: performance question (something to do w/ parameterized Tom Lane
• 20:40   Re: performance question (something to do w/ parameterized Jeffrey Tenny
• 20:50   Re: performance question (something to do w/ parameterized Tom Lane
• 21:25   Re: Memory and/or cache issues? Michael Stone
• 22:11   Re: performance question (something to do w/ parameterized Jeffrey Tenny
• 22:16   Re: performance question (something to do w/ parameterized Jeffrey Tenny
• 23:06   Re: performance question (something to do w/ parameterized Tom Lane
• 23:35   Re: performance question (something to do w/ parameterized Jeffrey Tenny
• 23:37   Re: performance question (something to do w/ parameterized Tom Lane

9 May 2006

• 00:08   Re: performance question (something to do w/ parameterized Klint Gore
• 01:30   Assistance with optimizing query - same SQL, different category_id = Seq Scan Brendan Duddridge
• 01:39   Re: extremely slow when execute select/delete for certain tables kah_hang_ang@toray.com.my
• 03:54   Re: Takes too long to fetch the data from database soni de
• 07:41   Re: Takes too long to fetch the data from database Bruno Wolff III
• 08:37   Big IN() clauses etc : feature proposal PFC
• 09:16   Arguments Pro/Contra Software Raid Hannes Dorbath
• 09:32   Re: Big IN() clauses etc : feature proposal PFC
• 09:32   Re: Big IN() clauses etc : feature proposal Christian Kratzer
• 09:42   Re: Big IN() clauses etc : feature proposal Christian Kratzer
• 10:09   Re: [HACKERS] Big IN() clauses etc : feature proposal PFC
• 10:36   Re: [HACKERS] Big IN() clauses etc : feature proposal Martijn van Oosterhout
• 10:52   Re: [HACKERS] Big IN() clauses etc : feature proposal Csaba Nagy
• 11:28   Re: [HACKERS] Big IN() clauses etc : feature proposal PFC
• 11:36   Re: Arguments Pro/Contra Software Raid Grega Bremec
• 12:50   Re: Memory and/or cache issues? mcelroy, tim
• 13:32   Re: Big IN() clauses etc : feature proposal Tom Lane
• 14:41   Re: [GENERAL] Arguments Pro/Contra Software Raid Steve Atkins
• 15:00   Re: [HACKERS] Big IN() clauses etc : feature proposal Greg Stark
• 15:18   Re: Arguments Pro/Contra Software Raid Bruno Wolff III
• 15:51   Re: [GENERAL] Arguments Pro/Contra Software Raid Joshua D. Drake
• 16:28   Re: [HACKERS] Big IN() clauses etc : feature proposal PFC
• 16:37   Re: [HACKERS] Big IN() clauses etc : feature proposal PFC
• 16:43   Re: [HACKERS] Big IN() clauses etc : feature proposal Dawid Kuroczko
• 16:48   Re: [HACKERS] Big IN() clauses etc : feature proposal PFC
• 17:52   Re: [GENERAL] Arguments Pro/Contra Software Raid Steve Atkins
• 17:57   Re: Arguments Pro/Contra Software Raid Vivek Khera
• 18:05   Re: [GENERAL] Arguments Pro/Contra Software Raid Douglas McNaught
• 18:25   Re: Arguments Pro/Contra Software Raid Joshua D. Drake
• 18:26   Re: [GENERAL] Arguments Pro/Contra Software Raid Joshua D. Drake
• 18:34   Re: [GENERAL] Arguments Pro/Contra Software Raid Steve Atkins
• 18:43   Re: [GENERAL] Arguments Pro/Contra Software Raid Joshua D. Drake
• 19:04   Re: [GENERAL] Arguments Pro/Contra Software Raid Scott Marlowe
• 19:13   Re: [HACKERS] Big IN() clauses etc : feature proposal Tom Lane
• 22:40   Slow C Function Adam Palmblad
• 23:09   Re: Slow C Function Joshua D. Drake

10 May 2006

• 00:38   Postgres gets stuck Craig A. James
• 00:51   Re: Postgres gets stuck Chris
• 01:00   Re: [GENERAL] Arguments Pro/Contra Software Raid Bruce Momjian
• 01:03   Re: [GENERAL] Arguments Pro/Contra Software Raid Bruce Momjian
• 02:40   Re: Arguments Pro/Contra Software Raid William Yu
• 02:54   Re: Lot'sa joins - performance tip-up, please? Mario Splivalo
• 02:54   Re: Lot'sa joins - performance tip-up, please? Mario Splivalo
• 02:54   Re: Performance Issues on Opteron Dual Core Gregory Stewart
• 02:54   slow variable against int?? Witold Strzelczyk
• 02:54   Re: performance question (something to do w/ Kenneth Marshall
• 02:54   Dynamically loaded C function performance Adam Palmblad
• 02:54    Adam Palmblad
• 02:54   VACUUM killing my CPU blender@jaskom.pl
• 02:54   Re: [GENERAL] Arguments Pro/Contra Software Raid Jean-Yves F. Barbier
• 02:55   Re: [HACKERS] Big IN() clauses etc : feature proposal Mitchell Skinner
• 02:55   PostgreSQL VACCUM killing CPU blender@jaskom.pl
• 03:13   UNSUBSCRIBE Shoaib Burq
• 03:15   Re: PostgreSQL VACCUM killing CPU Will Reese
• 03:28   Re: UNSUBSCRIBE Chris
• 03:29   Re: PostgreSQL VACCUM killing CPU Michael Glaesemann
• 03:29   Re: PostgreSQL VACCUM killing CPU Michael Glaesemann
• 03:52   Re: Slow C Function Tom Lane
• 03:59   Re: [GENERAL] Arguments Pro/Contra Software Raid Scott Lamb
• 04:08   Re: VACUUM killing my CPU Alan Hodgson
• 04:41   Re: [GENERAL] Arguments Pro/Contra Software Raid Greg Stark
• 04:50   Re: [GENERAL] Arguments Pro/Contra Software Raid Greg Stark
• 05:15   Re: UNSUBSCRIBE Tom Lane
• 05:22   Re: UNSUBSCRIBE Chris
• 05:43   Re: UNSUBSCRIBE Tom Lane
• 06:14   Re: UNSUBSCRIBE Michael Glaesemann
• 06:49   Re: [GENERAL] Arguments Pro/Contra Software Raid PFC
• 07:08   Re: VACUUM killing my CPU Rudi Starcevic
• 09:18   in memory views Thomas Vatter
• 09:36   Re: in memory views Tino Wildenhain
• 09:55   Re: in memory views Thomas Vatter
• 10:09   Re: in memory views Tino Wildenhain
• 10:43   Re: in memory views Thomas Vatter
• 11:12   Re: in memory views Hakan Kocaman
• 11:50   Question about explain-command... Clemens Eisserer
• 11:57   Re: in memory views Tino Wildenhain
• 12:15   Re: [GENERAL] Arguments Pro/Contra Software Raid Douglas McNaught
• 12:23   Re: in memory views Thomas Vatter
• 12:44   Re: Arguments Pro/Contra Software Raid Florian Weimer
• 13:29   Re: [HACKERS] Big IN() clauses etc : feature proposal Markus Schaber
• 13:54   Re: [GENERAL] Arguments Pro/Contra Software Raid Markus Schaber
• 14:01   Re: [GENERAL] Arguments Pro/Contra Software Raid Bruce Momjian
• 14:16   Re: [GENERAL] Arguments Pro/Contra Software Raid Vivek Khera
• 14:18   Re: PostgreSQL VACCUM killing CPU Wu Fengguang
• 14:36   Re: [GENERAL] Arguments Pro/Contra Software Raid Bruce Momjian
• 14:37   Re: [HACKERS] Big IN() clauses etc : feature proposal PFC
• 14:38   Re: [GENERAL] Arguments Pro/Contra Software Raid Markus Schaber
• 14:44   Re: [GENERAL] Arguments Pro/Contra Software Raid Scott Marlowe
• 14:47   Re: Question about explain-command... Dave Dutcher
• 14:51   Re: [GENERAL] Arguments Pro/Contra Software Raid Douglas McNaught
• 14:56   Re: [HACKERS] Big IN() clauses etc : feature proposal Martijn van Oosterhout
• 14:57   Re: [GENERAL] Arguments Pro/Contra Software Raid Markus Schaber
• 15:04   Re: [HACKERS] Big IN() clauses etc : feature proposal Markus Schaber
• 15:10   Re: [GENERAL] Arguments Pro/Contra Software Raid Scott Marlowe
• 15:10   Re: UNSUBSCRIBE Tom Lane
• 15:12   Re: in memory views Scott Marlowe
• 15:14   Re: Question about explain-command... Nis Jorgensen
• 15:40   Re: in memory views Thomas Vatter
• 15:45   Re: in memory views Scott Marlowe
• 15:45   Re: in memory views 
• 15:53   Re: [HACKERS] Big IN() clauses etc : feature proposal Nis Jorgensen
• 15:59   Re: [HACKERS] Big IN() clauses etc : feature proposal Markus Schaber
• 18:09   Re: UNSUBSCRIBE Bruno Wolff III
• 18:40   Re: [HACKERS] Big IN() clauses etc : feature proposal Jim C. Nasby
• 19:00   Re: [HACKERS] Big IN() clauses etc : feature proposal Jim C. Nasby
• 19:06   Re: [HACKERS] Big IN() clauses etc : feature proposal Jim C. Nasby
• 19:24   Re: [HACKERS] Big IN() clauses etc : feature proposal Jim C. Nasby
• 19:34   Re: [HACKERS] Big IN() clauses etc : feature proposal PFC
• 20:53   Re: in memory views Thomas Vatter
• 21:01   Re: in memory views Scott Marlowe
• 21:09   Re: in memory views Dave Dutcher
• 21:18   Re: in memory views Thomas Vatter
• 21:24   Re: in memory views Thomas Vatter
• 22:10   Re: Lot'sa joins - performance tip-up, please? Jim C. Nasby
• 22:16   Re: in memory views Kris Jurka
• 22:20   Re: UNSUBSCRIBE Jim C. Nasby
• 22:21   Re: UNSUBSCRIBE Jim C. Nasby
• 22:40   Same query - Slow in production Brian Wipf
• 23:07   Re: in memory views Thomas Vatter
• 23:57   Re: Same query - Slow in production Brian Wipf

11 May 2006

• 00:32   Re: [HACKERS] Big IN() clauses etc : feature proposal Tom Lane
• 01:20   Re: Same query - Slow in production Tom Lane
• 06:36   Speed Up Offset and Limit Clause Christian Paul Cosinas
• 06:51   Re: Speed Up Offset and Limit Clause Chris
• 07:04   Re: Speed Up Offset and Limit Clause PFC
• 07:06   Re: Speed Up Offset and Limit Clause Guillaume Cottenceau
• 08:31   Re: [HACKERS] Big IN() clauses etc : feature proposal Martijn van Oosterhout
• 12:58   Nested Loops vs. Hash Joins or Merge Joins Ketema Harris
• 15:26   Re: Postgres gets stuck Qingqing Zhou
• 15:36   Re: [HACKERS] Big IN() clauses etc : feature proposal Greg Stark
• 15:53   Re: Postgres gets stuck Craig A. James
• 17:18   Re: [HACKERS] Big IN() clauses etc : feature proposal Jim C. Nasby
• 18:03   Re: [HACKERS] Big IN() clauses etc : feature proposal Scott Marlowe
• 18:03   Re: [HACKERS] Big IN() clauses etc : feature proposal Martijn van Oosterhout
• 18:44   Re: [HACKERS] Big IN() clauses etc : feature proposal Martijn van Oosterhout
• 19:57   Re: [HACKERS] Big IN() clauses etc : feature proposal Jim C. Nasby
• 20:00   Re: [HACKERS] Big IN() clauses etc : feature proposal Jim C. Nasby
• 21:01   Re: [HACKERS] Big IN() clauses etc : feature proposal Jim C. Nasby
• 21:32   Re: [HACKERS] Big IN() clauses etc : feature proposal PFC
• 22:04   Re: slow variable against int?? Jim C. Nasby
• 22:05   Re: Dynamically loaded C function performance Jim C. Nasby
• 22:08   Re: Assistance with optimizing query - same SQL, different category_id = Seq Scan Jim C. Nasby
• 22:08   Re: [HACKERS] Big IN() clauses etc : feature proposal Tom Lane
• 22:19   Re: [GENERAL] Arguments Pro/Contra Software Raid Jim C. Nasby
• 22:32   Re: [GENERAL] Arguments Pro/Contra Software Raid Jim C. Nasby
• 22:38   Re: [GENERAL] Arguments Pro/Contra Software Raid Joshua D. Drake
• 22:41   Re: Question about explain-command... Jim C. Nasby
• 22:49   Re: Dynamically loaded C function performance Joe Conway
• 22:51   Re: Nested Loops vs. Hash Joins or Merge Joins Jim C. Nasby
• 22:58   Re: [HACKERS] Big IN() clauses etc : feature proposal Jim C. Nasby
• 23:01   Re: [GENERAL] Arguments Pro/Contra Software Raid Jim C. Nasby
• 23:20   Re: [GENERAL] Arguments Pro/Contra Software Raid Bruce Momjian
• 23:24   Re: [GENERAL] Arguments Pro/Contra Software Raid Joshua D. Drake
• 23:31   Re: [GENERAL] Arguments Pro/Contra Software Raid Bruce Momjian
• 23:41   Re: [GENERAL] Arguments Pro/Contra Software Raid Jim C. Nasby
• 23:46   Re: [GENERAL] Arguments Pro/Contra Software Raid Bruce Momjian

12 May 2006

• 00:00   Re: [GENERAL] Arguments Pro/Contra Software Raid Joshua D. Drake
• 00:03   Re: Postgres gets stuck Tom Lane
• 02:10   Re: Postgres gets stuck Craig A. James
• 02:51   Re: Postgres gets stuck Tom Lane
• 07:18   Re: [GENERAL] Arguments Pro/Contra Software Raid Bruno Wolff III
• 13:06   Wrong plan for subSELECT with GROUP BY Antal Attila
• 14:05   Re: Wrong plan for subSELECT with GROUP BY Tom Lane
• 14:49   Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows) andremachado
• 16:09   Re: slow variable against int?? Jim Nasby
• 18:23   stable function optimizations, revisited Phil Frost
• 19:12   Re: Wrong plan for subSELECT with GROUP BY Jim C. Nasby
• 19:14   Re: Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows) Jim C. Nasby
• 19:54   Re: Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows) Joshua D. Drake
• 22:19   Re: Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows) Tom Lane

13 May 2006

• 10:04   Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows) André Felipe Machado
• 21:26   Re: Firebird 1.5.3 X Postgresql 8.1.3 (linux and windows) Tom Lane

15 May 2006

• 08:48   Re: Wrong plan for subSELECT with GROUP BY Simon Riggs

16 May 2006

• 03:15   IMMUTABLE? David Wheeler
• 03:21   Re: IMMUTABLE? Tom Lane
• 04:22   Re: IMMUTABLE? David Wheeler
• 04:31   Re: IMMUTABLE? Tom Lane
• 09:40   Pgsql (and mysql) benchmark on T2000/Solaris and some profiling Arjen van der Meijden
• 09:48   Re: IMMUTABLE? Joachim Wieland
• 10:05   Re: Pgsql (and mysql) benchmark on T2000/Solaris and some profiling Qingqing Zhou
• 10:48   Re: Pgsql (and mysql) benchmark on T2000/Solaris and some Arjen van der Meijden
• 13:20   Re: Pgsql (and mysql) benchmark on T2000/Solaris and some Jignesh K. Shah
• 13:33   Re: IMMUTABLE? Tom Lane
• 13:54   Re: Pgsql (and mysql) benchmark on T2000/Solaris and some Arjen van der Meijden
• 15:53   Re: Pgsql (and mysql) benchmark on T2000/Solaris and some Jignesh K. Shah
• 16:55   Re: IMMUTABLE? Joachim Wieland
• 18:00   Re: IMMUTABLE? David Wheeler
• 18:30   Re: Pgsql (and mysql) benchmark on T2000/Solaris and some Arjen van der Meijden

17 May 2006

• 00:23   Adding and filling new column on big table Jonathan Blitz
• 01:29   Re: IMMUTABLE? Christopher Kings-Lynne
• 01:41   Re: Speed Up Offset and Limit Clause Christian Paul Cosinas
• 02:09   Re: IMMUTABLE? David Wheeler
• 02:20   Re: Speed Up Offset and Limit Clause Craig A. James
• 02:31   Re: Adding and filling new column on big table Michael Fuhr
• 06:13   Performance incorporate with JReport kah_hang_ang@toray.com.my
• 11:08   Re: Pgsql (and mysql) benchmark on T2000/Solaris and some Jignesh K. Shah
• 11:54   Re: Pgsql (and mysql) benchmark on T2000/Solaris and some Arjen van der Meijden
• 15:14   Re: Pgsql (and mysql) benchmark on T2000/Solaris and some Jignesh K. Shah
• 15:21   SQL CPU time usage Ruben Rubio Rey
• 15:51   Re: IMMUTABLE? Jim C. Nasby
• 15:55   Optimizer: limit not taken into account Craig A. James
• 16:24   Re: SQL CPU time usage john_oshea@wordbank.com
• 17:43   Re: Optimizer: limit not taken into account Bruno Wolff III
• 17:50   Performance/Maintenance test result collection Chris Mckenzie
• 18:22   Re: Optimizer: limit not taken into account Simon Riggs
• 18:30   Re: Optimizer: limit not taken into account Tom Lane
• 18:58   Re: Optimizer: limit not taken into account Craig A. James
• 19:04   Re: Speed Up Offset and Limit Clause Jim C. Nasby
• 19:20   Re: Optimizer: limit not taken into account Jim C. Nasby
• 19:24   Re: Performance/Maintenance test result collection Jim C. Nasby

18 May 2006

• 05:46   Re: Lot'sa joins - performance tip-up, please? Mario Splivalo
• 05:46   Re: [HACKERS] Big IN() clauses etc : feature proposal Zeugswetter Andreas DCP SD
• 07:49   Re: [HACKERS] Big IN() clauses etc : feature proposal Gregory S. Williamson
• 07:52   Re: Pgsql (and mysql) benchmark on T2000/Solaris and some Florian Weimer
• 09:57   Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle 10g2 Olivier Andreotti
• 10:13   Re: Lot'sa joins - performance tip-up, please? Markus Schaber
• 10:32   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle Chris Mair
• 10:43   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle Olivier Andreotti
• 10:48   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle 10g2 Gregory S. Williamson
• 10:49   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle Jean-Paul Argudo
• 10:59   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle 10g2 Olivier Andreotti
• 11:02   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle Guido Neitzer
• 12:44   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle Chris Mair
• 14:11   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle 10g2 Mikael Carneholm
• 14:48   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle 10g2 Tom Lane
• 14:52   Re: SQL CPU time usage Ruben Rubio Rey
• 15:20   Re: Performance/Maintenance test result collection Chris Mckenzie
• 15:52   why is bitmap index chosen for this query? Stephen Byers
• 15:59   Re: why is bitmap index chosen for this query? Steinar H. Gunderson
• 16:01   Re: SQL CPU time usage Ivan Zolotukhin
• 16:41   Re: why is bitmap index chosen for this query? Stephen Byers
• 16:46   Re: why is bitmap index chosen for this query? Steinar H. Gunderson
• 17:34   Re: why is bitmap index chosen for this query? Tom Lane
• 19:38   Re: why is bitmap index chosen for this query? Stephen Byers
• 19:48   Re: why is bitmap index chosen for this query? Steinar H. Gunderson
• 19:53   Re: why is bitmap index chosen for this query? Stephen Byers
• 20:16   Re: why is bitmap index chosen for this query? Steinar H. Gunderson
• 20:26   Re: why is bitmap index chosen for this query? Stephen Byers

19 May 2006

• 10:24   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle 10g2 Olivier Andreotti
• 13:10   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle 10g2 Tom Lane
• 20:16   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle Jim C. Nasby
• 20:21   Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle Jim C. Nasby
• 20:50   Re: Performance/Maintenance test result collection Jim C. Nasby
• 20:59   Re: why is bitmap index chosen for this query? Jim C. Nasby
• 23:11   How can I make this query faster (resend) Cstdenis

20 May 2006

• 02:37   utilizing multiple disks for i/o performance Kenji Morishige
• 04:51   Benchmarking Function David Wheeler

21 May 2006

• 08:22   Performs WAY better with enable_seqscan = off Brendan Duddridge
• 10:39   Re: Performs WAY better with enable_seqscan = off Ragnar
• 19:24   Re: Benchmarking Function Josh Berkus
• 20:01   Re: Performs WAY better with enable_seqscan = off Brendan Duddridge
• 22:45   Re: Benchmarking Function David Wheeler

22 May 2006

• 15:15   Re: utilizing multiple disks for i/o performance Scott Marlowe
• 15:20   Re: How can I make this query faster (resend) Jim C. Nasby
• 15:21   Re: utilizing multiple disks for i/o performance Jim C. Nasby
• 15:26   Re: Performs WAY better with enable_seqscan = off Jim C. Nasby
• 15:30   Re: How can I make this query faster (resend) Markus Schaber
• 15:30   Re: Performs WAY better with enable_seqscan = off Jim C. Nasby
• 17:20   Query hanging/not finishing inconsistently Meetesh Karia
• 18:50   Re: Query hanging/not finishing inconsistently Craig A. James
• 20:40   Re: Query hanging/not finishing inconsistently Meetesh Karia
• 22:33   slow query using sub select Tim Jones
• 23:07   Re: slow query using sub select Tom Lane
• 23:32   Re: slow query using sub select Jonathan Blitz
• 23:33   Re: Query performance Steinar H. Gunderson

23 May 2006

• 13:26   Re: slow query using sub select Tim Jones
• 17:40   Selects query stats? Dan Gorman
• 18:08   Re: Selects query stats? Mischa Sandberg
• 18:15   Re: Selects query stats? Dan Gorman
• 18:25   Re: Selects query stats? Mischa Sandberg
• 18:34   Re: Selects query stats? Dan Gorman
• 18:41   Re: Selects query stats? Jim C. Nasby
• 18:52   Re: Selects query stats? Simon Riggs
• 19:08   Re: Selects query stats? Dan Gorman
• 19:13   Re: Selects query stats? Tom Lane
• 19:50   Re: Selects query stats? Alvaro Herrera
• 19:56   Re: Selects query stats? Tom Lane
• 20:03   Re: Selects query stats? Jim C. Nasby
• 20:04   Re: Selects query stats? Guillaume Smet
• 21:47   Re: Selects query stats? Simon Riggs
• 22:11   Re: Selects query stats? Mischa Sandberg

24 May 2006

• 10:27   Re: Selects query stats? Robin Ericsson
• 19:45   Getting even more insert performance (250m+rows/day) Daniel J. Luke
• 20:02   Re: Getting even more insert performance (250m+rows/day) Dave Dutcher
• 20:03   Re: Getting even more insert performance (250m+rows/day) Steinar H. Gunderson
• 20:08   Re: Getting even more insert performance (250m+rows/day) Daniel J. Luke
• 20:10   Re: Getting even more insert performance (250m+rows/day) Daniel J. Luke
• 20:12   Re: Getting even more insert performance (250m+rows/day) Larry Rosenman
• 20:13   Re: Getting even more insert performance (250m+rows/day) Steinar H. Gunderson
• 20:18   Re: Getting even more insert performance (250m+rows/day) Mark Lewis
• 20:20   Re: Getting even more insert performance (250m+rows/day) Daniel J. Luke
• 20:21   Re: Getting even more insert performance (250m+rows/day) Daniel J. Luke
• 20:24   Re: Getting even more insert performance (250m+rows/day) Larry Rosenman
• 20:29   Re: Getting even more insert performance (250m+rows/day) Daniel J. Luke
• 21:32   Re: Getting even more insert performance (250m+rows/day) Jim C. Nasby
• 21:34   Re: Selects query stats? Jim C. Nasby

25 May 2006

• 00:53   Optimizing a huge_table/tiny_table join 
• 01:32   Re: Optimizing a huge_table/tiny_table join Joshua D. Drake
• 01:42   Re: Optimizing a huge_table/tiny_table join Tom Lane
• 03:40   Re: Getting even more insert performance (250m+rows/day) Ian Westmacott
• 16:16   lowering priority automatically at connection Chris Mair
• 16:26   Re: lowering priority automatically at connection Tom Lane
• 16:33   Re: Optimizing a huge_table/tiny_table join 
• 16:35   Re: lowering priority automatically at connection Chris Mair
• 16:48   Re: Optimizing a huge_table/tiny_table join Andrew Sullivan
• 16:55   Re: lowering priority automatically at connection Michael Fuhr
• 17:07   Re: Optimizing a huge_table/tiny_table join Dawid Kuroczko
• 20:07   is it possible to make this faster? Merlin Moncure
• 20:21   Re: is it possible to make this faster? Bruno Wolff III
• 20:32   Re: is it possible to make this faster? Merlin Moncure
• 20:36   Re: is it possible to make this faster? Steinar H. Gunderson
• 20:36   Re: is it possible to make this faster? Alan Hodgson
• 20:45   Re: is it possible to make this faster? Bruno Wolff III
• 20:52   Re: is it possible to make this faster? Tom Lane
• 20:54   Re: is it possible to make this faster? Merlin Moncure
• 21:08   Re: is it possible to make this faster? Steinar H. Gunderson
• 21:11   Re: is it possible to make this faster? Tom Lane
• 21:15   Re: is it possible to make this faster? Scott Marlowe
• 21:26   Re: is it possible to make this faster? Mark Lewis
• 22:13   Re: Optimizing a huge_table/tiny_table join Jim Nasby
• 22:17   Re: is it possible to make this faster? Jim Nasby
• 22:30   Re: is it possible to make this faster? Tom Lane
• 23:28   Re: Optimizing a huge_table/tiny_table join Mark Kirkwood

26 May 2006

• 01:26   Re: lowering priority automatically at connection Christopher Kings-Lynne
• 03:10   Re: is it possible to make this faster? Jeff -
• 03:29   Re: is it possible to make this faster? Tom Lane
• 04:47   Re: is it possible to make this faster? Merlin Moncure
• 10:26   column totals James Neethling
• 13:20   Re: column totals James Neethling
• 14:22   Re: is it possible to make this faster? Tom Lane
• 16:23   Re: column totals Ragnar
• 16:57   Re: is it possible to make this faster? Merlin Moncure
• 17:07   Re: is it possible to make this faster? Tom Lane
• 17:47   Re: is it possible to make this faster? Merlin Moncure
• 17:55   Re: is it possible to make this faster? Tom Lane
• 19:40   Re: is it possible to make this faster? Merlin Moncure
• 20:45   Re: is it possible to make this faster? Tom Lane

27 May 2006

• 21:02   Re: Speed Up Offset and Limit Clause PFC

28 May 2006

• 01:12   Re: is it possible to make this faster? Mark Kirkwood
• 09:38   App very unresponsive while performing simple update Brendan Duddridge
• 09:43   Re: App very unresponsive while performing simple update Brendan Duddridge
• 13:11   Re: App very unresponsive while performing simple update Greg Stark
• 14:16   Re: How can I make this query faster (resend) Cstdenis
• 16:05   Re: App very unresponsive while performing simple update Tom Lane
• 17:56   Re: App very unresponsive while performing simple update Greg Stark
• 19:17   Re: App very unresponsive while performing simple update Brendan Duddridge
• 21:32   Re: App very unresponsive while performing simple update Tom Lane
• 23:21   Re: App very unresponsive while performing simple update Greg Stark
• 23:24   Re: App very unresponsive while performing simple update Greg Stark

29 May 2006

• 09:53   select with "like" from another table Anton Maksimenkov
• 10:36   Re: select with "like" from another table chris smith
• 11:11   Re: Getting even more insert performance (250m+rows/day) Markus Schaber
• 14:33   Re: How can I make this query faster (resend) Cstdenis
• 14:35   Re: How can I make this query faster (resend) Cstdenis
• 15:40   Re: select with "like" from another table Anton Maksimenkov

30 May 2006

• 03:22   Re: Adding and filling new column on big table Francisco Reyes
• 03:52   Re: Selects query stats? Francisco Reyes
• 08:36   Re: Adding and filling new column on big table Jonathan Blitz
• 10:33   Re: Selects query stats? Alvis Tunkelis
• 14:18   Speedup hint needed, if available? :) Mario Splivalo
• 14:31   pg_dump issue mcelroy, tim
• 15:06   Re: Speedup hint needed, if available? :) Tom Lane
• 15:16   Re: pg_dump issue Tom Lane
• 15:17   Re: Speedup hint needed, if available? :) Mario Splivalo
• 15:34   Re: pg_dump issue mcelroy, tim
• 15:58   Re: Adding and filling new column on big table Francisco Reyes
• 16:11   Re: Adding and filling new column on big table Jonathan Blitz
• 16:20   Re: pg_dump issue Tom Lane
• 17:12   Re: pg_dump issue mcelroy, tim
• 17:25   Re: Adding and filling new column on big table Francisco Reyes
• 19:59   Re: Getting even more insert performance (250m+rows/day) Daniel J. Luke
• 20:04   Re: Adding and filling new column on big table Jonathan Blitz
• 20:07   Re: Adding and filling new column on big table Scott Marlowe
• 20:24   Re: Adding and filling new column on big table PFC
• 20:52   Re: Adding and filling new column on big table Francisco Reyes
• 20:56   Re: Query performance Antonio Batovanja
• 20:56   compiling source code!!!!!!!!!!!!!!!!!!!!!!!!!!!!! sibel karaasma
• 20:56   Optimizing a huge_table/tiny_table join 
• 20:56   Optimizing a huge_table/tiny_table join 
• 20:56   Re: Optimizing a huge_table/tiny_table join Kynn Jones
• 20:56   Why the 8.1 plan is worst than 7.4? wmiro@ig.com.br
• 20:56   Bulk loading/merging Worky Workerson
• 20:56   Re: Bulk loading/merging Worky Workerson
• 20:57   Re: Query performance Erwin Brandstetter
• 20:57   Re: Query performance Erwin Brandstetter
• 20:57   Split select completes, single select doesn't and becomes IO bound! Anthony Ransley
• 20:57   INSERT OU UPDATE WITHOUT SELECT? Waldomiro
• 21:05   Re: INSERT OU UPDATE WITHOUT SELECT? Jonah H. Harris
• 21:52   Re: Split select completes, single select doesn't and Ragnar
• 22:03   Re: Getting even more insert performance (250m+rows/day) Daniel J. Luke
• 22:35   Re: INSERT OU UPDATE WITHOUT SELECT? PFC
• 22:37   Re: Optimizing a huge_table/tiny_table join PFC
• 22:38   Re: INSERT OU UPDATE WITHOUT SELECT? Alvaro Herrera
• 22:54   Re: INSERT OU UPDATE WITHOUT SELECT? Dave Dutcher
• 23:05   Re: INSERT OU UPDATE WITHOUT SELECT? D'Arcy J.M. Cain

31 May 2006

• 00:38   Re: Why the 8.1 plan is worst than 7.4? Jim C. Nasby
• 01:09   Re: Bulk loading/merging Jim C. Nasby
• 01:36   Re: Query performance Christopher Kings-Lynne
• 03:20   Re: Why the 8.1 plan is worst than 7.4? Tom Lane
• 06:23   Re: App very unresponsive while performing simple update Jim C. Nasby
• 06:29   Re: INSERT OU UPDATE WITHOUT SELECT? Jim C. Nasby
• 06:30   Re: App very unresponsive while performing simple update Brendan Duddridge
• 09:30   Re: Speedup hint needed, if available? :) Nis Jorgensen
• 12:34   Re: App very unresponsive while performing simple update Jan de Visser
• 15:09   Re: App very unresponsive while performing simple update Bruno Wolff III
• 15:24   Re: App very unresponsive while performing simple update Greg Stark
• 17:35   Re: App very unresponsive while performing simple update Brendan Duddridge
• 17:43   Re: App very unresponsive while performing simple update Jan de Visser