Mailing lists [pgsql-performance]

1 December 2009

• 01:31   Re: truncate in transaction blocks read access Joshua D. Drake
• 10:03   Re: Server Freezing Waldomiro
• 10:19   Re: Server Freezing Waldomiro
• 14:49   Re: Server Freezing Fernando Hevia
• 17:52   Order by (for 15 rows) adds 30 seconds to query time Richard Neill
• 19:06   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 19:06   Re: Order by (for 15 rows) adds 30 seconds to query time Jean-Michel Pouré
• 21:46   Re: Order by (for 15 rows) adds 30 seconds to query time Richard Neill
• 22:37   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner

2 December 2009

• 00:38   Re: RAID card recommendation Scott Carey
• 01:11   Re: RAID card recommendation Karl Denninger
• 01:49   Re: RAID card recommendation Greg Smith
• 04:43   Re: Order by (for 15 rows) adds 30 seconds to query time Richard Neill
• 10:08   Re: Order by (for 15 rows) adds 30 seconds to query time Matthew Wakeling
• 10:13   Re: Cost of sort/order by not estimated by the query planner Laurent Laborde
• 11:42   Re: Cost of sort/order by not estimated by the query planner Greg Stark
• 11:47   Re: Cost of sort/order by not estimated by the query planner Laurent Laborde
• 11:48   Re: Cost of sort/order by not estimated by the query planner Greg Stark
• 12:02   Re: Cost of sort/order by not estimated by the query planner Laurent Laborde
• 12:17   Re: Cost of sort/order by not estimated by the query planner Robert Haas
• 12:20   Re: Cost of sort/order by not estimated by the query planner Laurent Laborde
• 12:47   Re: Order by (for 15 rows) adds 30 seconds to query time Craig Ringer
• 14:32   Re: Cost of sort/order by not estimated by the query planner Laurent Laborde
• 15:48   Re: Cost of sort/order by not estimated by the query planner Robert Haas
• 16:01   Re: Cost of sort/order by not estimated by the query planner Tom Lane
• 18:55   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 19:39   Re: Order by (for 15 rows) adds 30 seconds to query time Tom Lane
• 21:18   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 21:20   Re: Order by (for 15 rows) adds 30 seconds to query time Tom Lane
• 21:23   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 22:04   Re: Order by (for 15 rows) adds 30 seconds to query time Richard Neill
• 22:31   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner

3 December 2009

• 00:31   Re: Order by (for 15 rows) adds 30 seconds to query time Richard Neill
• 02:16   Re: Query times change by orders of magnitude as DB ages Scott Carey
• 05:23   Re: Analyse without locking? Richard Neill
• 06:04   Re: Checkpoint spikes Greg Smith
• 07:52   Re: [BUGS] BUG #5228: Execution of prepared query is slow when timestamp parameter is used Craig Ringer
• 08:44   Re: Analyse without locking? Laurent Laborde
• 10:27   Re: Checkpoint spikes Heikki Linnakangas
• 19:57   Re: Checkpoint spikes Greg Smith
• 23:05   Re: SSD + RAID Scott Carey

5 December 2009

• 17:44   Re: Server Freezing Denis Lussier
• 17:44   Re: OpenMP in PostgreSQL-8.4.0 Denis Lussier
• 17:44   query cost too high, anyway to reduce it nair rajiv
• 17:44   Time Profiling inside the procedure niraj patel
• 17:44   performance while importing a very large data set in to database Ashish Kumar Singh
• 17:44   Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum Andreas Thiel
• 19:53   Re: performance while importing a very large data set in to database Jeremy Harris
• 20:01   Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum Andres Freund
• 20:07   Re: performance while importing a very large data set in to database Ing . Marcos Luís Ortíz Valmaseda
• 20:13   Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum Scott Marlowe
• 20:13   Re: performance while importing a very large data set in to database Scott Marlowe
• 20:14   Re: query cost too high, anyway to reduce it Scott Marlowe
• 22:10   Re: performance while importing a very large data set in to database Scott Marlowe

6 December 2009

• 00:16   Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum Craig Ringer
• 00:34   Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum Greg Smith
• 13:13   Re: performance while importing a very large data set in to database Pierre Frédéric Caillaud
• 13:16   Re: performance while importing a very large data set in to database Kris Kewley
• 14:15   Re: performance while importing a very large data set in to database Greg Smith
• 15:51   Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum Andres Freund
• 18:10   Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum Andres Freund
• 19:24   Re: Large DB, several tuning questions: Index sizes, VACUUM, REINDEX, Autovacuum Scott Marlowe

7 December 2009

