Search

Peripheral Links

• Home
• About
• Download
• Documentation
• Community
• Developers
• Support
• Your account

pgsql-performance - November 2006

Search archives
	(enter a message-id to go directly to that message)	Advanced Search

Prev | Next

2006-11-01

• Re: Help w/speeding up range queries? Luke Lonergan (00:10)
• Re: MVCC & indexes? mark (00:20)
• Re: Help w/speeding up range queries? Tom Lane (04:29)
• Context switching Carlos H. Reimer (05:23)
• Re: Help w/speeding up range queries? Luke Lonergan (05:26)
• Re: pg_trgm indexes giving bad estimations? Ben (05:41)
• Re: Help w/speeding up range queries? Tom Lane (05:58)
• big transaction slows down over time - but disk seems almost unused Ben (05:58)
• Re: pg_trgm indexes giving bad estimations? Tom Lane (06:01)
• Re: big transaction slows down over time - but disk Andreas Kostyrka (09:21)
• Re: big transaction slows down over time - but disk seems Heikki Linnakangas (09:39)
• Re: MVCC & indexes? Ivan Voras (12:06)
• Re: big transaction slows down over time - but disk seems almost unused Ben (15:49)
• Re: big transaction slows down over time - but disk seems almost unused Ben (15:56)
• Re: big transaction slows down over time - but disk seems Richard Huxton (16:34)
• Re: big transaction slows down over time - but disk seems Ben (16:51)
• Re: big transaction slows down over time - but disk seems Richard Huxton (17:15)
• Database-wide vacuum can take a long time, during which tables are not being analyzed Steven Flatt (19:15)
• Re: Database-wide vacuum can take a long time, during which Matthew O'Connor (21:56)

2006-11-02

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

2006-11-03

• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Arjen van der Meijden (09:39)
• Context switch storm creimer (10:32)
• profiling PL/pgSQL? Drew Wilson (11:12)
• Re: profiling PL/pgSQL? A. Kretschmer (11:21)
• Re: profiling PL/pgSQL? Richard Huxton (12:07)
• Re: Context switch storm Gregory S. Williamson (12:50)
• Re: Context switch storm Richard Huxton (12:52)
• Re: Context switch storm Cosimo Streppone (13:06)
• Re: Context switch storm creimer (13:28)
• Re: Context switch storm Richard Huxton (13:29)
• Re: Setting "nice" values Andreas Kostyrka (13:34)
• Re: Context switch storm Andreas Kostyrka (13:53)
• Re: Context switch storm Richard Huxton (14:05)
• Re: Context switch storm Richard Troy (14:10)
• Re: Context switch storm Richard Huxton (14:38)
• Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs Tom Lane (14:50)
• Re: Context switch storm Tom Lane (15:25)
• Re: profiling PL/pgSQL? Jonah H. Harris (15:27)
• Re: Context switch storm Andreas Kostyrka (16:16)
• EXISTS optimization Kevin Grittner (19:04)
• Re: profiling PL/pgSQL? korryd (19:40)

2006-11-05

• BUG #2737: hash indexing large table fails, while btree of same index works Balazs Nagy (13:47)
• Re: Slow functional indexes? Stuart Bishop (20:34)

2006-11-06

• Re: Slow functional indexes? Tom Lane (01:23)
• Re: Slow functional indexes? Gene (01:33)
• Re: Setting "nice" values Jim Nasby (04:27)
• Re: Setting "nice" values Madison Kelly (13:10)
• Re: Setting "nice" values Madison Kelly (13:12)
• Re: Setting "nice" values Madison Kelly (13:13)
• Re: Setting "nice" values Tobias Brox (13:33)
• Re: Setting "nice" values Madison Kelly (13:48)
• Re: Setting "nice" values Tobias Brox (14:11)
• Yet another question on LIMIT performance :/ Hannes Dorbath (14:13)
• Re: Yet another question on LIMIT performance :/ Heikki Linnakangas (14:13)
• Re: Setting "nice" values Madison Kelly (14:18)
• Re: Yet another question on LIMIT performance :/ Hannes Dorbath (14:21)
• Re: Yet another question on LIMIT performance :/ Tom Lane (14:33)
• RES: Context switching Carlos H. Reimer (18:29)
• Easy read-heavy benchmark kicking around? Brian Hurt (20:47)
• Re: Easy read-heavy benchmark kicking around? Luke Lonergan (20:53)
• Re: Easy read-heavy benchmark kicking around? Merlin Moncure (21:09)
• Re: Easy read-heavy benchmark kicking around? Scott Marlowe (21:26)
• Re: Context switch storm Cosimo Streppone (21:33)

