Mailing lists [pgsql-performance]

1 July 2012

• 04:19   Re: MemSQL the "world's fastest database"? Greg Smith
• 04:37   Re: SSD, Postgres and safe write cache Greg Smith
• 05:00   Re: MemSQL the "world's fastest database"? Scott Marlowe

3 July 2012

• 09:30   static virtual columns as result? PV
• 13:50   Re: static virtual columns as result? Kevin Grittner
• 15:44   Re: static virtual columns as result? PV
• 17:16   Re: Drop statistics? Bruce Momjian
• 21:46   Re: MemSQL the "world's fastest database"? Gregg Jaskiewicz
• 23:08   Introducing the TPC-V benchmark, and its relationship to PostgreSQL Reza Taheri
• 23:13   The need for clustered indexes to boost TPC-V performance Reza Taheri

4 July 2012

• 05:19   Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Craig Ringer
• 05:44   Re: The need for clustered indexes to boost TPC-V performance Craig Ringer
• 07:58   Re: The need for clustered indexes to boost TPC-V performance Thomas Kellerer
• 08:32   Re: The need for clustered indexes to boost TPC-V performance Craig Ringer
• 10:36   Re: static virtual columns as result? PV
• 13:40   Re: The need for clustered indexes to boost TPC-V performance Daniel Farina
• 14:26   Re: The need for clustered indexes to boost TPC-V performance Claudio Freire
• 18:24   Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Reza Taheri
• 22:35   Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Mark Kirkwood

5 July 2012

• 05:54   Re: Drop statistics? David Kerr
• 12:30   Re: The need for clustered indexes to boost TPC-V performance Robert Klemme
• 19:10   Re: The need for clustered indexes to boost TPC-V performance Reza Taheri
• 19:13   Re: The need for clustered indexes to boost TPC-V performance Reza Taheri
• 19:46   Re: The need for clustered indexes to boost TPC-V performance Samuel Gendler
• 20:38   Re: The need for clustered indexes to boost TPC-V performance Reza Taheri
• 20:52   Re: The need for clustered indexes to boost TPC-V performance Samuel Gendler

6 July 2012

• 00:41   Re: The need for clustered indexes to boost TPC-V performance Andy Colson
• 00:46   Re: The need for clustered indexes to boost TPC-V performance Craig Ringer
• 00:52   SSDs again, LSI Warpdrive 2 anyone? Mark Kirkwood
• 00:58   Re: The need for clustered indexes to boost TPC-V performance Craig Ringer
• 01:09   Re: The need for clustered indexes to boost TPC-V performance Reza Taheri
• 01:09   Re: The need for clustered indexes to boost TPC-V performance Craig Ringer
• 01:25   Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Greg Smith
• 01:42   Re: The need for clustered indexes to boost TPC-V performance Greg Smith
• 01:46   Re: MemSQL the "world's fastest database"? Greg Smith
• 02:12   What would effect planning time? David Kerr
• 03:08   Re: The need for clustered indexes to boost TPC-V performance Craig Ringer
• 03:22   Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Reza Taheri
• 03:33   Re: The need for clustered indexes to boost TPC-V performance Reza Taheri
• 03:41   Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Craig Ringer
• 03:57   The overall experience of TPC-V benchmark team with PostgreSQL Reza Taheri
• 04:03   Re: Introducing the TPC-V benchmark, and its relationship to PostgreSQL Reza Taheri
• 04:09   Re: SSDs again, LSI Warpdrive 2 anyone? Mark Kirkwood
• 04:19   Re: The need for clustered indexes to boost TPC-V performance Reza Taheri
• 06:10   select operations that generate disk writes CSS
• 06:21   Re: select operations that generate disk writes Pavel Stehule
• 06:52   Re: select operations that generate disk writes Craig Ringer
• 09:39   PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Stanislaw Pankevich
• 09:39   Paged Query Hermann Matthes
• 09:39   how could select id=xx so slow? Yan Chunlu
• 09:47   Re: how could select id=xx so slow? Daniel Farina
• 11:16   Re: how could select id=xx so slow? Craig Ringer
• 11:29   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Craig Ringer
• 11:35   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Craig Ringer
• 11:39   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Daniel Farina
• 13:11   Re: how could select id=xx so slow? Albe Laurenz
• 13:18   Re: Paged Query Віталій Тимчишин
• 13:19   Re: Paged Query Albe Laurenz
• 13:35   Re: Paged Query Greg Spiegelberg
• 13:39   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Craig Ringer
• 13:39   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Albe Laurenz
• 13:44   Re: Paged Query Misa Simic
• 14:14   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Andres Freund
• 14:22   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Craig Ringer
• 14:46   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Albe Laurenz
• 15:16   Create tables performance Sylvain CAILLET
• 15:30   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Marc Mamin
• 15:57   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Jeff Janes
• 16:07   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Steve Crawford
• 17:22   Re: Create tables performance Jeff Janes
• 18:12   Re: Create tables performance Richard Huxton
• 18:32   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Chris Hanks