• 17:13   Load experimentation Ben Brehmer
• 17:33   Re: Load experimentation Kevin Grittner
• 17:39   Re: Load experimentation Scott Mead
• 17:40   Re: Load experimentation Thom Brown
• 17:45   Re: Load experimentation Ben Brehmer
• 17:50   Re: Load experimentation Craig James
• 18:05   Re: RAID card recommendation Scott Carey
• 18:21   Re: RAID card recommendation Scott Carey
• 18:33   Re: Load experimentation Ben Brehmer
• 18:37   Re: Load experimentation Craig James
• 18:48   Re: Load experimentation Alan Hodgson
• 18:49   Re: RAID card recommendation Karl Denninger
• 19:59   Re: Load experimentation Greg Smith
• 20:20   Re: RAID card recommendation Greg Smith
• 21:05   performance penalty between Postgresql 8.3.8 and 8.4.1 Schmitz, David
• 21:20   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Kevin Grittner
• 21:23   Re: RAID card recommendation Craig James
• 21:34   Re: RAID card recommendation Karl Denninger
• 21:43   Re: RAID card recommendation Greg Smith
• 21:58   Re: RAID card recommendation Greg Smith
• 22:14   Re: RAID card recommendation Karl Denninger
• 22:17   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Schmitz, David
• 22:25   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Andres Freund

8 December 2009

• 02:08   Dynamlically updating the estimated cost of a transaction Hasini Gunasinghe
• 03:04   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Robert Haas
• 04:37   error occured in dbt2 against with postgresql Niu Yan
• 04:44   Re: Dynamlically updating the estimated cost of a transaction Greg Smith
• 06:22   Re: Load experimentation Ben Brehmer
• 06:35   Re: Load experimentation Greg Smith
• 06:59   Re: Load experimentation Scott Marlowe
• 06:59   Re: Load experimentation Scott Marlowe
• 08:10   Re: Load experimentation Dimitri Fontaine
• 08:28   Re: Load experimentation Scott Marlowe
• 08:39   Re: Load experimentation Dimitri Fontaine
• 08:42   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Schmitz, David
• 09:00   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Schmitz, David
• 09:07   Re: Checkpoint spikes Richard Neill
• 09:08   Re: Checkpoint spikes Richard Neill
• 09:12   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Thom Brown
• 09:19   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Schmitz, David
• 09:29   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Andres Freund
• 09:42   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Schmitz, David
• 12:13   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Craig Ringer
• 12:30   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Schmitz, David
• 12:39   Optimizing Bitmap Heap Scan. niraj patel
• 12:43   Re: Optimizing Bitmap Heap Scan. Grzegorz Jaśkiewicz
• 12:51   Re: Optimizing Bitmap Heap Scan. niraj patel
• 13:03   Re: Optimizing Bitmap Heap Scan. Matthew Wakeling
• 13:22   Re: SSD + RAID Matthew Wakeling
• 13:27   Re: Optimizing Bitmap Heap Scan. niraj patel
• 13:48   Re: Optimizing Bitmap Heap Scan. Matthew Wakeling
• 14:02   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Robert Haas
• 14:05   Re: Checkpoint spikes Kevin Grittner
• 14:14   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Robert Haas
• 14:51   Vacuum running out of memory Jonathan Foy
• 14:51   Re: Optimizing Bitmap Heap Scan. Lennin Caro
• 14:52   Re: error occured in dbt2 against with postgresql Robert Haas
• 15:04   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Tom Lane
• 15:08   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Schmitz, David
• 15:22   Re: Vacuum running out of memory Tom Lane
• 15:31   Re: Vacuum running out of memory Jonathan Foy
• 15:41   Re: Vacuum running out of memory Greg Stark
• 15:42   Re: Vacuum running out of memory Tom Lane
• 15:48   Re: Optimizing Bitmap Heap Scan. Kevin Grittner
• 16:39   Re: performance penalty between Postgresql 8.3.8 and 8.4.1 Robert Haas
• 17:30   Re: Optimizing Bitmap Heap Scan. Robert Haas

9 December 2009

• 01:05   Re: Checkpoint spikes Greg Smith
• 01:13   Re: Checkpoint spikes Andres Freund
• 12:38   Re: Load experimentation Andy Colson
• 17:36   big select is resulting in a large amount of disk writing by kjournald Joseph S
• 18:46   Re: big select is resulting in a large amount of disk writing by kjournald Kenneth Marshall
• 18:54   Re: big select is resulting in a large amount of disk writing by kjournald Greg Smith
• 20:06   Re: big select is resulting in a large amount of disk writing by kjournald Joseph S
• 21:04   Re: big select is resulting in a large amount of disk writing by kjournald Greg Smith
• 21:36   Re: big select is resulting in a large amount of disk writing by kjournald Joseph S

10 December 2009

