Mailing lists [pgsql-performance]

1 December 2006

• 00:08   Re: Defining performance. Tobias Brox
• 00:10   Re: Defining performance. nospam@hardgeus.com
• 00:16   Re: Defining performance. Tobias Brox
• 00:47   Re: Bad iostat numbers Mark Kirkwood
• 01:24   Re: Bad iostat numbers David Boreham
• 02:00   Re: Bad iostat numbers Mark Kirkwood
• 02:32   Re: Defining performance. Chris
• 03:42   Re: Defining performance. Tobias Brox
• 07:55   Re: NAMEDATALEN and performance Alessandro Baretta
• 09:36   Re: Defining performance. Heikki Linnakangas
• 13:29   RES: Bad iostat numbers Carlos H. Reimer
• 13:47   RES: Bad iostat numbers Carlos H. Reimer
• 14:16   Re: NAMEDATALEN and performance Tom Lane
• 14:32   Re: RES: Bad iostat numbers David Boreham
• 15:34   Performance of Perc 5i Alex Turner
• 16:06   Re: Performance of Perc 5i Bucky Jordan

2 December 2006

• 14:50   Dump performance problems following server crash Kim
• 16:13   Re: Dump performance problems following server crash Tom Lane
• 16:29   Re: Dump performance problems following server crash Kim
• 18:24   Regex performance issue Alexandru Coseru
• 19:36   Re: Regex performance issue Dave Dutcher
• 19:49   Re: Regex performance issue Alexandru Coseru
• 19:55   Re: Regex performance issue Oleg Bartunov
• 21:04   Re: Regex performance issue Heikki Linnakangas
• 21:13   Re: Regex performance issue Alexandru Coseru
• 21:35   Re: Regex performance issue Heikki Linnakangas
• 23:54   Re: Regex performance issue Alexandru Coseru
• 23:55   Re: Regex performance issue Alexandru Coseru

3 December 2006

• 00:31   Re: Regex performance issue Scott Marlowe
• 03:05   Re: Regex performance issue Tom Lane
• 06:05   Re: Regex performance issue Oleg Bartunov
• 07:59   Which query analiser tools are available? Joost Kraaijeveld
• 08:56   Re: Which query analiser tools are available? Andreas Kretschmer
• 10:11   Re: Regex performance issue Alexandru Coseru
• 14:11   Propagating outer join conditions Aaron Birkland
• 14:47   Re: Propagating outer join conditions Jonathan Blitz
• 15:30   Re: Propagating outer join conditions Aaron Birkland
• 16:29   Hardware advice Alexandru Coseru
• 17:24   Re: Propagating outer join conditions Tom Lane
• 19:10   Re: Hardware advice Josh Berkus
• 20:38   Re: Hardware advice Alexandru Coseru
• 21:22   Enabling constraint_exclusion does not avoid scanning all child partitions Fayza Sultan
• 21:25   Re: Enabling constraint_exclusion does not avoid scanning all child partitions Tom Lane
• 21:37   Re: Enabling constraint_exclusion does not avoid scanning all child partitions Fayza Sultan

4 December 2006

• 04:35   Is Vacuum/analyze destroying my performance? Carlo Stonebanks
• 04:49   Re: Is Vacuum/analyze destroying my performance? Carlo Stonebanks
• 04:52   Re: Bad iostat numbers Greg Smith
• 06:18   Re: Bad iostat numbers Alex Turner
• 06:45   8.2rc1 (much) slower than 8.2dev? Arjen van der Meijden
• 13:37   Re: Is Vacuum/analyze destroying my performance? Matthew O'Connor
• 13:53   Re: 8.2rc1 (much) slower than 8.2dev? Tom Lane
• 15:25   Re: Bad iostat numbers Scott Marlowe
• 15:37   Re: Bad iostat numbers Scott Marlowe
• 15:41   Re: 8.2rc1 (much) slower than 8.2dev? Arjen van der Meijden
• 16:08   Re: Is Vacuum/analyze destroying my performance? Carlo Stonebanks
• 16:23   Configuration settings for 32GB RAM server Mark Lonsdale
• 16:37   Re: Bad iostat numbers Alex Turner
• 16:43   Re: Configuration settings for 32GB RAM server Jeff Davis
• 16:44   Re: Bad iostat numbers Michael Stone
• 16:48   How to move pg_xlog to another drive on Windows???? Joost Kraaijeveld
• 16:52   Re: Bad iostat numbers Alex Turner
• 17:03   Re: Bad iostat numbers Michael Stone
• 17:05   Re: Bad iostat numbers Scott Marlowe
• 17:13   Re: Bad iostat numbers Scott Marlowe
• 17:45   Re: Configuration settings for 32GB RAM server Vivek Khera
• 17:57   Re: Configuration settings for 32GB RAM server Joshua Marsh
• 18:04   Re: How to move pg_xlog to another drive on Windows???? Merlin Moncure
• 18:23   Re: Configuration settings for 32GB RAM server Scott Marlowe
• 18:30   Re: How to move pg_xlog to another drive on Windows???? Anthony Presley
• 22:29   Re: Configuration settings for 32GB RAM server Dave Cramer
• 23:05   pgsql upgrade Matt Chambers