7 July 2012

• 02:28   Re: Create tables performance Craig Ringer
• 22:35   Terrible plan for join to nested union Nate Allan

8 July 2012

• 00:08   Re: Terrible plan for join to nested union Tom Lane
• 05:50   Re: Terrible plan for join to nested union Nate Allan
• 06:04   Re: Terrible plan for join to nested union Pavel Stehule
• 09:56   Re: Terrible plan for join to nested union Nate Allan
• 15:56   Re: Terrible plan for join to nested union Tom Lane

9 July 2012

• 04:02   Re: Terrible plan for join to nested union Nate Allan
• 05:50   Re: Terrible plan for join to nested union Tom Lane
• 06:21   Re: Terrible plan for join to nested union Nate Allan
• 06:50   Re: Create tables performance Sylvain CAILLET
• 11:55   Re: Paged Query Gregg Jaskiewicz
• 12:03   Re: Paged Query Craig Ringer
• 12:27   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Stanislaw Pankevich
• 12:27   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Stanislaw Pankevich
• 12:27   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Stanislaw Pankevich
• 12:27   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Stanislaw Pankevich
• 12:27   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Stanislaw Pankevich
• 12:27   Re: how could select id=xx so slow? Yan Chunlu
• 12:28   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Stanislaw Pankevich
• 13:22   Re: Paged Query Shaun Thomas
• 14:16   Re: Paged Query Craig James
• 14:33   Re: Paged Query Greg Spiegelberg
• 17:03   Re: Create tables performance Jeff Janes
• 17:41   Re: Paged Query Misa Simic
• 17:46   Re: Paged Query Andrew Dunstan
• 18:13   Re: Paged Query Gurjeet Singh
• 22:24   Re: Paged Query Misa Simic
• 23:48   Re: Paged Query Craig Ringer
• 23:50   Re: Paged Query Craig Ringer

10 July 2012

• 00:34   Re: Paged Query Jeff Janes
• 01:25   Re: how could select id=xx so slow? Craig Ringer
• 02:46   Re: how could select id=xx so slow? Craig Ringer
• 05:24   Re: Paged Query Misa Simic
• 05:39   Massive I/O spikes during checkpoint David Kerr
• 05:52   Re: Massive I/O spikes during checkpoint Maxim Boguk
• 05:53   Re: Massive I/O spikes during checkpoint Jeff Janes
• 05:59   Re: Massive I/O spikes during checkpoint David Kerr
• 06:03   Re: Massive I/O spikes during checkpoint David Kerr
• 06:14   Re: Massive I/O spikes during checkpoint Maxim Boguk
• 06:18   Re: Massive I/O spikes during checkpoint David Kerr
• 06:28   Re: Create tables performance Sylvain CAILLET
• 08:36   Custom function in where clause Pena Kupen
• 08:45   Re: Custom function in where clause Maxim Boguk
• 08:45   Re: Custom function in where clause Brendan Jurd
• 09:30   Re: Custom function in where clause Pena Kupen
• 10:20   Fw: Re: Custom function in where clause Pena Kupen
• 12:44   Re: Massive I/O spikes during checkpoint Andres Freund
• 13:36   Re: Massive I/O spikes during checkpoint Jeff Janes
• 13:41   Re: Massive I/O spikes during checkpoint Andres Freund
• 19:06   Re: The need for clustered indexes to boost TPC-V performance Merlin Moncure
• 19:35   Re: The need for clustered indexes to boost TPC-V performance Reza Taheri

11 July 2012