• 14:50   Fw: Help me put 2 Gigs of RAM to use Mark Stosberg
• 15:03   Re: Fw: Help me put 2 Gigs of RAM to use Matthew Wakeling
• 15:42   Re: big select is resulting in a large amount of disk writing by kjournald Kevin Grittner
• 15:45   Re: Help me put 2 Gigs of RAM to use Mark Stosberg
• 15:45   Re: Fw: Help me put 2 Gigs of RAM to use Greg Smith
• 16:19   Re: Fw: Help me put 2 Gigs of RAM to use Robert Haas
• 19:24   Re: Load experimentation Ben Brehmer
• 19:41   8.4.1 ubuntu karmic slow createdb Michael Clemmons
• 20:57   Re: 8.4.1 ubuntu karmic slow createdb Andres Freund
• 21:01   Re: 8.4.1 ubuntu karmic slow createdb Michael Clemmons
• 21:09   Re: 8.4.1 ubuntu karmic slow createdb Andres Freund
• 22:30   Re: Load experimentation Scott Carey

11 December 2009

• 00:38   Re: 8.4.1 ubuntu karmic slow createdb Nikolas Everett
• 01:38   Re: Load experimentation Scott Carey
• 16:58   Re: 8.4.1 ubuntu karmic slow createdb Joshua D. Drake
• 19:44   Re: 8.4.1 ubuntu karmic slow createdb Nikolas Everett
• 19:50   Re: 8.4.1 ubuntu karmic slow createdb Joshua D. Drake
• 20:40   Re: 8.4.1 ubuntu karmic slow createdb Nikolas Everett
• 20:58   Re: 8.4.1 ubuntu karmic slow createdb Scott Marlowe
• 21:05   Re: 8.4.1 ubuntu karmic slow createdb Scott Mead
• 21:13   Re: 8.4.1 ubuntu karmic slow createdb Scott Marlowe
• 21:13   Re: 8.4.1 ubuntu karmic slow createdb Scott Carey
• 21:19   Re: 8.4.1 ubuntu karmic slow createdb Scott Marlowe
• 21:40   Re: 8.4.1 ubuntu karmic slow createdb Greg Smith
• 21:52   Re: 8.4.1 ubuntu karmic slow createdb Michael Clemmons
• 22:59   Re: 8.4.1 ubuntu karmic slow createdb Scott Marlowe
• 23:19   Re: 8.4.1 ubuntu karmic slow createdb Andres Freund
• 23:58   Re: 8.4.1 ubuntu karmic slow createdb Joshua D. Drake

12 December 2009

• 02:50   Re: 8.4.1 ubuntu karmic slow createdb Joshua D. Drake
• 19:36   Re: 8.4.1 ubuntu karmic slow createdb Michael Clemmons
• 19:38   Re: 8.4.1 ubuntu karmic slow createdb Andres Freund

13 December 2009

• 02:56   Re: 8.4.1 ubuntu karmic slow createdb Robert Haas

16 December 2009

• 00:29   Re: big select is resulting in a large amount of disk writing by kjournald Scott Carey
• 05:52   Parallel Function calls using multiple processes Vishal Gupta
• 06:35   Re: Parallel Function calls using multiple processes Pavel Stehule
• 07:17   Re: Parallel Function calls using multiple processes Vishal Gupta
• 07:38   Re: Parallel Function calls using multiple processes Pavel Stehule

17 December 2009

• 14:23   Automatic optimization of IN clauses via INNER JOIN Thomas Hamilton
• 14:33   Re: Automatic optimization of IN clauses via INNER JOIN Tom Lane
• 14:45   Re: Automatic optimization of IN clauses via INNER JOIN Thomas Hamilton
• 14:57   Re: Automatic optimization of IN clauses via INNER JOIN Tom Lane
• 17:05   Re: Automatic optimization of IN clauses via INNER JOIN Robert Haas
• 19:05   Re: Automatic optimization of IN clauses via INNER JOIN Grzegorz Jaśkiewicz
• 22:22   seq scan instead of index scan Karl Larsson
• 22:26   Re: seq scan instead of index scan Scott Marlowe
• 22:29   Re: seq scan instead of index scan Kevin Grittner
• 22:46   Re: seq scan instead of index scan Karl Larsson
• 23:11   Re: seq scan instead of index scan Greg Smith
• 23:11   Re: seq scan instead of index scan Scott Marlowe

18 December 2009

