Mailing lists [pgsql-performance]

1 November 2006

• 00:29   Re: Help w/speeding up range queries? Tom Lane
• 01:27   Re: Help w/speeding up range queries? Luke Lonergan
• 01:43   Re: pg_trgm indexes giving bad estimations? Ben
• 01:59   Re: Help w/speeding up range queries? Tom Lane
• 02:04   Re: pg_trgm indexes giving bad estimations? Tom Lane
• 02:51   big transaction slows down over time - but disk seems almost unused Ben
• 05:42   Re: big transaction slows down over time - but disk seems Heikki Linnakangas
• 14:22   Re: big transaction slows down over time - but disk seems almost unused Ben
• 14:54   Re: big transaction slows down over time - but disk Andreas Kostyrka
• 15:02   Re: MVCC & indexes? Ivan Voras
• 15:05   Re: big transaction slows down over time - but disk seems Richard Huxton
• 15:27   Re: big transaction slows down over time - but disk seems almost unused Ben
• 15:30   Re: big transaction slows down over time - but disk seems Ben
• 15:34   Re: big transaction slows down over time - but disk seems Richard Huxton
• 16:45   Database-wide vacuum can take a long time, during which tables are not being analyzed Steven Flatt
• 18:58   Re: Database-wide vacuum can take a long time, during which Matthew O'Connor

2 November 2006

• 06:49   Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed Simon Riggs
• 06:53   Re: Help w/speeding up range queries? Marcin Mank
• 07:00   Re: Help w/speeding up range queries? Simon Riggs
• 07:07   Query plan for "heavy" SELECT with "lite" sub-SELECTs Nikolay Samokhvalov
• 08:38   Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Richard Huxton
• 08:46   Locking vs. Exceptions Robins
• 10:25   Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Dave Dutcher
• 11:15   Setting "nice" values Madison Kelly
• 11:15   Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed Steven Flatt
• 11:20   Re: Setting "nice" values Scott Marlowe
• 11:25   Re: Setting "nice" values Madison Kelly
• 11:41   Re: Setting "nice" values Scott Marlowe
• 11:54   Re: Database-wide vacuum can take a long time, duringwhich tables are not being analyzed Alvaro Herrera
• 12:01   Re: Setting "nice" values Tobias Brox
• 15:16   Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Alvaro Herrera
• 18:11   Re: VACUUMs take twice as long across all nodes Vivek Khera
• 19:51   Re: Locking vs. Exceptions Benjamin Minshall

3 November 2006

• 05:46   Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Arjen van der Meijden
• 07:12   profiling PL/pgSQL? Drew Wilson
• 07:21   Re: profiling PL/pgSQL? A. Kretschmer
• 08:06   Re: profiling PL/pgSQL? Richard Huxton
• 08:34   Context switch storm creimer@brturbo.com.br
• 08:49   Re: Context switch storm Gregory S. Williamson
• 08:55   Re: Context switch storm Richard Huxton
• 09:28   Re: Context switch storm Richard Huxton
• 09:33   Re: Setting "nice" values Andreas Kostyrka
• 09:51   Re: Context switch storm Andreas Kostyrka
• 10:03   Re: Context switch storm Richard Troy
• 10:04   Re: Context switch storm Richard Huxton
• 10:08   Re: Context switch storm Cosimo Streppone
• 10:32   Re: Context switch storm creimer@brturbo.com.br
• 10:36   Re: Context switch storm Richard Huxton
• 10:51   Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Tom Lane
• 11:27   Re: profiling PL/pgSQL? Jonah H. Harris
• 11:27   Re: Context switch storm Tom Lane
• 12:14   Re: Context switch storm Andreas Kostyrka
• 15:25   EXISTS optimization Kevin Grittner

5 November 2006

• 16:34   Re: Slow functional indexes? Stuart Bishop
• 21:23   Re: Slow functional indexes? Tom Lane
• 21:34   Re: Slow functional indexes? Gene

6 November 2006