• 00:37   DELETE vs TRUNCATE explanation Craig Ringer
• 05:23   Re: DELETE vs TRUNCATE explanation Daniel Farina
• 06:25   Re: how could select id=xx so slow? Yan Chunlu
• 08:15   Re: Paged Query Віталій Тимчишин
• 08:23   Re: Paged Query Віталій Тимчишин
• 08:24   Re: how could select id=xx so slow? Albe Laurenz
• 11:41   Re: how could select id=xx so slow? Yan Chunlu
• 12:01   Re: how could select id=xx so slow? Ants Aasma
• 14:06   Re: DELETE vs TRUNCATE explanation Tom Lane
• 14:20   Re: DELETE vs TRUNCATE explanation ktm@rice.edu
• 16:36   Re: how could select id=xx so slow? Yan Chunlu
• 17:27   Re: moving tables Midge Brown
• 18:10   Re: DELETE vs TRUNCATE explanation Matthew Woodcraft
• 20:19   Re: DELETE vs TRUNCATE explanation Craig James
• 20:47   Re: DELETE vs TRUNCATE explanation Shaun Thomas
• 21:05   Re: DELETE vs TRUNCATE explanation Andrew Dunstan
• 21:32   Re: DELETE vs TRUNCATE explanation Mark Thornton
• 22:10   Re: DELETE vs TRUNCATE explanation Craig James
• 22:52   Re: DELETE vs TRUNCATE explanation Daniel Farina

12 July 2012

• 00:18   Re: how could select id=xx so slow? Craig Ringer
• 00:47   Re: how could select id=xx so slow? Yan Chunlu
• 01:07   Re: how could select id=xx so slow? Maciek Sakrejda
• 01:24   Re: DELETE vs TRUNCATE explanation Craig Ringer
• 01:26   Re: DELETE vs TRUNCATE explanation Craig Ringer
• 01:42   Re: DELETE vs TRUNCATE explanation Craig Ringer
• 02:20   Re: how could select id=xx so slow? Craig Ringer
• 05:10   Re: how could select id=xx so slow? Yan Chunlu
• 06:13   Re: DELETE vs TRUNCATE explanation Daniel Farina
• 06:56   Re: how could select id=xx so slow? Craig Ringer
• 07:46   Re: DELETE vs TRUNCATE explanation Craig Ringer
• 12:48   Re: how could select id=xx so slow? Yan Chunlu
• 14:39   Re: how could select id=xx so slow? Craig Ringer
• 16:08   Re: how could select id=xx so slow? Ants Aasma
• 18:53   Re: how could select id=xx so slow? Jeff Janes
• 19:15   Re: DELETE vs TRUNCATE explanation Jeff Janes
• 23:21   Re: DELETE vs TRUNCATE explanation Harold A. Giménez

13 July 2012

• 01:01   Re: DELETE vs TRUNCATE explanation Jeff Janes
• 04:02   Re: how could select id=xx so slow? Yan Chunlu
• 06:51   slow prepare, lots of semop calls. David Kerr
• 15:31   Re: SSDs again, LSI Warpdrive 2 anyone? jamonb
• 15:31   Re: how could select id=xx so slow? Yan Chunlu
• 15:31   Re: how could select id=xx so slow? Yan Chunlu
• 15:31   Any tool/script available which can be used to measure scalability of an application's database. Sreejith Balakrishnan
• 15:31   query overhead Andy Halsall
• 15:31   PostgreSQL index issue codevally
• 15:32   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Stanislaw Pankevich
• 15:32   Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material) Eoghan Murray
• 15:53   Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material) Claudio Freire
• 16:15   Re: query overhead Tom Lane
• 16:25   Is there a tool available to perform Data Model review, from a performance perspective? B Sreejith
• 16:40   Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material) Claudio Freire
• 17:41   Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material) Tom Lane
• 18:37   Re: Any tool/script available which can be used to measure scalability of an application's database. Sergey Konoplev
• 18:57   Re: Poor performance problem with Materialize, 8.4 -> 9.1 (enable_material) Claudio Freire
• 20:07   Re: Any tool/script available which can be used to measure scalability of an application's database. Robert Klemme

14 July 2012