• 00:10   Re: seq scan instead of index scan Karl Larsson
• 00:16   Re: seq scan instead of index scan Scott Marlowe
• 00:17   Re: seq scan instead of index scan Karl Larsson
• 00:37   Re: seq scan instead of index scan Scott Marlowe
• 01:20   Re: Automatic optimization of IN clauses via INNER JOIN Craig Ringer
• 05:27   Re: seq scan instead of index scan Tom Lane
• 11:46   Re: Issues with \copy from file Sigurgeir Gunnarsson
• 13:18   Re: Automatic optimization of IN clauses via INNER JOIN Robert Haas
• 13:24   Re: Automatic optimization of IN clauses via INNER JOIN Grzegorz Jaśkiewicz
• 14:23   Re: Issues with \copy from file Robert Haas
• 14:23   Re: Automatic optimization of IN clauses via INNER JOIN Robert Haas
• 14:24   Re: Automatic optimization of IN clauses via INNER JOIN Grzegorz Jaśkiewicz
• 14:44   Idea how to get rid of Bitmap Heap Scan Michael N. Mikhulya
• 14:51   Re: Idea how to get rid of Bitmap Heap Scan Matthew Wakeling
• 14:51   Re: Issues with \copy from file Sigurgeir Gunnarsson
• 15:18   Re: Idea how to get rid of Bitmap Heap Scan Michael N. Mikhulya
• 16:29   Re: Idea how to get rid of Bitmap Heap Scan Greg Stark
• 23:22   Re: Automatic optimization of IN clauses via INNER JOIN Robert Haas
• 23:24   Re: Issues with \copy from file Robert Haas
• 23:32   Re: Automatic optimization of IN clauses via INNER JOIN Tom Lane

19 December 2009

• 02:33   Re: Automatic optimization of IN clauses via INNER JOIN Robert Haas

20 December 2009

• 01:12   Re: Idea how to get rid of Bitmap Heap Scan Robert Haas
• 10:38   Re: Idea how to get rid of Bitmap Heap Scan Greg Stark
• 15:26   Re: Idea how to get rid of Bitmap Heap Scan Tom Lane

21 December 2009

• 00:57   Re: Idea how to get rid of Bitmap Heap Scan Robert Haas

23 December 2009

• 21:11   hardware priority for an SSD database? Ben Chobot
• 23:26   Re: hardware priority for an SSD database? Greg Smith

24 December 2009

• 00:39   Re: FSM - per database or per installation? Craig James
• 01:03   Re: FSM - per database or per installation? Scott Marlowe
• 01:07   Re: FSM - per database or per installation? Alvaro Herrera
• 09:24   Re: FSM - per database or per installation? Craig Ringer
• 10:56   Optimizer use of index slows down query by factor Michael Ruf
• 11:00   Multicolumn index - WHERE ... ORDER BY Lucas Maystre
• 11:12   SATA drives performance Ognjen Blagojevic
• 13:42   Performance with partitions/inheritance and multiple tables Radhika S
• 13:57   Re: SATA drives performance Scott Marlowe
• 13:59   Re: SATA drives performance Richard Neill
• 14:46   Re: Optimizer use of index slows down query by factor Tom Lane
• 14:50   Re: Performance with partitions/inheritance and multiple tables Shrirang Chitnis
• 14:52   Re: SATA drives performance Greg Smith
• 14:56   Re: Multicolumn index - WHERE ... ORDER BY Tom Lane
• 15:19   Re: SATA drives performance gael@pilotsystems.net (Gaël Le Mignot)
• 15:42   Re: SATA drives performance Greg Smith
• 15:43   Re: SATA drives performance Mark Mielke
• 16:06   Re: SATA drives performance Greg Smith
• 16:12   Re: SATA drives performance Richard Neill
• 16:28   Re: SATA drives performance Jeremy Harris
• 17:09   Re: SATA drives performance Richard Neill
• 17:32   Re: SATA drives performance Scott Marlowe
• 20:10   Re: SATA drives performance Ognjen Blagojevic
• 21:19   Re: SATA drives performance Adam Tauno Williams
• 21:51   Re: SATA drives performance Richard Neill
• 21:59   Re: SATA drives performance Scott Marlowe
• 23:15   Re: SATA drives performance Richard Neill
• 23:52   Re: SATA drives performance Scott Marlowe

26 December 2009

• 19:15   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner

27 December 2009

• 14:36   Re: SATA drives performance Glyn Astill
• 20:52   Re: Order by (for 15 rows) adds 30 seconds to query time Tom Lane

28 December 2009

• 14:10   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 16:41   Re: Order by (for 15 rows) adds 30 seconds to query time Tom Lane
• 17:37   Re: SATA drives performance Craig James
• 21:55   Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 21:59   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 22:06   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Tom Lane
• 22:20   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 22:32   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 22:58   Re: 8.4.1 ubuntu karmic slow createdb Thomas Kellerer
• 23:28   Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark
• 23:29   Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 23:43   Re: [PERFORM] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1ubuntu karmic slow createdb) Andres Freund
• 23:45   Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) david@lang.hm
• 23:46   Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) david@lang.hm
• 23:46   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Smith

29 December 2009

• 01:06   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 01:53   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Michael Clemmons
• 01:55   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 02:04   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Michael Clemmons
• 02:26   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 09:48   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark
• 10:13   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 17:31   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 19:12   Re: roopasatish
• 20:37   Re: Performance with partitions/inheritance and multiple tables Anj Adu