5 December 2006

• 03:10   Re: Bad iostat numbers Greg Smith
• 03:47   Re: How to move pg_xlog to another drive on K C Lau
• 04:18   Re: Is Vacuum/analyze destroying my performance? Matthew T. O'Connor
• 05:21   Re: Bad iostat numbers Alex Turner
• 08:05   JOIN work somehow strange on simple query Anton
• 08:39   Re: JOIN work somehow strange on simple query Anton
• 09:22   Re: Hardware advice Sven Geisler
• 10:14   Re: Configuration settings for 32GB RAM server Mark Lonsdale
• 11:15   Re: Bad iostat numbers Michael Stone
• 11:57   Re: Bad iostat numbers Alex Turner
• 13:48   Re: Bad iostat numbers Craig A. James
• 13:50   Re: Bad iostat numbers Michael Stone
• 14:27   single transaction vs multiple transactions Sven Geisler
• 14:30   Re: single transaction vs multiple transactions Heikki Linnakangas
• 14:35   Re: single transaction vs multiple transactions Sven Geisler
• 14:43   Re: single transaction vs multiple transactions Heikki Linnakangas
• 14:59   Re: single transaction vs multiple transactions Sven Geisler
• 15:55   Re: single transaction vs multiple transactions Tom Lane
• 16:18   Performance of ORDER BY Glenn Sullivan
• 16:36   Re: Performance of ORDER BY Luke Lonergan
• 16:46   Restart time Jean Arnaud
• 17:02   Re: Performance of ORDER BY Tom Lane
• 17:17   Re: Restart time Tom Lane
• 17:17   Re: Performance of ORDER BY Steinar H. Gunderson
• 17:20   Re: Performance of ORDER BY A. Kretschmer
• 17:39   Re: Performance of ORDER BY Tom Lane
• 18:32   Re: Restart time Rajesh Kumar Mallah
• 18:40   Re: Restart time Tom Lane
• 18:56   Re: Performance of ORDER BY Stefan Kaltenbrunner
• 19:07   Re: single transaction vs multiple transactions Jens Schipkowski
• 19:43   Re: Performance of ORDER BY Glenn Sullivan
• 20:44   Re: Hardware advice Alexandru Coseru
• 22:07   Re: shared_buffers > 284263 on OS X Brian Wipf
• 22:10   Re: shared_buffers > 284263 on OS X Tom Lane
• 23:06   Re: shared_buffers > 284263 on OS X Brian Wipf

6 December 2006

