Mailing lists [pgsql-performance]

1 November 2010

• 01:30   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Marti Raudsepp
• 05:03   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Mark Kirkwood
• 12:49   Insert performance with composite index Divakar Singh
• 12:56   Re: Insert performance with composite index Divakar Singh
• 13:01   Re: Insert performance with composite index Marti Raudsepp
• 13:05   Re: Insert performance with composite index Marti Raudsepp
• 13:58   Re: Insert performance with composite index Cédric Villemain
• 14:04   Re: Insert performance with composite index Andres Freund
• 14:14   Re: Insert performance with composite index Andres Freund
• 14:16   Re: Insert performance with composite index Divakar Singh
• 14:21   Re: Insert performance with composite index Andres Freund
• 14:28   Re: Insert performance with composite index Divakar Singh
• 14:34   Re: Insert performance with composite index Andres Freund

2 November 2010

• 02:50   A query become very slow after upgrade from 8.1.10 to 8.4.5 Yaocl
• 09:45   Re: Insert performance with composite index hubert depesz lubaczewski
• 11:05   Re: Insert performance with composite index Cédric Villemain
• 11:53   Re: Insert performance with composite index hubert depesz lubaczewski
• 12:51   Re: Insert performance with composite index Divakar Singh
• 20:32   Re: Insert performance with composite index Cédric Villemain
• 21:21   Test Mladen Gogala
• 21:32   Array interface Mladen Gogala
• 22:30   Re: A query become very slow after upgrade from 8.1.10 to 8.4.5 Tom Lane
• 22:41   Re: Array interface Conor Walsh

3 November 2010

• 01:47   Re: A query become very slow after upgrade from 8.1.10 to 8.4.5 Yaocl
• 14:57   Re: Array interface Mladen Gogala
• 15:51   Re: Test Robert Gravsjö
• 16:35   Bufer cache replacement LRU algorithm? Mladen Gogala
• 16:52   Re: Bufer cache replacement LRU algorithm? Kenneth Marshall
• 16:52   Simple (hopefully) throughput question? Nick Matheson
• 17:09   Re: Bufer cache replacement LRU algorithm? Kevin Grittner
• 17:10   Re: Simple (hopefully) throughput question? Heikki Linnakangas
• 17:23   Re: Simple (hopefully) throughput question? Marti Raudsepp
• 17:40   Re: Simple (hopefully) throughput question? Andy Colson

4 November 2010

• 09:12   Re: Simple (hopefully) throughput question? Pierre C
• 14:31   Re: Simple (hopefully) throughput question? Nick Matheson
• 14:35   Re: Simple (hopefully) throughput question? Nick Matheson
• 14:38   Re: Simple (hopefully) throughput question? Nick Matheson
• 14:42   Re: Simple (hopefully) throughput question? Nick Matheson
• 15:07   Re: Simple (hopefully) throughput question? Vitalii Tymchyshyn
• 15:09   Re: Simple (hopefully) throughput question? Nick Matheson
• 15:13   Re: Simple (hopefully) throughput question? Maciek Sakrejda
• 19:25   Re: Simple (hopefully) throughput question? Nick Matheson

5 November 2010