• 00:28   Re: Setting "nice" values Jim Nasby
• 09:11   Re: Setting "nice" values Madison Kelly
• 09:13   Re: Setting "nice" values Madison Kelly
• 09:15   Re: Setting "nice" values Madison Kelly
• 09:34   Re: Setting "nice" values Tobias Brox
• 09:49   Re: Setting "nice" values Madison Kelly
• 10:09   Yet another question on LIMIT performance :/ Hannes Dorbath
• 10:11   Re: Setting "nice" values Tobias Brox
• 10:14   Re: Yet another question on LIMIT performance :/ Heikki Linnakangas
• 10:18   Re: Yet another question on LIMIT performance :/ Hannes Dorbath
• 10:19   Re: Setting "nice" values Madison Kelly
• 10:33   Re: Yet another question on LIMIT performance :/ Tom Lane
• 14:51   Context switching Carlos H. Reimer
• 14:52   Re: profiling PL/pgSQL? 
• 15:29   RES: Context switching Carlos H. Reimer
• 16:47   Easy read-heavy benchmark kicking around? Brian Hurt
• 16:58   Re: Easy read-heavy benchmark kicking around? Luke Lonergan
• 17:10   Re: Easy read-heavy benchmark kicking around? Merlin Moncure
• 17:26   Re: Easy read-heavy benchmark kicking around? Scott Marlowe
• 17:41   Re: Context switch storm Cosimo Streppone
• 21:37   Re: Help w/speeding up range queries? Jim Nasby
• 21:55   Re: Easy read-heavy benchmark kicking around? Mark Kirkwood

7 November 2006

• 06:48   Re: Easy read-heavy benchmark kicking around? Dimitri Fontaine
• 13:42   Re: Context switching Josh Berkus

8 November 2006

• 12:18   Re: Easy read-heavy benchmark kicking around? Markus Schaber
• 12:34   Re: Easy read-heavy benchmark kicking around? Merlin Moncure
• 12:57   Re: Easy read-heavy benchmark kicking around? Cosimo Streppone
• 13:14   Re: Which OS provides the _fastest_ PostgreSQL performance? Ron Mayer
• 15:33   Re: Easy read-heavy benchmark kicking around? Luke Lonergan

9 November 2006

• 08:47   Keeping processes open for re-use Hilary Forbes
• 08:56   Re: Keeping processes open for re-use Csaba Nagy
• 13:29   Re: Easy read-heavy benchmark kicking around? Merlin Moncure
• 13:55   Re: Keeping processes open for re-use imad
• 22:12   Re: Keeping processes open for re-use Shane Ambler
• 22:18   Re: Keeping processes open for re-use Joshua D. Drake

10 November 2006

• 01:15   10x rowcount mis-estimation favouring merge over nestloop Abhijit Menon-Sen
• 02:50   Re: 10x rowcount mis-estimation favouring merge over nestloop Tom Lane
• 03:25   Re: 10x rowcount mis-estimation favouring merge over nestloop Abhijit Menon-Sen
• 14:54   Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?] Ron Mayer
• 19:55   Re: [BUGS] BUG #2737: hash indexing large table fails, while btree of same index works Tom Lane

11 November 2006

• 04:18   Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works Simon Riggs

13 November 2006

• 05:01   Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?] Guy Thornley

14 November 2006

• 05:52   Re: Context switch storm Cosimo Streppone
• 06:11   Re: Context switch storm Andreas Kostyrka
• 10:17   Re: Context switch storm Merlin Moncure
• 12:50   Re: Context switch storm Jim C. Nasby
• 13:53   Re: Context switch storm Bucky Jordan
• 16:11   Re: Context switch storm Merlin Moncure
• 17:43   Re: Context switch storm Cosimo Streppone

15 November 2006

• 05:08   Re: Context switch storm Simon Riggs
• 07:44   Slow SELECT on three or more clients AMIR FRANCO D. JOVEN
• 09:26   Re: Slow SELECT on three or more clients Andreas Kostyrka
• 09:32   Re: Slow SELECT on three or more clients Russell Smith
• 09:59   Re: Slow SELECT on three or more clients Gregory S. Williamson
• 10:17   Re: Slow SELECT on three or more clients Merlin Moncure
• 10:47   Re: Slow SELECT on three or more clients Markus Schaber
• 12:38   Hundreds of database and FSM Craig A. James
• 13:32   Re: Hundreds of database and FSM Alvaro Herrera
• 13:43   Re: Hundreds of database and FSM Steinar H. Gunderson
• 22:23   Postgres server crash Craig A. James
• 22:28   Re: Postgres server crash Russell Smith