• 01:21   Re: Any tool/script available which can be used to measure scalability of an application's database. B Sreejith
• 01:26   Re: Any tool/script available which can be used to measure scalability of an application's database. B Sreejith
• 03:28   Re: query overhead Craig Ringer
• 03:35   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Craig Ringer
• 05:06   Re: Any tool/script available which can be used to measure scalability of an application's database. Craig Ringer
• 08:49   Re: Any tool/script available which can be used to measure scalability of an application's database. Craig Ringer
• 09:11   Re: Any tool/script available which can be used to measure scalability of an application's database. John Jones
• 09:50   Re: Any tool/script available which can be used to measure scalability of an application's database. B Sreejith
• 12:18   Re: Any tool/script available which can be used to measure scalability of an application's database. Robert Klemme
• 12:50   Re: Any tool/script available which can be used to measure scalability of an application's database. Sergey Konoplev
• 15:11   Re: Any tool/script available which can be used to measure scalability of an application's database. Craig Ringer

16 July 2012

• 01:55   Proposed change for 9.3(?): Require full restart to change fsync parameter, not just pg_ctl reload Craig Ringer
• 07:44   Re: PostgreSQL index issue Albe Laurenz
• 13:38   very very slow inserts into very large table Jon Nelson
• 14:06   Re: very very slow inserts into very large table Mark Thornton
• 14:44   Re: query overhead Craig Ringer
• 17:35   Re: very very slow inserts into very large table Samuel Gendler
• 17:56   Re: very very slow inserts into very large table Jon Nelson
• 18:28   Re: very very slow inserts into very large table Jeff Janes
• 18:59   Re: very very slow inserts into very large table Mark Thornton
• 19:08   Re: very very slow inserts into very large table Claudio Freire
• 19:16   Re: very very slow inserts into very large table Mark Thornton
• 20:01   Re: very very slow inserts into very large table Claudio Freire

17 July 2012

• 03:31   Re: very very slow inserts into very large table Craig Ringer
• 03:49   Re: very very slow inserts into very large table Satoshi Nagayasu
• 15:58   Process 11812 still waiting for ExclusiveLock on extension of relation David Kerr
• 16:01   Re: very very slow inserts into very large table Ants Aasma
• 16:24   Re: very very slow inserts into very large table Jeff Janes
• 16:27   Slow application response on lightly loaded server? Mike Blackwell
• 16:35   Re: Slow application response on lightly loaded server? Scott Marlowe
• 16:56   Re: very very slow inserts into very large table Claudio Freire
• 17:38   Re: Slow application response on lightly loaded server? Mike Blackwell
• 17:50   Re: Slow application response on lightly loaded server? Scott Marlowe
• 18:10   Re: Slow application response on lightly loaded server? Mike Blackwell
• 19:36   Re: Slow application response on lightly loaded server? Scott Marlowe
• 19:48   Re: Slow application response on lightly loaded server? Mike Blackwell
• 21:00   Re: Slow application response on lightly loaded server? Scott Marlowe

18 July 2012

• 01:52   Linux memory zone reclaim Greg Smith
• 02:01   Re: Linux memory zone reclaim Scott Marlowe
• 03:51   Re: Linux memory zone reclaim Dave Crooke
• 05:38   Re: Linux memory zone reclaim Claudio Freire
• 12:09   Re: Process 11812 still waiting for ExclusiveLock on extension of relation Sergey Konoplev
• 12:18   postgresql query cost values/estimates John Lister
• 14:27   monitoring suggestions Campbell, Lance
• 14:34   Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones. Merlin Moncure
• 16:10   optimizing queries using IN and EXISTS Nick Hofstede
• 18:40   Re: optimizing queries using IN and EXISTS Peter Geoghegan
• 19:33   Re: Array fundamentals Robert Haas
• 20:01   Re: Sequencial scan in a JOIN Robert Haas
• 20:29   Re: optimizing queries using IN and EXISTS Nick Hofstede
• 22:36   Re: optimizing queries using IN and EXISTS Tom Lane

19 July 2012

• 01:43   Re: Process 11812 still waiting for ExclusiveLock on extension of relation David Kerr
• 11:35   queries are fast after dump->restore but slow again after some days dispite vacuum Felix Scheicher
• 11:53   Re: optimizing queries using IN and EXISTS Nick Hofstede
• 12:39   Re: queries are fast after dump->restore but slow again after some days dispite vacuum Andrew Dunstan
• 15:13   Re: queries are fast after dump->restore but slow again after some days dispite vacuum Felix Scheicher
• 15:49   Re: queries are fast after dump->restore but slow again after some days dispite vacuum Andrew Dunstan
• 16:12   Re: queries are fast after dump->restore but slow again after some days dispite vacuum Jeff Janes
• 17:05   Re: queries are fast after dump->restore but slow again after some days dispite vacuum Scott Marlowe
• 17:25   Re: queries are fast after dump->restore but slow again after some days dispite vacuum mandavi