• 09:05   Re: Simple (hopefully) throughput question? Pierre C
• 10:59   Running PostgreSQL as fast as possible no matter the consequences A B
• 11:16   Re: Running PostgreSQL as fast as possible no matter the consequences Thom Brown
• 11:17   Re: Running PostgreSQL as fast as possible no matter the consequences Thom Brown
• 11:17   Re: Running PostgreSQL as fast as possible no matter the consequences Guillaume Cottenceau
• 11:23   Re: Running PostgreSQL as fast as possible no matter the consequences Szymon Guz
• 11:24   Re: Running PostgreSQL as fast as possible no matter the consequences A B
• 11:27   Re: Running PostgreSQL as fast as possible no matter the consequences Craig Ringer
• 11:32   Re: Running PostgreSQL as fast as possible no matter the consequences A B
• 11:36   Re: Running PostgreSQL as fast as possible no matter the consequences A B
• 11:37   Re: Running PostgreSQL as fast as possible no matter the consequences Marti Raudsepp
• 11:42   Re: Running PostgreSQL as fast as possible no matter the consequences Thom Brown
• 11:56   Re: Running PostgreSQL as fast as possible no matter the consequences Marti Raudsepp
• 12:06   Re: Running PostgreSQL as fast as possible no matter the consequences Guillaume Cottenceau
• 12:08   Re: Running PostgreSQL as fast as possible no matter the consequences Guillaume Cottenceau
• 12:48   Re: Running PostgreSQL as fast as possible no matter the consequences Jon Nelson
• 15:23   Re: Running PostgreSQL as fast as possible no matter the consequences Devrim GÜNDÜZ
• 16:24   Re: Running PostgreSQL as fast as possible no matter the consequences Chris Browne
• 16:26   Re: Running PostgreSQL as fast as possible no matter the consequences Mladen Gogala
• 17:35   Re: Simple (hopefully) throughput question? Robert Klemme
• 20:15   Major Linux performance regression; shouldn't we be worried about RHEL6? Josh Berkus
• 20:19   Re: Major Linux performance regression; shouldn't we be worried about RHEL6? Josh Berkus
• 20:27   Re: Major Linux performance regression; shouldn't we be worried about RHEL6? Scott Marlowe
• 20:33   Re: Major Linux performance regression; shouldn't we be worried about RHEL6? Josh Berkus
• 20:39   Re: Major Linux performance regression; shouldn't we be worried about RHEL6? Andres Freund
• 20:58   Re: Bufer cache replacement LRU algorithm? Greg Smith
• 21:00   Re: Major Linux performance regression; shouldn't we be worried about RHEL6? Scott Marlowe
• 21:10   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Greg Smith
• 21:22   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Marti Raudsepp
• 21:25   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Andres Freund
• 21:26   Re: Major Linux performance regression; shouldn't we be worried about RHEL6? Greg Smith
• 21:28   Re: Simple (hopefully) throughput question? Samuel Gendler
• 22:04   Re: Simple (hopefully) throughput question? Samuel Gendler
• 22:06   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Greg Smith
• 22:07   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Josh Berkus
• 22:11   Re: Major Linux performance regression; shouldn't we be worried about RHEL6? Josh Berkus
• 22:29   Re: Major Linux performance regression; shouldn't we be worried about RHEL6? Scott Carey
• 23:33   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Marti Raudsepp
• 23:39   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Pierre C

6 November 2010

• 00:27   postmaster consuming /lots/ of memory with hash aggregate. why? Jon Nelson
• 08:58   Re: postmaster consuming /lots/ of memory with hash aggregate. why? Pierre C
• 18:37   Re: postmaster consuming /lots/ of memory with hash aggregate. why? Jon Nelson

7 November 2010

• 00:21   Re: Running PostgreSQL as fast as possible no matter the consequences Craig Ringer
• 01:23   Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds Robert Haas
• 19:33   questions regarding shared_buffers behavior Mark Rostron
• 22:30   Re: questions regarding shared_buffers behavior Greg Smith
• 22:35   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Greg Smith
• 22:45   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Andres Freund
• 23:05   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Greg Smith
• 23:33   Re: questions regarding shared_buffers behavior Mark Rostron

8 November 2010