• 02:02   max/min and index usage Tobias Brox
• 02:17   Re: max/min and index usage Tobias Brox
• 02:30   Re: max/min and index usage Tom Lane
• 02:35   Re: max/min and index usage Tobias Brox
• 03:24   Re: Hardware advice Alex Turner
• 03:55   Re: Bad iostat numbers Greg Smith
• 05:20   Re: Restart time Rajesh Kumar Mallah
• 06:04   Locking in PostgreSQL? Joost Kraaijeveld
• 07:49   Re: Restart time Jean Arnaud
• 08:09   Re: Hardware advice Sven Geisler
• 08:21   Re: Hardware advice Gregory S. Williamson
• 11:29   Re: Locking in PostgreSQL? Dave Cramer
• 12:20   Re: Locking in PostgreSQL? Jens Schipkowski
• 12:26   Re: Locking in PostgreSQL? Dave Cramer
• 12:31   Re: Locking in PostgreSQL? Steinar H. Gunderson
• 12:42   Re: [GENERAL] Locking in PostgreSQL? Markus Schiltknecht
• 12:46   Re: [GENERAL] Locking in PostgreSQL? Martijn van Oosterhout
• 14:41   File Systems Compared Brian Wipf
• 15:02   Re: File Systems Compared Brian Hurt
• 15:06   Re: File Systems Compared Alexander Staubo
• 15:21   Re: Bad iostat numbers Steve Atkins
• 15:22   Re: File Systems Compared Luke Lonergan
• 15:31   Re: File Systems Compared Markus Schiltknecht
• 15:33   Re: File Systems Compared Joshua D. Drake
• 15:40   Re: File Systems Compared Brian Hurt
• 15:44   Re: File Systems Compared Steinar H. Gunderson
• 15:44   Re: File Systems Compared Florian Weimer
• 15:55   Re: File Systems Compared Mark Lewis
• 16:07   VACUUM FULL does not works....... asif ali
• 16:13   Re: VACUUM FULL does not works....... Jean-Max Reymond
• 16:21   Re: VACUUM FULL does not works....... Scott Marlowe
• 16:40   Re: File Systems Compared Luke Lonergan
• 16:46   Re: File Systems Compared Markus Schiltknecht
• 16:47   Re: VACUUM FULL does not works....... Rajesh Kumar Mallah
• 16:59   Re: Locking in PostgreSQL? Casey Duncan
• 16:59   Re: File Systems Compared Arnaud Lesauvage
• 17:08   [offtopic] Word wrapping Steinar H. Gunderson
• 17:09   Re: Locking in PostgreSQL? Erik Jones
• 17:12   Re: File Systems Compared Michael Stone
• 17:37   Re: VACUUM FULL does not works....... asif ali
• 17:47   Re: [offtopic] File Systems Compared Brian Wipf
• 18:11   Problems with an update-from statement and pg-8.1.4 Rafael Martinez
• 18:20   Re: Problems with an update-from statement and pg-8.1.4 Stephan Szabo
• 18:53   Re: Problems with an update-from statement and pg-8.1.4 Ted Allen
• 18:55   Re: VACUUM FULL does not works....... Tom Lane
• 19:11   Re: Problems with an update-from statement and pg-8.1.4 Rafael Martinez
• 19:12   Re: File Systems Compared Merlin Moncure
• 19:19   Re: Problems with an update-from statement and pg-8.1.4 Erik Jones
• 19:24   Re: File Systems Compared Brian Hurt
• 19:29   Re: Problems with an update-from statement and pg-8.1.4 Rafael Martinez
• 19:30   Re: File Systems Compared Bruno Wolff III
• 19:31   Re: Problems with an update-from statement and pg-8.1.4 Erik Jones
• 19:33   Disk storage and san questions (was File Systems Compared) Matthew Schumacher
• 19:59   Re: File Systems Compared Ron
• 20:48   Re: File Systems Compared Brian Wipf
• 21:08   Re: VACUUM FULL does not works....... asif ali
• 21:13   Re: VACUUM FULL does not works....... Scott Marlowe
• 21:30   Re: Areca 1260 Performance (was: File Systems Compared) Brian Wipf
• 22:26   Re: Areca 1260 Performance (was: File Systems Ron
• 22:41   Re: Areca 1260 Performance Brian Wipf
• 23:19   Re: VACUUM FULL does not works....... asif ali
• 23:26   Re: Areca 1260 Performance Ron

7 December 2006

• 05:01   Re: 8.2rc1 (much) slower than 8.2dev? Jim C. Nasby
• 05:03   Re: Configuration settings for 32GB RAM server Jim C. Nasby
• 05:17   Re: File Systems Compared Greg Smith
• 05:58   Re: VACUUM FULL does not works....... Rajesh Kumar Mallah
• 07:37   Re: Areca 1260 Performance Brian Wipf
• 08:13   Re: 8.2rc1 (much) slower than 8.2dev? Arjen van der Meijden
• 09:18   Core 2 or Opteron Mindaugas
• 09:29   Re: Core 2 or Opteron Arjen van der Meijden
• 09:44   Re: Core 2 or Opteron Claus Guttesen
• 10:05   Re: Core 2 or Opteron Mindaugas
• 10:19   Re: Core 2 or Opteron Arjen van der Meijden
• 11:34   Re: Areca 1260 Performance Ron
• 12:19   SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can helpe me. Marcos Borges
• 14:38   Re: 8.2rc1 (much) slower than 8.2dev? Tom Lane
• 14:44   Re: Areca 1260 Performance Shane Ambler
• 15:03   Re: Areca 1260 Performance Gene
• 15:35   Advice on selecting good values for work_mem? Bill Moran
• 15:42   How to determine if my setting for shared_buffers is too high? Bill Moran
• 16:03   Re: Advice on selecting good values for work_mem? Tom Lane
• 16:04   Re: How to determine if my setting for shared_buffers is too high? Tom Lane
• 17:16   Re: Advice on selecting good values for work_mem? Stephen Frost
• 20:23   Re: File Systems Compared Merlin Moncure
• 23:07   Re: Disk storage and san questions (was File Systems Compared) Bucky Jordan
• 23:11   Re: Areca 1260 Performance Ron

8 December 2006

• 03:04   Re: One table is very slow, but replicated table (same data) is fine Chris Browne
• 18:19   Re: How to determine if my setting for shared_buffers is too high? Jim C. Nasby

9 December 2006

• 00:24   Re: Low throughput of binary inserts from windows to linux Axel Waggershauser
• 02:52   Re: Low throughput of binary inserts from windows to linux Tom Lane

10 December 2006

• 18:43   New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 22:52   Re: New to PostgreSQL, performance considerations Shane Ambler

11 December 2006

• 00:02   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 00:15   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 00:18   Re: New to PostgreSQL, performance considerations Gene
• 00:47   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 01:11   Re: New to PostgreSQL, performance considerations Michael Glaesemann
• 01:19   Re: New to PostgreSQL, performance considerations Michael Stone
• 01:44   Re: New to PostgreSQL, performance considerations Dave Cramer
• 02:29   Re: New to PostgreSQL, performance considerations Alexander Staubo
• 02:33   Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can helpe Chris
• 02:38   Re: New to PostgreSQL, performance considerations Tatsuo Ishii
• 03:02   Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can Joshua D. Drake
• 03:36   Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can Chris
• 03:57   Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can Tom Lane
• 04:50   Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can Mark Kirkwood
• 05:01   Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can Chris
• 05:38   Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can Andreas Kostyrka
• 07:08   Postgresql - Threshold value. Ravindran G - TLS, Chennai.
• 08:06   Re: New to PostgreSQL, performance considerations Alexander Staubo
• 08:19   Re: Postgresql - Threshold value. Rajesh Kumar Mallah
• 08:33   Re: New to PostgreSQL, performance considerations Alexander Staubo
• 08:38   Re: Postgresql - Threshold value. Kaloyan Iliev
• 08:39   Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can Ragnar
• 09:33   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 09:36   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 10:04   Re: New to PostgreSQL, performance considerations Dave Cramer
• 10:06   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 10:08   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 10:26   Re: New to PostgreSQL, performance considerations Steinar H. Gunderson
• 11:16   Re: New to PostgreSQL, performance considerations Michael Stone
• 12:09   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 12:17   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 12:18   Re: New to PostgreSQL, performance considerations Christopher Browne
• 12:32   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 12:34   Re: New to PostgreSQL, performance considerations Steinar H. Gunderson
• 12:46   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 13:03   Re: New to PostgreSQL, performance considerations Steinar H. Gunderson
• 13:06   Re: New to PostgreSQL, performance considerations Steinar H. Gunderson
• 13:11   Re: Postgresql - Threshold value. Ravindran G - TLS, Chennai.
• 13:25   Re: Postgresql - Threshold value. A. Kretschmer
• 13:44   Re: Postgresql - Threshold value. Ravindran G - TLS, Chennai.
• 13:47   Re: New to PostgreSQL, performance considerations Merlin Moncure
• 13:58   Re: Low throughput of binary inserts from windows to linux Axel Waggershauser
• 14:03   Re: Low throughput of binary inserts from windows to linux Thomas H.
• 14:16   Re: Low throughput of binary inserts from windows to linux Axel Waggershauser
• 14:42   Re: Postgresql - Threshold value. Rajesh Kumar Mallah
• 14:59   Re: Low throughput of binary inserts from windows to linux Tom Lane
• 15:04   Re: New to PostgreSQL, performance considerations Chris Browne
• 15:09   Re: Postgresql - Threshold value. Tom Lane
• 15:25   Re: Low throughput of binary inserts from windows to Kevin Grittner
• 15:27   Looking for hw suggestions for high concurrency OLTP app Cosimo Streppone
• 15:45   really quick multiple inserts can use COPY? Jens Schipkowski
• 15:56   Re: really quick multiple inserts can use COPY? Andreas Kretschmer
• 16:01   Re: really quick multiple inserts can use COPY? Rajesh Kumar Mallah
• 16:11   Re: really quick multiple inserts can use COPY? Tom Lane
• 16:13   Re: really quick multiple inserts can use COPY? Guillaume Cottenceau
• 16:16   Re: New to PostgreSQL, performance considerations Ron
• 16:34   Re: New to PostgreSQL, performance considerations Michael Stone
• 16:53   Re: File Systems Compared Bruno Wolff III
• 17:21   Re: New to PostgreSQL, performance considerations Ron
• 17:36   Re: New to PostgreSQL, performance considerations Luke Lonergan
• 17:38   Re: Looking for hw suggestions for high concurrency Luke Lonergan
• 17:55   Re: New to PostgreSQL, performance considerations Michael Stone
• 18:04   Re: New to PostgreSQL, performance considerations Michael Stone
• 18:22   Re: really quick multiple inserts can use COPY? imad
• 18:28   Re: New to PostgreSQL, performance considerations Merlin Moncure
• 18:51   Re: New to PostgreSQL, performance considerations Ron
• 19:07   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 19:08   Re: New to PostgreSQL, performance considerations Ron
• 19:09   Re: New to PostgreSQL, performance considerations Luke Lonergan
• 19:10   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 19:10   Re: New to PostgreSQL, performance considerations Michael Stone
• 19:14   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 19:19   Re: Looking for hw suggestions for high concurrency Merlin Moncure
• 20:40   Re: Looking for hw suggestions for high concurrency Luke Lonergan
• 20:47   Re: New to PostgreSQL, performance considerations Craig A. James
• 21:14   Re: New to PostgreSQL, performance considerations Mark Kirkwood
• 21:22   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 21:31   Re: New to PostgreSQL, performance considerations Luke Lonergan
• 21:44   Re: Low throughput of binary inserts from windows to linux Axel Waggershauser

12 December 2006

• 00:25   Re: Low throughput of binary inserts from windows to linux Tom Lane
• 00:37   Re: New to PostgreSQL, performance considerations Michael Stone
• 02:39   Re: New to PostgreSQL, performance considerations Christopher Browne
• 05:35   Re: New to PostgreSQL, performance considerations Greg Smith
• 05:47   Re: New to PostgreSQL, performance considerations Tom Lane
• 06:39   Re: Low throughput of binary inserts from windows to linux Florian Weimer
• 06:46   Re: really quick multiple inserts can use COPY? Jens Schipkowski
• 07:12   Re: really quick multiple inserts can use COPY? nicky
• 08:10   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 09:19   Re: Low throughput of binary inserts from windows to linux Axel Waggershauser
• 09:34   Re: New to PostgreSQL, performance considerations Guido Neitzer
• 10:30   Re: New to PostgreSQL, performance considerations Alexander Staubo
• 11:30   Re: New to PostgreSQL, performance considerations Michael Stone
• 11:31   Re: New to PostgreSQL, performance considerations Michael Stone
• 11:33   Re: New to PostgreSQL, performance considerations Michael Stone
• 11:42   Re: New to PostgreSQL, performance considerations Cosimo Streppone
• 11:46   Re: New to PostgreSQL, performance considerations Steinar H. Gunderson
• 11:48   Re: New to PostgreSQL, performance considerations Michael Stone
• 11:56   Re: New to PostgreSQL, performance considerations Michael Stone
• 13:28   Re: New to PostgreSQL, performance considerations Brad Nicholson
• 13:33   Re: New to PostgreSQL, performance considerations Alexander Staubo
• 14:13   Re: New to PostgreSQL, performance considerations Ron
• 14:17   Re: New to PostgreSQL, performance considerations Florian Weimer
• 14:26   Re: New to PostgreSQL, performance considerations Bill Moran
• 14:48   Re: New to PostgreSQL, performance considerations Tom Lane
• 14:57   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 14:58   Re: New to PostgreSQL, performance considerations David Boreham
• 15:08   Re: New to PostgreSQL, performance considerations Greg Smith
• 15:11   Re: New to PostgreSQL, performance considerations Alvaro Herrera
• 15:33   Re: Low throughput of binary inserts from windows to linux Tom Lane
• 15:36   Re: New to PostgreSQL, performance considerations Greg Smith
• 15:56   Re: Low throughput of binary inserts from windows to linux David Boreham
• 15:59   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 16:14   Re: New to PostgreSQL, performance considerations Tom Lane
• 16:32   Re: New to PostgreSQL, performance considerations Tom Lane
• 16:56   Re: New to PostgreSQL, performance considerations Ron
• 17:36   Re: New to PostgreSQL, performance considerations Daniel van Ham Colchete
• 19:31   Re: New to PostgreSQL, performance considerations Ron
• 19:49   Re: New to PostgreSQL, performance considerations Bucky Jordan
• 20:09   Re: New to PostgreSQL, performance considerations Greg Smith
• 21:39   Re: New to PostgreSQL, performance considerations Christopher Browne

13 December 2006

• 08:22   Re: New to PostgreSQL, performance considerations Sven Geisler
• 09:51   Slow update with simple query Arnaud Lesauvage
• 10:19   Re: Slow update with simple query Ragnar
• 10:35   Re: Slow update with simple query Arnaud Lesauvage
• 11:18   Re: Slow update with simple query Jens Schipkowski
• 11:24   Re: Slow update with simple query Arnaud Lesauvage
• 12:21   Re: Slow update with simple query Jens Schipkowski
• 12:38   Re: Slow update with simple query Arnaud Lesauvage
• 13:48   Re: Slow update with simple query Ragnar
• 14:20   Re: Slow update with simple query Arnaud Lesauvage
• 15:13   Re: New to PostgreSQL, performance considerations Cosimo Streppone
• 15:44   Re: Slow update with simple query asif ali
• 15:44   Insertion to temp table deteriorating over time Steven Flatt
• 15:46   Re: Slow update with simple query Tom Lane
• 15:47   Re: Slow update with simple query Arnaud Lesauvage
• 16:14   Re: Insertion to temp table deteriorating over time Rajesh Kumar Mallah
• 16:29   Re: Insertion to temp table deteriorating over time Tom Lane
• 16:51   Re: Slow update with simple query Mark Lewis
• 17:04   Re: New to PostgreSQL, performance considerations Ron
• 17:47   Re: Slow update with simple query Tom Lane
• 17:50   Re: New to PostgreSQL, performance considerations Bucky Jordan
• 18:02   strange query behavior Tim Jones
• 18:14   Re: strange query behavior Ragnar
• 18:16   Re: strange query behavior Tom Lane
• 18:18   Optimizing a query James Cloos
• 18:25   Re: Optimizing a query Tomeh, Husam
• 18:44   Re: strange query behavior Tim Jones
• 18:50   Re: New to PostgreSQL, performance considerations Ron
• 18:59   Re: New to PostgreSQL, performance considerations Guido Neitzer
• 20:49   Re: Optimizing a query Tom Lane
• 20:59   Re: strange query behavior Tom Lane
• 21:08   Re: strange query behavior Tim Jones
• 21:36   Re: Optimizing a query James Cloos
• 21:36   Re: strange query behavior Tom Lane
• 21:44   Re: strange query behavior Tim Jones
• 21:54   Re: strange query behavior Tim Jones
• 22:15   Re: Optimizing a query Tomeh, Husam
• 22:17   Re: Insertion to temp table deteriorating over time Steven Flatt
• 22:25   Re: strange query behavior Tom Lane
• 22:27   Re: Insertion to temp table deteriorating over time Tom Lane
• 22:44   Re: Insertion to temp table deteriorating over time Tom Lane

14 December 2006

• 00:04   Re: New to PostgreSQL, performance considerations Bruce Momjian
• 01:21   Re: New to PostgreSQL, performance considerations Rajesh Kumar Mallah
• 01:36   Re: New to PostgreSQL, performance considerations Josh Berkus
• 02:01   Re: New to PostgreSQL, performance considerations Joshua D. Drake
• 04:50   Re: New to PostgreSQL, performance considerations Tom Lane
• 05:11   Re: New to PostgreSQL, performance considerations Michael Glaesemann
• 05:39   Re: File Systems Compared Jim Nasby
• 05:45   Re: New to PostgreSQL, performance considerations Ron
• 05:49   Re: New to PostgreSQL, performance considerations Gregory S. Williamson
• 13:01   Re: Slow update with simple query Arnaud Lesauvage
• 13:02   Re: strange query behavior Tim Jones
• 13:04   EXPLAIN ANALYZE on 8.2 Evgeny Gridasov
• 14:00   Re: New to PostgreSQL, performance considerations Greg Smith
• 14:18   Re: Slow update with simple query Tom Lane
• 14:23   Re: Slow update with simple query Arnaud Lesauvage
• 14:24   Re: New to PostgreSQL, performance considerations Greg Smith
• 14:27   Re: New to PostgreSQL, performance considerations Michael Stone
• 15:03   Re: New to PostgreSQL, performance considerations Ron
• 15:12   Re: EXPLAIN ANALYZE on 8.2 Tom Lane
• 15:16   Re: New to PostgreSQL, performance considerations Matthew O'Connor
• 15:19   Re: Slow update with simple query Tom Lane
• 15:26   Re: Slow update with simple query Arnaud Lesauvage
• 15:30   Re: EXPLAIN ANALYZE on 8.2 Evgeny Gridasov
• 15:36   Re: Slow update with simple query Mark Lewis
• 15:41   Re: EXPLAIN ANALYZE on 8.2 Tom Lane
• 15:51   Re: Slow update with simple query Tom Lane
• 16:14   unsubscribe Rohit Prakash Khare
• 16:47   Re: File Systems Compared Bruno Wolff III
• 16:48   Re: strange query behavior Tom Lane
• 17:30   Re: strange query behavior Tom Lane
• 18:15   Re: New to PostgreSQL, performance considerations Alexander Staubo
• 18:19   Re: strange query behavior Tim Jones
• 18:29   Re: New to PostgreSQL, performance considerations Ron
• 19:40   Re: Insertion to temp table deteriorating over time Steven Flatt
• 20:21   Re: File Systems Compared Ron Mayer
• 20:23   Re: Insertion to temp table deteriorating over time Tom Lane
• 21:41   Re: New to PostgreSQL, performance considerations Alexander Staubo
• 22:43   Re: EXPLAIN ANALYZE on 8.2 Kelly Burkhart
• 22:59   Re: EXPLAIN ANALYZE on 8.2 Mark Kirkwood
• 23:05   Re: EXPLAIN ANALYZE on 8.2 Tom Lane
• 23:16   Re: New to PostgreSQL, performance considerations Ron
• 23:29   Re: New to PostgreSQL, performance considerations Alexander Staubo

15 December 2006

• 02:09   Re: New to PostgreSQL, performance considerations Ron
• 02:22   Re: New to PostgreSQL, performance considerations Greg Smith
• 08:54   Re: New to PostgreSQL, performance considerations Alexander Staubo
• 09:28   Re: New to PostgreSQL, performance considerations Steinar H. Gunderson
• 09:29   Re: EXPLAIN ANALYZE on 8.2 Simon Riggs
• 09:50   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Martijn van Oosterhout
• 10:24   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Dimitri Fontaine
• 10:56   Re: New to PostgreSQL, performance considerations Ron
• 11:21   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Simon Riggs
• 11:25   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Martijn van Oosterhout
• 11:31   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Martijn van Oosterhout
• 11:32   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Florian Weimer
• 13:23   Re: New to PostgreSQL, performance considerations Merlin Moncure
• 13:50   Re: New to PostgreSQL, performance considerations Greg Smith
• 13:57   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Tom Lane
• 14:05   Re: New to PostgreSQL, performance considerations Ron
• 14:46   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Tom Lane
• 14:49   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Martijn van Oosterhout
• 14:55   Re: New to PostgreSQL, performance considerations Merlin Moncure
• 14:57   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Tom Lane
• 15:10   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Gregory Stark
• 15:21   Re: Insertion to temp table deteriorating over time Steven Flatt
• 15:33   Re: File Systems Compared Bruno Wolff III
• 15:43   Re: File Systems Compared Bruno Wolff III
• 15:53   Re: New to PostgreSQL, performance considerations Ron
• 15:56   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Ron
• 16:09   Re: Insertion to temp table deteriorating over time Tom Lane
• 16:25   Re: New to PostgreSQL, performance considerations Ron
• 16:56   Re: Insertion to temp table deteriorating over time Steven Flatt
• 17:06   Re: Insertion to temp table deteriorating over time Tom Lane
• 17:26   Re: Insertion to temp table deteriorating over time Steven Flatt
• 18:09   Re: Insertion to temp table deteriorating over time Tom Lane
• 18:21   Re: Insertion to temp table deteriorating over time Steven Flatt
• 18:30   Re: Insertion to temp table deteriorating over time Tom Lane
• 20:11   Re: File Systems Compared Bruno Wolff III
• 21:30   Re: New to PostgreSQL, performance considerations Alexander Staubo
• 23:07   Re: New to PostgreSQL, performance considerations Michael Stone

16 December 2006

• 02:24   opportunity to benchmark a quad core Xeon Jeff Frost
• 07:11   Re: opportunity to benchmark a quad core Xeon Arjen van der Meijden
• 07:27   Re: New to PostgreSQL, performance considerations Cosimo Streppone
• 13:49   partition text/varchar check problem jamcito
• 14:49   Re: partition text/varchar check problem Tom Lane
• 14:53   Re: New to PostgreSQL, performance considerations Ron
• 15:04   Re: New to PostgreSQL, performance considerations Steinar H. Gunderson
• 16:26   Scaling concerns tsuraan
• 16:32   Re: Scaling concerns Steinar H. Gunderson
• 16:34   Re: New to PostgreSQL, performance considerations Michael Stone
• 17:03   Re: Scaling concerns tsuraan
• 17:19   Re: partition text/varchar check problem -- solved jamcito
• 19:23   Re: partition text/varchar check problem Ireneusz Pluta
• 19:30   Re: partition text/varchar check problem jamcito
• 19:34   Re: partition text/varchar check problem Tom Lane
• 20:33   Re: Scaling concerns Dimitri Fontaine

17 December 2006

• 02:21   Re: Scaling concerns Andreas Kostyrka
• 06:19   Re: Scaling concerns Luke Lonergan
• 10:17   Re: File Systems Compared Bruno Wolff III
• 14:44   Re: Scaling concerns Bill Moran
• 20:34   Re: Scaling concerns tsuraan
• 20:59   Re: Scaling concerns tsuraan
• 23:53   Re: Scaling concerns Greg Smith

18 December 2006

• 03:37   Re: Scaling concerns tsuraan
• 03:59   Re: Scaling concerns Tom Lane
• 05:07   Optimizing timestamp queries? Inefficient Overlaps? Adam Rich
• 05:31   Re: Optimizing timestamp queries? Inefficient Overlaps? Tom Lane
• 08:26   transaction ID wrap limit Sabin Coanda
• 11:20   Re: New to PostgreSQL, performance considerations Ron
• 14:51   Re: transaction ID wrap limit Tom Lane
• 15:32   Query plan changing when queried data does not Harry Hehl
• 16:08   Re: Query plan changing when queried data does not Tom Lane
• 16:21   Re: opportunity to benchmark a quad core Xeon Jeff Frost
• 16:51   Re: Insertion to temp table deteriorating over time Steven Flatt
• 17:01   Re: Insertion to temp table deteriorating over time Tom Lane
• 20:18   Re: Advice on selecting good values for work_mem? Bill Moran
• 20:43   Re: Advice on selecting good values for work_mem? Bill Moran
• 21:34   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Simon Riggs
• 22:06   Re: Insertion to temp table deteriorating over time Steven Flatt

19 December 2006

• 03:43   Re: [HACKERS] EXPLAIN ANALYZE on 8.2 Tom Lane
• 07:09   Re: Insertion to temp table deteriorating over time Tom Lane
• 13:32   Inner join vs where-clause subquery Jeremy Haile
• 14:43   Re: Insertion to temp table deteriorating over time Steven Flatt
• 15:32   Re: Inner join vs where-clause subquery Richard Huxton
• 15:59   Re: Insertion to temp table deteriorating over time Tom Lane
• 16:35   Re: Inner join vs where-clause subquery Jeremy Haile
• 17:23   Re: Inner join vs where-clause subquery Richard Huxton
• 18:35   Re: Inner join vs where-clause subquery Jeremy Haile
• 19:02   Re: Inner join vs where-clause subquery Richard Huxton
• 19:18   Re: Inner join vs where-clause subquery Jeremy Haile
• 19:48   Re: Inner join vs where-clause subquery Jeremy Haile

20 December 2006

• 04:42   max_fsm_pages and check_points ALVARO ARCILA
• 06:26   GROUP BY vs DISTINCT Brian Herlihy
• 07:59   Re: max_fsm_pages and check_points Ragnar
• 10:00   Re: GROUP BY vs DISTINCT Steinar H. Gunderson
• 10:16   Re: GROUP BY vs DISTINCT Peter Childs
• 10:25   Question: Clustering & Load Balancing CARMODA
• 14:36   Re: GROUP BY vs DISTINCT Tom Lane
• 14:50   Re: Question: Clustering & Load Balancing Michal Taborsky - Internet Mall

22 December 2006

• 15:07   URGENT: Out of disk space pg_xlog Jeremy Haile
• 15:53   Re: URGENT: Out of disk space pg_xlog Jeremy Haile
• 15:54   Re: URGENT: Out of disk space pg_xlog Joshua D. Drake
• 16:03   Re: URGENT: Out of disk space pg_xlog Simon Riggs
• 16:24   Re: URGENT: Out of disk space pg_xlog Kevin Grittner
• 16:30   Re: URGENT: Out of disk space pg_xlog Jeremy Haile
• 16:37   Re: URGENT: Out of disk space pg_xlog Simon Riggs
• 16:40   Re: URGENT: Out of disk space pg_xlog Jeremy Haile
• 17:14   Re: URGENT: Out of disk space pg_xlog Tom Lane
• 17:37   Re: URGENT: Out of disk space pg_xlog Kevin Grittner
• 17:46   Re: URGENT: Out of disk space pg_xlog Tom Lane
• 17:47   Re: URGENT: Out of disk space pg_xlog ohp@pyrenet.fr
• 19:13   Re: URGENT: Out of disk space pg_xlog Tom Lane
• 19:26   Re: URGENT: Out of disk space pg_xlog Alvaro Herrera
• 19:29   Re: URGENT: Out of disk space pg_xlog Steinar H. Gunderson
• 21:16   Re: URGENT: Out of disk space pg_xlog Bruce Momjian

23 December 2006

• 13:00   Re: URGENT: Out of disk space pg_xlog ohp@pyrenet.fr
• 16:33   Re: URGENT: Out of disk space pg_xlog Jeremy Haile
• 17:13   Re: URGENT: Out of disk space pg_xlog Bruce Momjian

24 December 2006

• 18:21   Questions about planner methods Kevin Kempter
• 19:49   Re: [HACKERS] Questions about planner methods Martijn van Oosterhout

26 December 2006

• 21:30   Re: [NOVICE] Partitioning Kevin Hunter

27 December 2006

• 03:37   Re: [NOVICE] Partitioning Tom Lane

28 December 2006

• 01:54   Re: [GENERAL] Need Help Richard Broersma Jr
• 04:47   High update activity, PostgreSQL vs BigDBMS Guy Rouillier
• 08:06   Re: High update activity, PostgreSQL vs BigDBMS Shoaib Mir
• 11:38   Re: High update activity, PostgreSQL vs BigDBMS Dave Cramer
• 12:20   Re: Advice on selecting good values for work_mem? Simon Riggs
• 13:57   Re: High update activity, PostgreSQL vs BigDBMS Tom Lane

29 December 2006

• 00:58   Postgresql Configutation and overflow fabrix peñuelas
• 01:12   Re: Postgresql Configutation and overflow Adam Rich
• 02:35   Re: Postgresql Configutation and overflow Dave Cramer
• 11:54   Re: High update activity, PostgreSQL vs BigDBMS Ron
• 13:26   Re: High update activity, PostgreSQL vs BigDBMS Arnau
• 16:15   Backup/Restore too slow Sebastián Baioni
• 16:15   What you would consider as heavy traffic? oliver@obeattie.com
• 16:15   performance implications of binary placement Bob Dusek
• 16:15   Need Help JM
• 16:15   Postgresql Configutation and overflow Fabricio Peñuelas
• 16:35   Re: Backup/Restore too slow Rod Taylor
• 16:39   Re: What you would consider as heavy traffic? Rod Taylor
• 16:44   Re: Backup/Restore too slow Tom Lane
• 17:04   Re: Backup/Restore too slow Sebastián Baioni
• 17:35   Re: URGENT: Out of disk space pg_xlog Simon Riggs
• 20:25   Re: Backup/Restore too slow Russell Smith
• 21:08   Re: High update activity, PostgreSQL vs BigDBMS Alvaro Herrera
• 21:15   Re: High update activity, PostgreSQL vs BigDBMS Jeff Frost

30 December 2006

• 02:22   Re: High update activity, PostgreSQL vs BigDBMS Alex Turner

31 December 2006

• 06:26   Re: High update activity, PostgreSQL vs BigDBMS Guy Rouillier
• 11:02   Worse perfomance on 8.2.0 than on 7.4.14 Rolf Østvik
• 11:17   Re: Worse perfomance on 8.2.0 than on 7.4.14 Claus Guttesen
• 12:01   Re: Worse perfomance on 8.2.0 than on 7.4.14 Rolf Østvik
• 15:26   Re: Worse perfomance on 8.2.0 than on 7.4.14 Dave Cramer
• 15:45   Re: Worse perfomance on 8.2.0 than on 7.4.14 Dennis Bjorklund
• 16:11   Re: Worse perfomance on 8.2.0 than on 7.4.14 Tom Lane