20 July 2012

• 02:27   Deferred constraints performance impact ? mark
• 07:13   Re: queries are fast after dump->restore but slow again after some days dispite vacuum Laszlo Nagy
• 21:19   A very long running query.... Ioannis Anagnostopoulos
• 21:24   Re: A very long running query.... Claudio Freire
• 21:27   Re: A very long running query.... Ioannis Anagnostopoulos
• 21:33   Re: A very long running query.... Rosser Schwarz
• 21:34   Re: A very long running query.... Claudio Freire
• 21:52   Re: A very long running query.... Ioannis Anagnostopoulos
• 21:54   Re: A very long running query.... Ioannis Anagnostopoulos
• 22:19   Re: A very long running query.... Ioannis Anagnostopoulos
• 23:10   Re: A very long running query.... Tom Lane
• 23:56   Re: A very long running query.... Ioannis Anagnostopoulos

21 July 2012

• 08:02   Re: A very long running query.... Craig Ringer
• 08:31   Re: query overhead Craig Ringer
• 09:18   Re: A very long running query.... Marc Mamin
• 09:24   Re: A very long running query.... Ioannis Anagnostopoulos
• 16:58   Re: A very long running query.... Tom Lane
• 17:42   Re: A very long running query.... Ioannis Anagnostopoulos
• 19:16   Re: A very long running query.... Ioannis Anagnostopoulos
• 19:19   Re: A very long running query.... Claudio Freire
• 19:24   Re: A very long running query.... Ioannis Anagnostopoulos
• 20:11   Re: A very long running query.... Claudio Freire
• 20:11   Re: A very long running query.... Claudio Freire
• 20:29   Re: A very long running query.... Ioannis Anagnostopoulos

23 July 2012

• 08:42   Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns
• 10:03   Shards + hash = forever running queries Daniele Varrazzo
• 11:44   Re: Shards + hash = forever running queries Daniele Varrazzo
• 13:46   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Martin French
• 13:54   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Andrew Dunstan
• 14:46   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns
• 14:47   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns
• 15:08   Re: Shards + hash = forever running queries Tom Lane
• 15:09   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Tom Lane
• 15:49   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns
• 19:07   Re: postgres clustering interactions with pg_dump Robert Haas
• 19:38   Re: High CPU Usage Robert Haas
• 21:13   Efficiency of EXISTS? Kenneth Tilton
• 21:52   Re: Efficiency of EXISTS? Merlin Moncure
• 22:13   Re: Efficiency of EXISTS? Kenneth Tilton

24 July 2012

• 00:30   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Craig Ringer
• 06:51   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Martin French
• 07:22   Geoserver-PostGIS performance problems Riaan van den Dool
• 07:55   Re: Geoserver-PostGIS performance problems Brett Walker
• 08:11   Re: Geoserver-PostGIS performance problems Riaan van den Dool
• 08:37   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns
• 08:48   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns
• 09:06   Re: Shards + hash = forever running queries Daniele Varrazzo
• 09:19   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Martin French
• 09:34   Re: Odd blocking (or massively latent) issue - even with EXPLAIN Jim Vanns
• 10:13   Using ctid column changes plan drastically Thomas Kellerer
• 10:42   Why do I need more time with partition table? AI Rumman
• 11:14   transactions start time Aleksei Arefjev
• 11:36   Re: Why do I need more time with partition table? AI Rumman
• 11:46   Re: Why do I need more time with partition table? Jan Otto
• 12:51   ZFS vs. UFS Laszlo Nagy
• 13:04   Re: ZFS vs. UFS Georgi Naplatanov
• 13:18   Re: ZFS vs. UFS Ivan Voras
• 13:23   Heavy inserts load wile querying... Ioannis Anagnostopoulos
• 14:23   Re: Using ctid column changes plan drastically Tom Lane
• 14:27   Re: ZFS vs. UFS Torsten Zuehlsdorff
• 14:30   Re: Heavy inserts load wile querying... Craig James
• 14:34   Re: ZFS vs. UFS Craig James
• 14:42   Re: Heavy inserts load wile querying... Ioannis Anagnostopoulos
• 14:54   Re: Using ctid column changes plan drastically Thomas Kellerer
• 15:50   Re: Geoserver-PostGIS performance problems Maciek Sakrejda
• 15:55   Re: Using ctid column changes plan drastically Tom Lane
• 16:32   Re: Using ctid column changes plan drastically Thomas Kellerer
• 17:13   Re: Using ctid column changes plan drastically Tom Lane
• 17:21   Re: transactions start time Richard Huxton
• 18:27   Re: ZFS vs. UFS Laszlo Nagy
• 18:36   Re: ZFS vs. UFS Laszlo Nagy
• 18:36   Re: Linux memory zone reclaim John Lister
• 18:42   Re: Linux memory zone reclaim Claudio Freire
• 19:14   Re: ZFS vs. UFS Craig James
• 20:12   Re: Linux memory zone reclaim Claudio Freire
• 21:00   Re: Linux memory zone reclaim Claudio Freire
• 21:23   Re: Linux memory zone reclaim John Lister
• 21:37   Re: Linux memory zone reclaim Claudio Freire
• 21:57   Re: Linux memory zone reclaim Scott Marlowe
• 22:08   Re: Linux memory zone reclaim Claudio Freire