• 01:36   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Marti Raudsepp
• 02:04   Re: questions regarding shared_buffers behavior Cédric Villemain
• 08:13   Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds Francisco Reyes
• 13:24   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Marti Raudsepp
• 14:19   Help with bulk read performance Dan Schaffer
• 14:19   Array interface Mladen Gogala
• 14:19   Array interface Mladen Gogala
• 14:19   Re: Running PostgreSQL as fast as possible no matter the consequences Lello, Nick
• 14:19   Select * is very slow shaiju.ck
• 14:24   Re: Select * is very slow Pavel Stehule
• 14:31   Re: Select * is very slow Thom Brown
• 16:02   Re: Select * is very slow Kevin Grittner
• 16:09   Re: Select * is very slow Kevin Grittner
• 16:09   Re: Select * is very slow Thomas Kellerer
• 16:16   Re: Select * is very slow Kevin Grittner
• 17:12   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Scott Carey
• 17:40   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Tom Lane
• 17:42   Re: Select * is very slow Pierre C
• 19:35   Re: Select * is very slow Justin Pitts
• 19:35   Re: Running PostgreSQL as fast as possible no matter the consequences Dimitri Fontaine
• 19:35   Re: Running PostgreSQL as fast as possible no matter the consequences Klaus Ita
• 21:13   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Greg Smith
• 21:32   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Andres Freund

9 November 2010

• 09:47   out of memory problem Till Kirchner
• 14:22   Re: out of memory problem Tom Lane
• 15:02   Re: out of memory problem Bob Lunney
• 20:19   anti-join chosen even when slower than old plan Kevin Grittner
• 20:26   Huge overestimation in rows expected results in bad plan bricklen
• 21:51   Re: Huge overestimation in rows expected results in bad plan Andy Colson
• 21:59   Re: Huge overestimation in rows expected results in bad plan bricklen
• 22:07   Re: anti-join chosen even when slower than old plan Kevin Grittner
• 22:17   Re: anti-join chosen even when slower than old plan Tom Lane
• 22:25   Re: anti-join chosen even when slower than old plan Kevin Grittner
• 22:29   Re: Huge overestimation in rows expected results in bad plan Tom Lane
• 22:39   Re: Huge overestimation in rows expected results in bad plan bricklen
• 22:55   Re: Huge overestimation in rows expected results in bad plan Tom Lane
• 23:08   Re: anti-join chosen even when slower than old plan Tom Lane
• 23:10   Re: Huge overestimation in rows expected results in bad plan bricklen

10 November 2010

• 04:37   Re: anti-join chosen even when slower than old plan Grzegorz Jaśkiewicz
• 08:10   Re: Array interface Mark Kirkwood
• 08:42   Re: Array interface Mark Kirkwood
• 10:36   Why dose the planner select one bad scan plan. 静安寺
• 11:38   Re: anti-join chosen even when slower than old plan Kevin Grittner
• 11:54   Re: Why dose the planner select one bad scan plan. tv@fuzzy.cz
• 14:21   Re: anti-join chosen even when slower than old plan Kevin Grittner
• 14:36   Re: anti-join chosen even when slower than old plan Tom Lane
• 21:08   Re: anti-join chosen even when slower than old plan Robert Haas
• 21:43   Re: anti-join chosen even when slower than old plan Kevin Grittner
• 22:07   Re: anti-join chosen even when slower than old plan Tom Lane

11 November 2010