16 November 2006

• 04:54   Re: Slow SELECT on three or more clients AMIR FRANCO D. JOVEN
• 06:46   Re: Postgres server crash Richard Huxton
• 13:02   Re: Postgres server crash Craig A. James
• 13:08   Re: Postgres server crash Richard Huxton
• 13:17   Re: Postgres server crash Craig A. James
• 13:27   Re: Postgres server crash Richard Huxton
• 13:39   Re: Keeping processes open for re-use Jean-Max Reymond
• 14:10   Re: Postgres server crash Tom Lane
• 14:14   Re: Postgres server crash Tom Lane
• 14:19   Re: Postgres server crash Richard Huxton
• 14:26   Re: Postgres server crash Merlin Moncure
• 16:51   Re: Postgres server crash Ben
• 17:01   Re: Context switch storm Jim Nasby
• 18:48   Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works Tom Lane

17 November 2006

• 06:59   Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works Simon Riggs
• 07:18   Re: Keeping processes open for re-use Richard Huxton
• 10:38   Re: [BUGS] BUG #2737: hash indexing largetablefails,while btree of same index works Simon Riggs
• 11:08   Re: [BUGS] BUG #2737: hash indexing large tablefails,while btree of same index works Tom Lane
• 11:36   Re: [BUGS] BUG #2737: hash indexing large tablefails,while Julius.Stroffek
• 13:45   availability of SATA vendors Jeff Frost
• 14:45   Re: Optimicing Postgres for SunSolaris10 on V240 Josh Berkus
• 14:48   shared_buffers > 284263 on OS X Brian Wipf
• 15:20   Re: availability of SATA vendors Arjen van der Meijden
• 16:00   Re: availability of SATA vendors Ron
• 16:44   Re: availability of SATA vendors Steve Atkins
• 17:54   Re: availability of SATA vendors Luke Lonergan

18 November 2006

• 05:33   start up cost estimate rakesh kumar
• 06:09   Re: Optimicing Postgres for SunSolaris10 on V240 Marc Cousin
• 10:27   Re: start up cost estimate Joshua Marsh
• 12:17   Re: shared_buffers > 284263 on OS X Dave Cramer
• 14:11   Re: start up cost estimate Tom Lane
• 14:30   Re: shared_buffers > 284263 on OS X Tom Lane
• 14:48   Re: shared_buffers > 284263 on OS X lists@event-s.net (Guido Neitzer)
• 14:48   Re: shared_buffers > 284263 on OS X Guido Neitzer
• 21:18   Re: Postgres server crash Richard Troy
• 23:13   Re: shared_buffers > 284263 on OS X Brian Wipf

19 November 2006

• 00:05   Fwd: start up cost estimate rakesh kumar
• 02:45   Re: Postgres server crash Craig A. James
• 02:51   Re: Postgres server crash Tom Lane
• 11:21   Re: shared_buffers > 284263 on OS X Guido Neitzer
• 13:01   Re: Postgres server crash Ron Mayer
• 13:07   Re: Postgres server crash Ron Mayer
• 15:41   Re: Postgres server crash Michael Stone
• 16:42   Re: Postgres server crash Richard Broersma Jr
• 17:25   Re: Postgres server crash Michael Stone
• 18:13   Re: Postgres server crash Craig A. James
• 18:22   PostgreSQL with 64 bit was: Re: shared_buffers > 284263 on OS X Guido Neitzer
• 18:32   Re: Postgres server crash Michael Stone
• 21:02   Re: Postgres server crash Craig A. James
• 21:59   Re: Postgres server crash Bruno Wolff III

20 November 2006

• 02:43   Re: Postgres server crash Craig A. James
• 18:58   Re: Postgres server crash Mattias Kregert

21 November 2006