25 July 2012

• 06:52   Re: transactions start time Aleksei Arefjev
• 07:27   Re: ZFS vs. UFS Torsten Zuehlsdorff
• 07:38   Re: transactions start time Aleksei Arefjev
• 08:10   Re: Using ctid column changes plan drastically Thomas Kellerer
• 08:40   Re: Why do I need more time with partition table? AI Rumman
• 14:42   Re: Why do I need more time with partition table? Jan Otto
• 14:56   Re: Why do I need more time with partition table? Jeff Janes
• 14:56   Re: transactions start time Tom Lane
• 15:36   odd planner again, pg 9.0.8 Marcus Engene
• 16:20   Re: odd planner again, pg 9.0.8 Pavel Stehule
• 16:39   Re: odd planner again, pg 9.0.8 Tom Lane
• 17:01   Re: transactions start time Andres Freund
• 18:12   Re: odd planner again, pg 9.0.8 Marcus Engene
• 18:46   Re: Geoserver-PostGIS performance problems Merlin Moncure
• 19:17   Re: Geoserver-PostGIS performance problems Vinicius Abrahao
• 19:26   Re: Geoserver-PostGIS performance problems Merlin Moncure
• 19:59   Re: Geoserver-PostGIS performance problems Vinicius Abrahao
• 20:04   Re: Geoserver-PostGIS performance problems Merlin Moncure

26 July 2012

• 02:14   Re: Geoserver-PostGIS performance problems Rural Hunter
• 06:34   Re: Geoserver-PostGIS performance problems Maciek Sakrejda
• 06:51   Re: Geoserver-PostGIS performance problems Maciek Sakrejda
• 13:32   Re: Geoserver-PostGIS performance problems Merlin Moncure
• 14:42   planner, *_collapse_limit Marcus Engene
• 17:01   Re: planner, *_collapse_limit Merlin Moncure

27 July 2012

• 00:26   Re: Linux memory zone reclaim Bruce Momjian
• 05:25   Re: ZFS vs. UFS Greg Smith
• 22:03   pgstat wait timeout Anibal David Acosta
• 22:31   Re: pgstat wait timeout Anibal David Acosta

28 July 2012

• 04:33   Postgres 9.1.4 - high stats collector IO usage David Barton
• 07:08   Re: Postgres 9.1.4 - high stats collector IO usage Pavel Stehule
• 16:14   Re: Postgres 9.1.4 - high stats collector IO usage Tom Lane
• 17:08   Re: Postgres 9.1.4 - high stats collector IO usage David Barton
• 17:12   Re: Postgres 9.1.4 - high stats collector IO usage David Barton

30 July 2012

• 16:44   Re: Linux memory zone reclaim Kevin Grittner
• 17:09   Re: Linux memory zone reclaim Scott Marlowe
• 17:27   Re: Linux memory zone reclaim Bruce Momjian

31 July 2012

• 01:21   Re: Postgres 9.1.4 - high stats collector IO usage Mark Kirkwood
• 08:50   Re: ZFS vs. UFS Laszlo Nagy
• 14:33   Re: ZFS vs. UFS Craig James