• 02:47   Re: anti-join chosen even when slower than old plan Robert Haas
• 04:14   Re: anti-join chosen even when slower than old plan Mladen Gogala
• 07:01   Re: anti-join chosen even when slower than old plan Віталій Тимчишин
• 07:43   Re: Why dose the planner select one bad scan plan. tv@fuzzy.cz
• 12:41   CREATE INDEX as bottleneck Marc Mamin
• 12:51   Re: anti-join chosen even when slower than old plan Kenneth Marshall
• 12:58   Re: CREATE INDEX as bottleneck Kenneth Marshall
• 13:16   Re: anti-join chosen even when slower than old plan Mladen Gogala
• 13:28   Re: anti-join chosen even when slower than old plan Kenneth Marshall
• 14:00   Re: anti-join chosen even when slower than old plan Kevin Grittner
• 16:06   Re: anti-join chosen even when slower than old plan Bob Lunney
• 16:13   Re: anti-join chosen even when slower than old plan Mladen Gogala
• 16:46   Re: anti-join chosen even when slower than old plan Tom Lane
• 16:55   Re: anti-join chosen even when slower than old plan Craig James
• 16:58   Re: anti-join chosen even when slower than old plan Robert Haas
• 17:11   Re: anti-join chosen even when slower than old plan Mladen Gogala
• 17:23   Re: anti-join chosen even when slower than old plan Tom Lane
• 17:55   Re: CREATE INDEX as bottleneck Alex Hunsaker
• 17:58   Re: anti-join chosen even when slower than old plan Tom Lane
• 18:02   Re: anti-join chosen even when slower than old plan Robert Haas
• 18:05   Re: anti-join chosen even when slower than old plan Robert Haas
• 18:16   Re: anti-join chosen even when slower than old plan Kevin Grittner
• 18:17   Re: anti-join chosen even when slower than old plan Tom Lane
• 18:23   Re: anti-join chosen even when slower than old plan Kevin Grittner
• 18:36   Re: anti-join chosen even when slower than old plan Tom Lane
• 18:41   Re: anti-join chosen even when slower than old plan Tom Lane
• 18:48   Re: anti-join chosen even when slower than old plan Kevin Grittner
• 18:50   Re: anti-join chosen even when slower than old plan Kevin Grittner
• 19:05   Re: CREATE INDEX as bottleneck Marc Mamin
• 19:11   Re: anti-join chosen even when slower than old plan Andres Freund
• 19:19   Re: anti-join chosen even when slower than old plan Jon Nelson
• 19:29   Re: anti-join chosen even when slower than old plan Robert Haas
• 19:56   Re: anti-join chosen even when slower than old plan 
• 20:28   Re: anti-join chosen even when slower than old plan Kenneth Marshall
• 20:53   equivalent queries lead to different query plans for self-joins with group by? Ben
• 21:37   Re: equivalent queries lead to different query plans for self-joins with group by? Tom Lane
• 22:56   Re: equivalent queries lead to different query plans for self-joins with group by? Ben

12 November 2010

• 01:31   Re: postmaster consuming /lots/ of memory with hash aggregate. why? Jon Nelson
• 03:26   Re: postmaster consuming /lots/ of memory with hash aggregate. why? Pavel Stehule
• 03:33   Re: postmaster consuming /lots/ of memory with hash aggregate. why? Jon Nelson
• 03:39   Re: postmaster consuming /lots/ of memory with hash aggregate. why? Pavel Stehule
• 08:08   Re: anti-join chosen even when slower than old plan Cédric Villemain
• 08:15   Re: anti-join chosen even when slower than old plan Cédric Villemain
• 09:10   Re: anti-join chosen even when slower than old plan Vitalii Tymchyshyn
• 10:00   Re: anti-join chosen even when slower than old plan Cédric Villemain
• 11:06   Re: anti-join chosen even when slower than old plan Vitalii Tymchyshyn
• 11:41   Re: anti-join chosen even when slower than old plan Cédric Villemain
• 12:47   MVCC performance issue Kyriacos Kyriacou
• 12:52   Re: MVCC performance issue Kenneth Marshall
• 12:55   Re: MVCC performance issue Thom Brown
• 14:33   Re: postmaster consuming /lots/ of memory with hash aggregate. why? Jon Nelson
• 14:34   Re: MVCC performance issue bricklen
• 14:37   Re: MVCC performance issue Kenneth Marshall
• 14:53   Re: MVCC performance issue Vitalii Tymchyshyn
• 15:13   Re: postmaster consuming /lots/ of memory with hash aggregate. why? Pavel Stehule
• 15:14   Re: MVCC performance issue Kyriacos Kyriacou
• 15:18   Re: MVCC performance issue Kyriacos Kyriacou
• 15:24   Re: MVCC performance issue Andy Colson
• 15:27   Re: MVCC performance issue Kenneth Marshall
• 15:30   Re: MVCC performance issue Thom Brown
• 15:41   Re: MVCC performance issue Ben Chobot
• 15:41   Re: MVCC performance issue Tom Lane
• 15:42   Re: anti-join chosen even when slower than old plan Robert Haas
• 15:43   Re: MVCC performance issue Kyriacos Kyriacou
• 15:46   Re: anti-join chosen even when slower than old plan Tom Lane
• 16:13   Re: MVCC performance issue Kyriacos Kyriacou
• 16:27   Re: MVCC performance issue Scott Marlowe
• 16:40   Re: MVCC performance issue Scott Marlowe
• 16:48   Re: MVCC performance issue Scott Marlowe
• 17:12   Re: MVCC performance issue Scott Carey
• 17:18   Re: MVCC performance issue Scott Carey
• 17:57   Re: anti-join chosen even when slower than old plan Robert Haas
• 20:07   Re: questions regarding shared_buffers behavior Robert Haas
• 21:07   Re: Why dose the planner select one bad scan plan. 静安寺
• 21:07   MVCC performance issue Kyriacos Kyriacou
• 21:07   autovacuum blocks the operations of other manual vacuum kuopo