2006-11-07

• Re: Help w/speeding up range queries? Jim Nasby (01:37)
• Re: Easy read-heavy benchmark kicking around? Mark Kirkwood (01:52)
• Re: Easy read-heavy benchmark kicking around? Dimitri Fontaine (10:49)
• Re: Context switching Josh Berkus (17:42)

2006-11-08

• Re: Easy read-heavy benchmark kicking around? Markus Schaber (16:18)
• Re: Easy read-heavy benchmark kicking around? Merlin Moncure (16:34)
• Re: Easy read-heavy benchmark kicking around? Cosimo Streppone (16:57)
• Re: Which OS provides the _fastest_ PostgreSQL performance? Ron Mayer (17:14)
• Re: Easy read-heavy benchmark kicking around? Luke Lonergan (19:32)

2006-11-09

• Keeping processes open for re-use Hilary Forbes (12:35)
• Re: Keeping processes open for re-use Csaba Nagy (12:56)
• Re: Easy read-heavy benchmark kicking around? Merlin Moncure (17:28)
• Re: Keeping processes open for re-use imad (17:55)

2006-11-10

• Re: Keeping processes open for re-use Shane Ambler (02:09)
• Re: Keeping processes open for re-use Joshua D. Drake (02:19)
• 10x rowcount mis-estimation favouring merge over nestloop Abhijit Menon-Sen (05:12)
• Re: 10x rowcount mis-estimation favouring merge over nestloop Tom Lane (06:15)
• Re: 10x rowcount mis-estimation favouring merge over nestloop Abhijit Menon-Sen (07:07)
• Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?] Ron Mayer (18:54)
• Re: BUG #2737: hash indexing large table fails, while btree of same index works Tom Lane (23:55)

2006-11-11

• Re: [PERFORM] BUG #2737: hash indexing large table fails,while btree of same index works Simon Riggs (08:17)

2006-11-13

• Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?] Guy Thornley (08:32)

2006-11-14

• Re: Context switch storm Cosimo Streppone (09:51)
• Re: Context switch storm Andreas Kostyrka (10:13)
• Re: Context switch storm Merlin Moncure (14:17)
• Re: Context switch storm Jim C. Nasby (16:50)
• Re: Context switch storm Bucky Jordan (17:53)
• Re: Context switch storm Merlin Moncure (20:11)
• Re: Context switch storm Cosimo Streppone (21:43)

2006-11-15

• Re: Context switch storm Simon Riggs (09:07)
• Slow SELECT on three or more clients AMIR FRANCO D. JOVEN (11:37)
• Re: Slow SELECT on three or more clients Andreas Kostyrka (13:29)
• Re: Slow SELECT on three or more clients Russell Smith (13:31)
• Re: Slow SELECT on three or more clients Gregory S. Williamson (14:01)
• Re: Slow SELECT on three or more clients Merlin Moncure (14:17)
• Re: Slow SELECT on three or more clients Markus Schaber (14:47)
• Hundreds of database and FSM Craig A. James (16:31)
• Re: Hundreds of database and FSM Alvaro Herrera (17:31)
• Re: Hundreds of database and FSM Steinar H. Gunderson (17:42)

2006-11-16

• Postgres server crash Craig A. James (02:20)
• Re: Postgres server crash Russell Smith (02:28)
• Re: Slow SELECT on three or more clients AMIR FRANCO D. JOVEN (08:47)
• Re: Postgres server crash Richard Huxton (10:48)
• Re: Postgres server crash Merlin Moncure (14:01)
• Re: Postgres server crash Craig A. James (17:00)
• Re: Postgres server crash Richard Huxton (17:09)
• Re: Postgres server crash Craig A. James (17:15)
• Re: Postgres server crash Richard Huxton (17:29)
• Re: Keeping processes open for re-use Jean-Max Reymond (17:39)
• Re: Postgres server crash Tom Lane (18:10)
• Re: Postgres server crash Tom Lane (18:14)
• Re: Postgres server crash Richard Huxton (18:22)
• Re: Postgres server crash Ben (21:00)
• Re: Context switch storm Jim Nasby (21:01)
• Re: [PERFORM] BUG #2737: hash indexing large table fails,while btree of same index works Tom Lane (22:48)

