Mailing lists [pgsql-performance]

1 July 2004

• 01:50   Re: How can one see what queries are running withing a Roger Ging
• 02:51   Re: Query performance Mischa Sandberg
• 02:52   Re: How can one see what queries are running withing a P.A.M. van Dam
• 04:35   planner and worst case scenario Joseph Shraibman
• 16:51   network address query Litao Wu
• 19:20   Query gets slow when where clause increases James Antill
• 21:45   Re: Query gets slow when where clause increases Dennis Bjorklund

2 July 2004

• 07:47   Mysterious performance of query because of plsql function in where condition Peter Alberer
• 11:52   Re: Mysterious performance of query because of plsql function in where condition Jeff
• 13:00   Re: Mysterious performance of query because of plsql function in where condition Bruno Wolff III
• 13:06   Re: BUG #1186: Broken Index? Bruno Wolff III

5 July 2004

• 10:11   Seq scan vs. Index scan with different query conditions eleven@ludojad.itpp.pl
• 11:41   Re: Seq scan vs. Index scan with different query conditions Richard Huxton
• 11:44   Re: Seq scan vs. Index scan with different query Andrew McMillan
• 13:42   Re: Seq scan vs. Index scan with different query conditions eleven@ludojad.itpp.pl
• 19:24   Re: Seq scan vs. Index scan with different query Andrew McMillan

6 July 2004

• 15:00   to fsync or not to fsync Rodrigo Filgueira
• 15:45   Re: to fsync or not to fsync Frank Hsueh
• 16:50   Re: to fsync or not to fsync (ext3?) Rodrigo Filgueira
• 17:54   Keyword searching question borajetta
• 17:57   Re: Keyword searching question borajetta

7 July 2004

• 15:13   Implementatiion of Inheritance in Postgres Ioannis Theoharis
• 16:17   Terrible performance after deleting/recreating indexes Bill Chandler
• 17:24   inserting into brand new database faster than old database Missner, T. R.
• 19:04   Forcing HashAggregation prior to index scan? Eugene
• 19:15   finding a max value Edoardo Ceccarelli
• 19:19   Odd sorting behaviour Steinar H. Gunderson
• 19:20   Re: Mysterious performance of query because of plsql function in CoL
• 19:25   Re: inserting into brand new database faster than old database Matthew T. O'Connor
• 19:28   Re: inserting into brand new database faster than old database Missner, T. R.
• 20:34   Re: finding a max value Rosser Schwarz
• 21:27   query plan wierdness? Joel McGraw
• 22:12   Re: query plan wierdness? Joel McGraw
• 22:50   Re: query plan wierdness? Stephan Szabo

8 July 2004

• 09:02   Re: inserting into brand new database faster than old database Shridhar Daithankar
• 09:07   Re: Terrible performance after deleting/recreating indexes Shridhar Daithankar
• 10:19   Odd sorting behaviour Steinar H. Gunderson
• 16:13   Re: finding a max value James Antill
• 16:16   Re: query plan wierdness? Guido Barosio
• 16:51   Re: query plan wierdness? Rod Taylor
• 18:03   vacuum_mem Litao Wu
• 18:26   Re: vacuum_mem Rod Taylor
• 20:49   Re: Terrible performance after deleting/recreating indexes Bill Chandler

9 July 2004