13 November 2010

• 02:32   Re: temporary tables, indexes, and query plans Jon Nelson
• 04:44   Re: anti-join chosen even when slower than old plan Cédric Villemain
• 04:54   Re: MVCC performance issue Craig Ringer
• 06:05   Re: MVCC performance issue Rich
• 08:32   Re: anti-join chosen even when slower than old plan Marc Mamin
• 12:53   do temporary tables have hint bits? Jon Nelson
• 13:57   Re: do temporary tables have hint bits? Tom Lane
• 14:41   Re: temporary tables, indexes, and query plans Tom Lane
• 15:15   Re: anti-join chosen even when slower than old plan bricklen
• 15:15   Re: temporary tables, indexes, and query plans Jon Nelson
• 15:42   Re: temporary tables, indexes, and query plans Tom Lane
• 16:38   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Marti Raudsepp
• 17:02   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Tom Lane
• 17:38   Re: MVCC performance issue Mladen Gogala
• 23:11   Re: MVCC performance issue Craig Ringer
• 23:20   Re: anti-join chosen even when slower than old plan Robert Haas
• 23:46   Re: temporary tables, indexes, and query plans Robert Haas
• 23:54   Re: temporary tables, indexes, and query plans Tom Lane

14 November 2010

• 01:55   Re: temporary tables, indexes, and query plans Robert Haas
• 07:31   Re: MVCC performance issue Marti Raudsepp
• 07:46   Re: MVCC performance issue Marti Raudsepp
• 08:47   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Marti Raudsepp
• 14:55   Re: temporary tables, indexes, and query plans Tom Lane
• 22:01   Re: Why dose the planner select one bad scan plan. Robert Haas
• 23:33   Re: MVCC performance issue Mladen Gogala

15 November 2010

• 07:42   Difference between explain analyze and real execution time Artur Zając
• 14:06   Re: Running PostgreSQL as fast as possible no matter the consequences Robert Haas
• 14:13   Re: Difference between explain analyze and real execution time Tom Lane
• 14:24   Re: Difference between explain analyze and real execution time Artur Zając
• 14:25   Re: Difference between explain analyze and real execution time Tobias Brox
• 18:27   Re: Running PostgreSQL as fast as possible no matter the consequences Andy Colson
• 18:36   Re: Running PostgreSQL as fast as possible no matter the consequences Robert Haas
• 18:39   Re: Difference between explain analyze and real execution time Robert Haas
• 19:44   Re: Difference between explain analyze and real execution time Artur Zając
• 20:04   Re: Difference between explain analyze and real execution time Tom Lane
• 20:30   Re: Difference between explain analyze and real execution time Artur Zając

16 November 2010