2006-11-17

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

2006-11-18

• Re: Optimicing Postgres for SunSolaris10 on V240 Marc Cousin (09:08)
• start up cost estimate rakesh kumar (09:33)
• Re: start up cost estimate Joshua Marsh (14:27)
• Re: shared_buffers > 284263 on OS X Dave Cramer (16:17)
• Re: shared_buffers > 284263 on OS X Guido Neitzer (17:48)
• Re: start up cost estimate Tom Lane (18:11)
• Re: shared_buffers > 284263 on OS X Tom Lane (18:30)
• Re: shared_buffers > 284263 on OS X Guido Neitzer (18:44)

2006-11-19

• Re: Postgres server crash Richard Troy (01:28)
• Re: shared_buffers > 284263 on OS X Brian Wipf (03:13)
• Fwd: start up cost estimate rakesh kumar (04:05)
• Re: Postgres server crash Craig A. James (06:43)
• Re: Postgres server crash Tom Lane (06:51)
• Re: shared_buffers > 284263 on OS X Guido Neitzer (15:20)
• Re: Postgres server crash Ron Mayer (17:01)
• Re: Postgres server crash Ron Mayer (17:07)
• Re: Postgres server crash Michael Stone (18:41)
• Re: Postgres server crash Richard Broersma Jr (20:42)
• Re: Postgres server crash Michael Stone (21:24)
• Re: Postgres server crash Craig A. James (22:12)
• PostgreSQL with 64 bit was: Re: shared_buffers > 284263 on OS X Guido Neitzer (22:22)
• Re: Postgres server crash Michael Stone (22:32)

2006-11-20

• Re: Postgres server crash Craig A. James (01:00)
• Re: Postgres server crash Bruno Wolff III (01:59)
• Re: Postgres server crash Craig A. James (06:42)
• Re: Postgres server crash Mattias Kregert (22:36)

2006-11-21

• BitMapScan performance degradation Jérôme BENOIS (09:21)
• RES: Context switching Carlos H. Reimer (12:44)
• Re: Postgres server crash Markus Schaber (13:22)
• Re: BitMapScan performance degradation db (15:12)
• Re: BitMapScan performance degradation Jérôme BENOIS (15:35)
• Re: BitMapScan performance degradation Tom Lane (15:44)
• Slow Query Joe Lester (17:03)
• Re: Slow Query Joe Lester (19:52)
• Priority to a mission critical transaction Carlos H. Reimer (23:43)

2006-11-22

• Re: availability of SATA vendors Jeff Frost (01:54)
• Re: availability of SATA vendors Joshua D. Drake (02:13)
• Re: availability of SATA vendors Jeff Frost (02:15)
• Re: availability of SATA vendors Joshua D. Drake (02:37)
• PostgreSQL underestimates sorting Markus Schaber (10:17)
• Re: PostgreSQL underestimates sorting Steinar H. Gunderson (13:54)
• Re: availability of SATA vendors Bucky Jordan (14:18)
• Re: PostgreSQL underestimates sorting Markus Schaber (14:28)
• Re: availability of SATA vendors Jeff Frost (16:36)
• Re: PostgreSQL underestimates sorting Frank Wiles (16:53)
• Re: PostgreSQL underestimates sorting Markus Schaber (16:59)
• Re: availability of SATA vendors Joshua D. Drake (17:00)
• Re: availability of SATA vendors Jeff Frost (17:02)
• Re: availability of SATA vendors Arjen van der Meijden (17:07)
• Re: availability of SATA vendors Joshua D. Drake (17:09)
• Re: availability of SATA vendors Scott Marlowe (17:34)
• Re: availability of SATA vendors Bucky Jordan (21:35)
• Re: availability of SATA vendors Luke Lonergan (21:47)

Prev | Next