• 00:13   Re: Terrible performance after deleting/recreating indexes Mark Kirkwood
• 00:31   Working on huge RAM based datasets Andy Ballingall
• 01:35   Re: Working on huge RAM based datasets Christopher Kings-Lynne
• 14:16   Re: Working on huge RAM based datasets Merlin Moncure
• 15:18   Re: Terrible performance after deleting/recreating indexes Bill Chandler
• 18:15   Re: query plan wierdness? Joel McGraw
• 19:18   Re: query plan wierdness? Rod Taylor
• 20:24   Cursors performance (was: Re: Terrible performance after deleting/recreating indexes) Bill Chandler
• 20:38   Re: [JDBC] Cursors performance (was: Re: Terrible Dave Cramer
• 20:44   Re: [JDBC] Cursors performance (was: Re: Terrible performance Kris Jurka
• 21:17   Re: Working on huge RAM based datasets Andy Ballingall
• 21:17   Re: Working on huge RAM based datasets Andy Ballingall
• 22:22   Re: [JDBC] Cursors performance Oliver Jowett

10 July 2004

• 02:52   Re: inserting into brand new database faster than old database Tom Lane
• 03:04   Re: Cursors performance Mark Kirkwood
• 03:10   Re: Forcing HashAggregation prior to index scan? Tom Lane
• 10:00   Re: achat borne wifi Laurent Martelli
• 13:59   Re: Working on huge RAM based datasets Christopher Browne

11 July 2004

• 14:14   Re: Working on huge RAM based datasets Jan Wieck
• 17:59   Re: Working on huge RAM based datasets Christopher Browne

12 July 2004

• 14:05   Re: Working on huge RAM based datasets Merlin Moncure
• 14:22   Re: Working on huge RAM based datasets Merlin Moncure
• 14:38   Re: Working on huge RAM based datasets Rod Taylor
• 16:39   Re: Working on huge RAM based datasets Josh Berkus
• 18:02   Re: Working on huge RAM based datasets Jan Wieck
• 18:34   Re: Fw: invitation au "Village du Logiciel Libre" de la Laurent Martelli
• 23:54   Re: query plan wierdness? Joel McGraw

13 July 2004

• 02:11   Re: query plan wierdness? Rod Taylor
• 05:54   How to create an index for type timestamp column using rtree? Chris Cheston
• 06:25   Re: How to create an index for type timestamp column using rtree? Tom Lane
• 06:31   Re: How to create an index for type timestamp column using Christopher Kings-Lynne
• 07:56   Re: How to create an index for type timestamp column using rtree? Chris Cheston
• 16:51   Insert are going slower ... Hervé Piedvache
• 17:10   Re: Insert are going slower ... Josh Berkus
• 19:29   Re: Working on huge RAM based datasets Andy Ballingall
• 19:29   Re: Inverted-list databases (was: Working on huge RAM based datasets) Mischa Sandberg
• 19:29   Swapping in 7.4.3 Jim Ewert
• 20:28   Re: Swapping in 7.4.3 Matthew T. O'Connor
• 23:42   Re: Insert are going slower ... Hervé Piedvache

14 July 2004

• 10:04   Re: Insert are going slower ... gnari
• 10:13   Re: Insert are going slower ... Shridhar Daithankar
• 14:08   Re: Insert are going slower ... Hervé Piedvache
• 14:32   Re: Insert are going slower ... Shridhar Daithankar
• 16:41   Re: Insert are going slower ... Josh Berkus
• 21:19   Re: Insert are going slower ... Hervé Piedvache
• 21:32   Re: Insert are going slower ... Hervé Piedvache
• 21:41   vacuum full 100 mins plus? Patrick Hatcher
• 22:48   Re: vacuum full 100 mins plus? Patrick Hatcher
• 23:11   Re: Odd sorting behaviour Steinar H. Gunderson

15 July 2004

• 00:13   Re: vacuum full 100 mins plus? Josh Berkus
• 01:40   Re: Odd sorting behaviour Josh Berkus
• 03:02   Re: vacuum full 100 mins plus? Christopher Browne
• 04:37   Re: vacuum full 100 mins plus? Tom Lane
• 04:53   Re: Odd sorting behaviour Tom Lane
• 06:22   Re: Insert are going slower ... Shridhar Daithankar
• 12:08   Re: Odd sorting behaviour Steinar H. Gunderson
• 13:49   Re: Swapping in 7.4.3 Jim Ewert
• 15:30   Re: vacuum full 100 mins plus? Mike Rylander
• 16:19   Re: Swapping in 7.4.3 Scott Marlowe
• 18:07   hardware raid suggestions Brian Hirt
• 18:09   Re: Insert are going slower ... Josh Berkus
• 18:11   Re: Odd sorting behaviour Josh Berkus
• 22:16   Re: Odd sorting behaviour Steinar H. Gunderson

16 July 2004

• 02:55   Re: hardware raid suggestions Josh Berkus
• 03:25   Re: hardware raid suggestions Mark Aufflick
• 07:36   Re: Swapping in 7.4.3 Matt Clark
• 11:17   Re: Insert are going slower ... Hervé Piedvache
• 18:37   Wierd issues Andrew Matthews
• 18:37   extrem bad performance Stefan
• 21:36   same plan, different time Litao Wu

17 July 2004

• 02:31   Re: extrem bad performance Rod Taylor
• 03:20   Re: hardware raid suggestions Fred Moyer
• 03:31   Scaling with lazy index updates Fred Moyer
• 04:53   Re: same plan, different time Tom Lane

18 July 2004

• 00:02   Re: Scaling with lazy index updates Josh Berkus
• 09:42   Re: High load average with PostgreSQL 7.4.2 on debian/ibm eserver. Gaetano Mendola
• 17:24   Re: Insert are going slower ... Josh Berkus

20 July 2004

• 07:50   NAS, SAN or any alternate solution ? bsimon@loxane.com
• 08:20   Re: NAS, SAN or any alternate solution ? Scott Marlowe
• 09:29   Réf. : Re: NAS, SAN or any alternatesolution ? bsimon@loxane.com
• 10:02   Re: Réf. : Re: [PERFORM] NAS, Mark Kirkwood
• 10:15   Réf. : Re: Réf. : Re: NAS, SANor any alternate solution ? bsimon@loxane.com
• 10:45   Re: Working on huge RAM based datasets abhousehunt
• 11:51   Re: Odd sorting behaviour Steinar H. Gunderson
• 12:26   Re: NAS, SAN or any alternate solution ? Grega Bremec
• 13:04   Re: NAS, SAN or any alternate solution ? Grega Bremec
• 15:27   Re: Réf. : Re: NAS, SAN or any Scott Marlowe
• 16:45   Re: NAS, SAN or any alternate solution ? Joe Conway
• 17:03   Re: Odd sorting behaviour Josh Berkus
• 17:07   Re: Odd sorting behaviour Josh Berkus
• 17:21   Re: Odd sorting behaviour Steinar H. Gunderson
• 17:30   Re: NAS, SAN or any alternate solution ? Rod Taylor
• 19:19   Unbearably slow cascading deletes andrew@pillette.com
• 19:45   Re: Unbearably slow cascading deletes Stephan Szabo
• 19:55   Re: Unbearably slow cascading deletes Stephan Szabo
• 19:59   Re: Unbearably slow cascading deletes andrew@pillette.com
• 20:07   Re: Unbearably slow cascading deletes andrew@pillette.com

21 July 2004

• 01:36   Re: Unbearably slow cascading deletes Christopher Kings-Lynne
• 02:22   Re: Odd sorting behaviour Rod Taylor
• 10:04   Re: Odd sorting behaviour Steinar H. Gunderson
• 14:58   Re: Odd sorting behaviour Rod Taylor
• 16:46   Re: extrem bad performance Stefan
• 20:46   Beowulf Cluster & Postgresql? joe
• 21:07   Re: Beowulf Cluster & Postgresql? Scott Marlowe

22 July 2004

• 02:48   Re: Beowulf Cluster & Postgresql? Mark Kirkwood

23 July 2004

• 05:53   Performance over a LAN William Carney
• 06:00   Re: Performance over a LAN Christopher Kings-Lynne
• 06:20   Re: Performance over a LAN Mark Aufflick
• 06:28   Re: Performance over a LAN Scott Marlowe
• 08:00   Re: Performance over a LAN William Carney
• 11:43   Re: Performance over a LAN Rod Taylor
• 12:05   Re: Performance over a LAN Jeff
• 15:34   Re: Performance over a LAN Michael Adler
• 16:26   Re: Performance over a LAN Gary Cowell
• 17:10   Re: Performance over a LAN Greg Stark
• 17:42   Re: [HACKERS] Wrong index choosen? Gaetano Mendola
• 18:12   Re: [HACKERS] Wrong index choosen? Matthew T. O'Connor
• 21:51   Re: [HACKERS] Wrong index choosen? Jaime Casanova
• 22:01   Re: [HACKERS] Wrong index choosen? Scott Marlowe

24 July 2004

• 00:08   Re: [HACKERS] Wrong index choosen? Gaetano Mendola
• 01:49   Re: [HACKERS] Wrong index choosen? Matthew T. O'Connor

25 July 2004

• 23:09   Index type Ilia Kantor
• 23:09   Re: Working on huge RAM based datasets Andy Ballingall
• 23:09   variable length - user defined types/storage place martin.bokler@web.de

26 July 2004

• 04:57   arrays and indexes Ross J. Reedstrom
• 06:27   Re: arrays and indexes Greg Stark
• 14:16   Re: Insert are going slower ... Gaetano Mendola
• 14:16   Re: hardware raid suggestions Gaetano Mendola
• 14:47   Re: Insert are going slower ... Gaetano Mendola
• 14:52   Timestamp-based indexing Harmon S. Nine
• 14:56   Re: arrays and indexes Merlin Moncure
• 15:05   Re: Timestamp-based indexing Kevin Barnard
• 15:10   Re: Timestamp-based indexing Matthew T. O'Connor
• 15:43   Re: Timestamp-based indexing Harmon S. Nine
• 15:46   Re: Timestamp-based indexing Harmon S. Nine
• 15:59   Re: Timestamp-based indexing Tom Lane
• 16:02   Re: Timestamp-based indexing Stephan Szabo
• 16:24   Re: Insert are going slower ... Scott Marlowe
• 18:37   Re: Timestamp-based indexing Harmon S. Nine
• 18:57   Re: arrays and indexes Ross J. Reedstrom
• 20:35   Re: arrays and indexes Pierre-Frédéric Caillaud
• 20:40   Re: arrays and indexes Greg Stark
• 21:21   Re: arrays and indexes Tom Lane
• 21:27   Re: Timestamp-based indexing Litao Wu
• 21:40   Re: Timestamp-based indexing Tom Lane

27 July 2004

• 01:52   Re: Timestamp-based indexing Christopher Kings-Lynne
• 04:33   Re: arrays and indexes Greg Stark
• 07:35   Little understanding for tuning ... Hervé Piedvache
• 13:07   best way to fetch next/prev record based on index Merlin Moncure
• 13:15   Automagic tuning Markus Schaber

28 July 2004

• 03:22   Re: best way to fetch next/prev record based on index Tom Lane
• 03:26   Re: best way to fetch next/prev record based on index Merlin Moncure
• 03:30   best way to fetch next/prev record based on index Merlin Moncure
• 03:30   Re: best way to fetch next/prev record based on index Greg Stark
• 03:30   Re: best way to fetch next/prev record based on index Tom Lane
• 03:31   Re: best way to fetch next/prev record based on index Markus Schaber
• 03:34   Re: best way to fetch next/prev record based on index Rod Taylor
• 03:35   Re: best way to fetch next/prev record based on index Merlin Moncure
• 03:35   Re: Automagic tuning Christopher Kings-Lynne
• 03:35   Re: best way to fetch next/prev record based on index Tom Lane
• 03:36   Correction of best way to fetch next/prev record based on index Markus Schaber
• 03:36   Re: best way to fetch next/prev record based on index andrew@pillette.com
• 03:43   Re: best way to fetch next/prev record based on index Markus Schaber
• 03:46   Re: best way to fetch next/prev record based on index Merlin Moncure
• 03:47   Re: best way to fetch next/prev record based on index Tom Lane
• 03:48   Re: best way to fetch next/prev record based on index Merlin Moncure
• 03:50   Re: best way to fetch next/prev record based on index Greg Stark
• 03:51   Re: best way to fetch next/prev record based on index Merlin Moncure
• 03:52   Re: best way to fetch next/prev record based on index Merlin Moncure
• 04:01   Re: best way to fetch next/prev record based on index Stephan Szabo
• 05:53   Re: best way to fetch next/prev record based on index Greg Stark
• 07:15   Re: best way to fetch next/prev record based on index Greg Stark
• 12:48   Re: best way to fetch next/prev record based on index Merlin Moncure
• 14:07   Re: best way to fetch next/prev record based on index Tom Lane
• 15:38   Re: best way to fetch next/prev record based on index Merlin Moncure
• 16:01   Re: best way to fetch next/prev record based on index Greg Stark
• 16:54   Join performance Pierre-Frédéric Caillaud
• 16:56   Re: best way to fetch next/prev record based on index Tom Lane
• 22:54   Re: best way to fetch next/prev record based on index Greg Stark
• 23:12   Re: best way to fetch next/prev record based on index Tom Lane

29 July 2004

• 15:32   Optimizer refuses to hash join Stan Bielski
• 15:48   my boss want to migrate to ORACLE Stephane Tessier
• 15:55   Extremely slow query... pathat@comcast.net
• 16:14   Re: Optimizer refuses to hash join Stephan Szabo
• 16:49   Re: best way to fetch next/prev record based on index Merlin Moncure
• 17:07   Re: Optimizer refuses to hash join Tom Lane
• 17:58   Re: best way to fetch next/prev record based on index Greg Stark
• 18:23   Re: best way to fetch next/prev record based on index Merlin Moncure
• 18:41   Re: best way to fetch next/prev record based on index Tom Lane
• 18:49   Re: best way to fetch next/prev record based on index Greg Stark
• 20:12   Re: best way to fetch next/prev record based on index Merlin Moncure
• 21:05   Index works with foo.val=bar.val but not foo.val<=bar.val 8lhhxba02@sneakemail.com

30 July 2004

• 01:22   Re: my boss want to migrate to ORACLE Russell Smith
• 02:34   Re: my boss want to migrate to ORACLE markir@coretech.co.nz
• 03:00   Re: my boss want to migrate to ORACLE markir@coretech.co.nz
• 12:33   Re: my boss want to migrate to ORACLE Jeff
• 13:56   Re: my boss want to migrate to ORACLE Stephane Tessier
• 14:14   Re: my boss want to migrate to ORACLE Merlin Moncure
• 15:13   Re: my boss want to migrate to ORACLE Scott Marlowe
• 16:49   Re: Optimizer refuses to hash join Tom Lane
• 17:56   Re: my boss want to migrate to ORACLE Matthew T. O'Connor
• 18:12   Re: my boss want to migrate to ORACLE Dan Langille
• 18:29   Re: my boss want to migrate to ORACLE Brian Hirt

31 July 2004

• 02:17   Re: my boss want to migrate to ORACLE Christopher Browne
• 04:17   Re: my boss want to migrate to ORACLE Scott Marlowe