• 05:54    Humair Mohammed
• 06:02   Re: Jayadevan M
• 06:08   Re: Mark Kirkwood
• 06:12   Re: Pavel Stehule
• 09:57   best db schema for time series data? Louis-David Mitterrand
• 10:04   Re: best db schema for time series data? Pavel Stehule
• 10:07   Re: best db schema for time series data? Louis-David Mitterrand
• 10:12   Re: best db schema for time series data? Pavel Stehule
• 10:24   Re: best db schema for time series data? Arjen van der Meijden
• 10:28   Re: best db schema for time series data? Louis-David Mitterrand
• 10:57   Re: best db schema for time series data? Jayadevan M
• 14:27   Re: autovacuum blocks the operations of other manual vacuum Alvaro Herrera
• 15:28   Re: best db schema for time series data? Harald Fuchs
• 15:54   Re: best db schema for time series data? Chris Browne
• 19:39   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Greg Smith
• 22:10   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Robert Haas
• 22:25   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Josh Berkus
• 22:31   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Tom Lane
• 23:01   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Marti Raudsepp
• 23:05   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Mladen Gogala
• 23:30   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Andres Freund
• 23:51   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Tom Lane

17 November 2010

• 00:01   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Andres Freund
• 00:04   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Tom Lane
• 00:12   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Andres Freund
• 00:18   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Josh Berkus
• 00:18   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Tom Lane
• 00:22   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Tom Lane
• 02:07   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Robert Haas
• 03:48   Re: Query Performance SQL Server vs. Postgresql Pavel Stehule
• 14:01   How to achieve sustained disk performance of 1.25 GB write for 5 mins Eric Comeau
• 14:25   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins J. Roeleveld
• 14:29   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins Digimer
• 15:01   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins Lutz Steinborn
• 15:13   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins Ivan Voras
• 16:28   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins Merlin Moncure
• 16:38   Anyone seen this kind of lock pileup? Josh Berkus
• 17:46   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins Scott Carey
• 17:57   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins Scott Carey
• 18:25   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Scott Carey
• 19:17   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Scott Carey
• 19:47   Re: Query Performance SQL Server vs. Postgresql Tomas Vondra
• 20:25   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Greg Smith
• 20:44   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Jon Nelson
• 20:52   Re: Query Performance SQL Server vs. Postgresql Rich
• 20:59   Re: Anyone seen this kind of lock pileup? Tom Lane
• 21:03   Re: Anyone seen this kind of lock pileup? Josh Berkus
• 21:06   Re: Query Performance SQL Server vs. Postgresql Mladen Gogala
• 21:48   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Greg Smith
• 21:54   Re: Anyone seen this kind of lock pileup? Ivan Voras
• 22:03   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins Eric Comeau
• 22:03   Re: Query Performance SQL Server vs. Postgresql Humair Mohammed
• 22:03   Re: Query Performance SQL Server vs. Postgresql Humair Mohammed
• 22:18   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Scott Carey
• 22:21   Re: Query Performance SQL Server vs. Postgresql Tom Lane
• 22:28   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins Ivan Voras
• 22:42   Re: Anyone seen this kind of lock pileup? Josh Berkus
• 22:43   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins Greg Smith
• 22:56   Re: Anyone seen this kind of lock pileup? Tom Lane

18 November 2010

• 05:15   Re: Query Performance SQL Server vs. Postgresql Pavel Stehule
• 09:10   executor stats / page reclaims Uwe Bartels
• 10:09   Low disk performance? Martin Chlupac
• 12:33   Re: Low disk performance? tv@fuzzy.cz
• 20:00   Re: Query Performance SQL Server vs. Postgresql Kevin Grittner
• 21:48   Re: autovacuum blocks the operations of other manual vacuum kuopo

19 November 2010

• 08:46   Re: best db schema for time series data? Louis-David Mitterrand
• 08:50   Re: best db schema for time series data? Louis-David Mitterrand
• 13:52   Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Jignesh Shah
• 16:25   Re: best db schema for time series data? Chris Browne
• 23:16   Re: best db schema for time series data? Robert Klemme

20 November 2010