• 10:08   Re: Postgres server crash Markus Schaber
• 10:45   BitMapScan performance degradation Jérôme BENOIS
• 10:48   RES: Context switching Carlos H. Reimer
• 11:44   Re: BitMapScan performance degradation Tom Lane
• 11:51   Re: BitMapScan performance degradation db@zigo.dhs.org
• 13:01   Re: BitMapScan performance degradation Jérôme BENOIS
• 13:39   Slow Query Joe Lester
• 16:28   Re: Slow Query Joe Lester
• 21:54   Re: availability of SATA vendors Jeff Frost
• 22:11   Priority to a mission critical transaction Carlos H. Reimer
• 22:13   Re: availability of SATA vendors Joshua D. Drake
• 22:15   Re: availability of SATA vendors Jeff Frost
• 22:37   Re: availability of SATA vendors Joshua D. Drake

22 November 2006

• 09:51   PostgreSQL underestimates sorting Markus Schaber
• 09:58   Re: PostgreSQL underestimates sorting Steinar H. Gunderson
• 10:18   Re: availability of SATA vendors Bucky Jordan
• 10:28   Re: PostgreSQL underestimates sorting Markus Schaber
• 12:36   Re: availability of SATA vendors Jeff Frost
• 12:59   Re: PostgreSQL underestimates sorting Markus Schaber
• 13:00   Re: availability of SATA vendors Joshua D. Drake
• 13:02   Re: availability of SATA vendors Jeff Frost
• 13:07   Re: availability of SATA vendors Arjen van der Meijden
• 13:10   Re: availability of SATA vendors Joshua D. Drake
• 13:11   Re: PostgreSQL underestimates sorting Frank Wiles
• 13:34   Re: availability of SATA vendors Scott Marlowe
• 18:38   Re: availability of SATA vendors Bucky Jordan
• 19:03   Re: availability of SATA vendors Luke Lonergan

23 November 2006