• 00:49   Re: autovacuum blocks the operations of other manual vacuum Alvaro Herrera
• 03:43   Re: autovacuum blocks the operations of other manual vacuum tv@fuzzy.cz
• 09:16   Re: How to achieve sustained disk performance of 1.25 GB write for 5 mins Dimitri
• 15:28   Re: best db schema for time series data? Bob Lunney

21 November 2010

• 05:21   Re: Query Performance SQL Server vs. Postgresql Pavel Stehule
• 10:25   Should changing offset in LIMIT change query plan (at all/so early)? goran
• 10:25   Re: Query Performance SQL Server vs. Postgresql Humair Mohammed
• 10:25   Re: Query Performance SQL Server vs. Postgresql Humair Mohammed
• 10:39   Re: Query Performance SQL Server vs. Postgresql Pavel Stehule
• 13:34   Re: Query Performance SQL Server vs. Postgresql tv@fuzzy.cz
• 14:14   Re: Query Performance SQL Server vs. Postgresql Pavel Stehule
• 14:23   Re: Query Performance SQL Server vs. Postgresql Kevin Grittner
• 14:36   Re: Query Performance SQL Server vs. Postgresql tv@fuzzy.cz
• 14:42   Re: Query Performance SQL Server vs. Postgresql tv@fuzzy.cz
• 14:44   Re: Should changing offset in LIMIT change query plan (at all/so early)? Kevin Grittner
• 14:57   Re: Query Performance SQL Server vs. Postgresql tv@fuzzy.cz
• 15:25   Re: autovacuum blocks the operations of other manual vacuum Alvaro Herrera
• 16:16   Re: Query Performance SQL Server vs. Postgresql Tom Lane
• 17:56   Re: Query Performance SQL Server vs. Postgresql Robert Haas
• 23:16   Performance under contention Ivan Voras

22 November 2010

• 00:47   Re: Performance under contention Kevin Grittner
• 01:19   Re: Performance under contention Ivan Voras
• 05:55   Re: Performance under contention Jignesh Shah
• 07:37   Re: autovacuum blocks the operations of other manual vacuum kuopo
• 07:37   Re: Query Performance SQL Server vs. Postgresql Humair Mohammed
• 07:37   Re: autovacuum blocks the operations of other manual vacuum kuopo
• 07:37   Re: Query Performance SQL Server vs. Postgresql Humair Mohammed
• 07:59   Slow SELECT on small table Martin Boese
• 09:02   Re: Performance under contention Omar Kilani
• 10:00   Re: Query Performance SQL Server vs. Postgresql tv@fuzzy.cz
• 10:02   Re: Query Performance SQL Server vs. Postgresql Samuel Gendler
• 11:22   Re: Query Performance SQL Server vs. Postgresql tv@fuzzy.cz
• 14:12   Re: Slow SELECT on small table Kevin Grittner
• 14:26   Re: Performance under contention Kevin Grittner
• 14:38   Re: Performance under contention Ivan Voras
• 16:47   Re: Performance under contention Kevin Grittner

23 November 2010

• 10:15   Re: Query Performance SQL Server vs. Postgresql Humair Mohammed
• 13:20   Re: Query Performance SQL Server vs. Postgresql Merlin Moncure
• 23:11   Re: Performance under contention Craig Ringer

24 November 2010

• 00:10   Re: Performance under contention Ivan Voras
• 02:11   Re: postmaster consuming /lots/ of memory with hash aggregate. why? Robert Haas
• 07:58   Re: Performance under contention Vitalii Tymchyshyn
• 13:46   Re: Performance under contention Kevin Grittner
• 13:48   Optimizing query pasman pasmański
• 18:02   problem with from_collapse_limit and joined views Markus Schulz

25 November 2010