• 02:40   Direct I/O issues Greg Smith
• 03:31   Re: Lying drives [Was: Re: Which OS provides the _fastest_ Greg Smith
• 04:40   Re: availability of SATA vendors Arjen van der Meijden
• 11:20   Re: PostgreSQL underestimates sorting Simon Riggs
• 12:44   Re: Lying drives [Was: Re: Which OS provides the Bruce Momjian
• 12:46   Re: Direct I/O issues Tom Lane
• 14:10   Re: Direct I/O issues Greg Smith
• 16:40   Re: Priority to a mission critical transaction Brad Nicholson
• 18:38   Postgres scalability and performance on windows Gopal
• 18:51   Re: Postgres scalability and performance on windows Heikki Linnakangas

24 November 2006

• 00:06   Re: Direct I/O issues Bruce Momjian
• 04:27   Re: Postgres scalability and performance on windows Guido Neitzer
• 06:14   Re: Postgres scalability and performance on windows Gopal
• 10:08   TPC-H Benchmark Felipe Rondon Rocha
• 12:31   Re: TPC-H Benchmark Luke Lonergan
• 13:50   Re: Postgres scalability and performance on windows Frank Wiles
• 15:26   Massive delete of rows, how to proceed? Arnau
• 20:10   Re: Postgres scalability and performance on windows Tom Lane

25 November 2006

• 11:45   Massive delete of rows, how to proceed? Peter Childs
• 21:26   Re: Massive delete of rows, how to proceed? andrew@pillette.com

26 November 2006

• 07:24   When to vacuum a table? Joost Kraaijeveld
• 08:43   Re: When to vacuum a table? Marcelo Costa
• 09:30   Re: When to vacuum a table? Steinar H. Gunderson
• 09:46   Re: When to vacuum a table? Marcelo Costa
• 10:31   Re: When to vacuum a table? Rod Taylor
• 10:34   Re: When to vacuum a table? Andrew Sullivan
• 12:28   Re: When to vacuum a table? Craig A. James
• 13:06   Re: When to vacuum a table? Tom Lane
• 13:46   Re: When to vacuum a table? Joshua D. Drake
• 19:25   Re: shared_buffers > 284263 on OS X Jim C. Nasby
• 19:31   Re: availability of SATA vendors Jim C. Nasby
• 19:34   Re: availability of SATA vendors Jim C. Nasby
• 19:41   Re: Postgres server crash Jim C. Nasby
• 20:52   Re: Priority to a mission critical transaction Jim C. Nasby
• 21:01   Re: When to vacuum a table? Jim C. Nasby
• 23:51   Re: shared_buffers > 284263 on OS X Brendan Duddridge

27 November 2006

• 00:04   Re: shared_buffers > 284263 on OS X Tom Lane
• 00:11   Re: shared_buffers > 284263 on OS X Brian Wipf
• 03:11   Re: shared_buffers > 284263 on OS X Guido Neitzer
• 03:11   Re: shared_buffers > 284263 on OS X Guido Neitzer
• 03:24   Re: shared_buffers > 284263 on OS X Brian Wipf
• 03:35   Re: shared_buffers > 284263 on OS X Guido Neitzer
• 04:09   Plattform comparison (lies, damn lies and benchmarks) Guido Neitzer
• 04:44   Re: Massive delete of rows, how to proceed? Merlin Moncure
• 05:23   Re: shared_buffers > 284263 on OS X Jim C. Nasby
• 09:20   Re: Postgres server crash Michael Stone
• 12:05   Re: shared_buffers > 284263 on OS X AgentM
• 12:21   Re: shared_buffers > 284263 on OS X Guido Neitzer
• 14:33   Re: Postgres server crash Florian Weimer
• 14:59   Re: When to vacuum a table? Kevin Grittner

28 November 2006

• 00:25   Re: BUG #2784: Performance serious degrades over a period of a month Bruno Wolff III
• 07:35   Re: BUG #2784: Performance serious degrades over a period Bill Moran
• 08:27   Re: Postgres scalability and performance on windows Gopal
• 12:25   Re: Postgres scalability and performance on windows Tom Lane
• 12:51   Re: Postgres scalability and performance on windows J. Andrew Rogers
• 15:01   RES: Priority to a mission critical transaction Carlos H. Reimer
• 15:07   Re: RES: Priority to a mission critical transaction Tom Lane
• 15:17   Re: RES: Priority to a mission critical transaction Andreas Kostyrka
• 15:45   Re: RES: Priority to a mission critical transaction Josh Berkus
• 16:31   Re: RES: Priority to a mission critical transaction Ron Mayer
• 19:44   Re: RES: Priority to a mission critical transaction Bruce Momjian
• 21:20   Re: RES: Priority to a mission critical transaction Ron Mayer
• 21:26   Re: RES: Priority to a mission critical transaction Mark Kirkwood
• 21:43   Re: RES: Priority to a mission critical transaction Mark Kirkwood

29 November 2006

• 06:55   Re: RES: Priority to a mission critical transaction Ron Mayer
• 07:32   NAMEDATALEN and performance Alessandro Baretta
• 09:26   Re: RES: Priority to a mission critical transaction Brian Hurt
• 11:03   Re: RES: Priority to a mission critical transaction Mark Lewis
• 11:17   Re: RES: Priority to a mission critical transaction Brian Hurt
• 11:50   Re: NAMEDATALEN and performance Tom Lane
• 12:43   Re: RES: Priority to a mission critical transaction Ron Mayer
• 13:21   Re: RES: Priority to a mission critical transaction Brian Hurt
• 14:09   OT - how to size/match multiple databases/apps for a single server Kevin Kempter
• 14:47   Re: RES: Priority to a mission critical transaction Ron Mayer
• 15:43   Fw: [GENERAL] Including unique users in huge data warehouse in Postgresql... Mark Jensen
• 17:56   Re: Fw: [GENERAL] Including unique users in huge data Luke Lonergan

30 November 2006

• 00:29   Re: RES: Priority to a mission critical transaction Josh Berkus
• 19:31   Defining performance. Paul Lathrop
• 20:05   Re: Defining performance. Tobias Brox
• 20:26   Re: Defining performance. Tom Lane
• 20:44   Re: Defining performance. Scott Marlowe
• 20:44   Bad iostat numbers Carlos H. Reimer
• 20:58   Re: Defining performance. Jeff Davis
• 21:08   Re: Defining performance. Tobias Brox
• 21:10   Re: Defining performance. nospam@hardgeus.com
• 21:16   Re: Defining performance. Tobias Brox
• 21:47   Re: Bad iostat numbers Mark Kirkwood
• 22:24   Re: Bad iostat numbers David Boreham
• 23:00   Re: Bad iostat numbers Mark Kirkwood
• 23:32   Re: Defining performance. Chris