• 10:37   Which gives good performance? separate database vs separate schema Divakar Singh
• 11:02   Re: Which gives good performance? separate database vs separate schema tv@fuzzy.cz
• 11:03   Re: Which gives good performance? separate database vs separate schema Thomas Kellerer
• 11:09   Re: Which gives good performance? separate database vs separate schema tv@fuzzy.cz
• 11:10   Re: Which gives good performance? separate database vs separate schema Andres Freund
• 11:25   Re: Which gives good performance? separate database vs separate schema tv@fuzzy.cz
• 11:39   Re: Performance under contention Ivan Voras
• 13:53   Re: Which gives good performance? separate database vs separate schema Divakar Singh
• 14:46   Re: Which gives good performance? separate database vs separate schema tv@fuzzy.cz

26 November 2010

• 01:00   Re: Performance under contention Greg Smith
• 01:09   Re: Performance under contention Ivan Voras
• 08:53   Re: Optimizing query Pierre C
• 10:38   Re: Which gives good performance? separate database vs separate schema Robert Klemme
• 13:22   Update problem on large table felix
• 14:06   Re: Optimizing query pasman pasmański
• 15:00   Re: Update problem on large table bricklen
• 15:39   Re: CPUs for new databases Christian Elmerot @ One.com
• 16:46   Re: CPUs for new databases Kevin Grittner
• 21:30   Re: CPUs for new databases Greg Smith

28 November 2010

• 11:02   Simple database, multiple instances? Mario Splivalo
• 11:12   SELECT INTO large FKyed table is slow Mario Splivalo
• 18:03   Re: SELECT INTO large FKyed table is slow Pierre C
• 18:09   Re: SELECT INTO large FKyed table is slow Mario Splivalo
• 21:17   Re: SELECT INTO large FKyed table is slow Pierre C

29 November 2010

• 03:39   Hi- Sleeptime reduction aaliya zarrin
• 04:10   Re: Hi- Sleeptime reduction Kevin Grittner
• 06:00   Full Text index is not using during OR operation AI Rumman
• 06:11   Re: SELECT INTO large FKyed table is slow Mark Kirkwood
• 11:24   Re: SELECT INTO large FKyed table is slow Mario Splivalo
• 11:30   Re: SELECT INTO large FKyed table is slow Mario Splivalo
• 11:38   Re: Full Text index is not using during OR operation Oleg Bartunov
• 13:03   Re: Full Text index is not using during OR operation AI Rumman
• 13:32   Re: Full Text index is not using during OR operation Tobias Brox
• 14:03   Re: Full Text index is not using during OR operation Oleg Bartunov
• 15:48   Re: SELECT INTO large FKyed table is slow Pierre C
• 15:53   Re: SELECT INTO large FKyed table is slow Pierre C
• 23:22   Re: MVCC performance issue Robert Haas

30 November 2010

• 10:43   tidscan not work ? Pg 8.4.5 + WinXP pasman pasmański
• 10:46   Re: Simple database, multiple instances? Dimitri Fontaine
• 11:31   Re: Simple database, multiple instances? Mario Splivalo
• 15:07   postgresql statements are waiting bakkiya
• 15:26   Re: SELECT INTO large FKyed table is slow Mladen Gogala
• 15:44   Re: tidscan not work ? Pg 8.4.5 + WinXP Kevin Grittner
• 15:50   Re: tidscan not work ? Pg 8.4.5 + WinXP Tom Lane
• 15:53   Re: postgresql statements are waiting Kevin Grittner
• 15:55   Re: postgresql statements are waiting Scott Marlowe
• 16:16   Re: Simple database, multiple instances? Maciek Sakrejda
• 17:19   Question about subselect/IN performance T.H.
• 21:35   Re: Simple database, multiple instances? Pierre C
• 21:55   Re: Question about subselect/IN performance Kevin Grittner
• 22:22   Re: SELECT INTO large FKyed table is slow Mario Splivalo
• 22:24   Re: SELECT INTO large FKyed table is slow Mario Splivalo
• 22:42   Re: Question about subselect/IN performance T.H.
• 22:50   Re: SELECT INTO large FKyed table is slow Mark Kirkwood
• 23:00   Re: SELECT INTO large FKyed table is slow Mario Splivalo
• 23:51   Re: SELECT INTO large FKyed table is slow Pierre C