Mailing lists [pgsql-performance]

1 December 2009

• 07:03   Re: Server Freezing Waldomiro
• 07:19   Re: Server Freezing Waldomiro
• 11:49   Re: Server Freezing Fernando Hevia
• 14:52   Order by (for 15 rows) adds 30 seconds to query time Richard Neill
• 16:06   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 16:06   Re: Order by (for 15 rows) adds 30 seconds to query time Jean-Michel Pouré
• 18:46   Re: Order by (for 15 rows) adds 30 seconds to query time Richard Neill
• 19:37   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 21:38   Re: RAID card recommendation Scott Carey
• 22:11   Re: RAID card recommendation Karl Denninger
• 22:49   Re: RAID card recommendation Greg Smith

2 December 2009

• 01:43   Re: Order by (for 15 rows) adds 30 seconds to query time Richard Neill
• 07:08   Re: Order by (for 15 rows) adds 30 seconds to query time Matthew Wakeling
• 07:13   Re: Cost of sort/order by not estimated by the query planner Laurent Laborde
• 08:42   Re: Cost of sort/order by not estimated by the query planner Greg Stark
• 08:47   Re: Cost of sort/order by not estimated by the query planner Laurent Laborde
• 08:48   Re: Cost of sort/order by not estimated by the query planner Greg Stark
• 09:02   Re: Cost of sort/order by not estimated by the query planner Laurent Laborde
• 09:17   Re: Cost of sort/order by not estimated by the query planner Robert Haas
• 09:20   Re: Cost of sort/order by not estimated by the query planner Laurent Laborde
• 09:47   Re: Order by (for 15 rows) adds 30 seconds to query time Craig Ringer
• 11:32   Re: Cost of sort/order by not estimated by the query planner Laurent Laborde
• 12:48   Re: Cost of sort/order by not estimated by the query planner Robert Haas
• 13:01   Re: Cost of sort/order by not estimated by the query planner Tom Lane
• 15:55   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 16:39   Re: Order by (for 15 rows) adds 30 seconds to query time Tom Lane
• 18:18   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 18:20   Re: Order by (for 15 rows) adds 30 seconds to query time Tom Lane
• 18:23   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 19:04   Re: Order by (for 15 rows) adds 30 seconds to query time Richard Neill
• 19:31   Re: Order by (for 15 rows) adds 30 seconds to query time Kevin Grittner
• 21:31   Re: Order by (for 15 rows) adds 30 seconds to query time Richard Neill
• 23:16   Re: Query times change by orders of magnitude as DB ages Scott Carey

3 December 2009

• 02:23   Re: Analyse without locking? Richard Neill
• 03:04   Re: Checkpoint spikes Greg Smith
• 04:52   Re: [BUGS] BUG #5228: Execution of prepared query is slow when timestamp parameter is used Craig Ringer
• 05:44   Re: Analyse without locking? Laurent Laborde
• 07:27   Re: Checkpoint spikes Heikki Linnakangas
• 16:57   Re: Checkpoint spikes Greg Smith
• 20:05   Re: SSD + RAID Scott Carey

5 December 2009

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

6 December 2009

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

7 December 2009

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

8 December 2009

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

9 December 2009

• 09:38   Re: Load experimentation Andy Colson
• 14:36   big select is resulting in a large amount of disk writing by kjournald Joseph S
• 15:46   Re: big select is resulting in a large amount of disk writing by kjournald Kenneth Marshall
• 15:54   Re: big select is resulting in a large amount of disk writing by kjournald Greg Smith
• 17:06   Re: big select is resulting in a large amount of disk writing by kjournald Joseph S
• 18:04   Re: big select is resulting in a large amount of disk writing by kjournald Greg Smith
• 18:36   Re: big select is resulting in a large amount of disk writing by kjournald Joseph S

10 December 2009

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

11 December 2009

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

12 December 2009

• 16:36   Re: 8.4.1 ubuntu karmic slow createdb Michael Clemmons
• 16:38   Re: 8.4.1 ubuntu karmic slow createdb Andres Freund
• 23:56   Re: 8.4.1 ubuntu karmic slow createdb Robert Haas

15 December 2009

• 21:29   Re: big select is resulting in a large amount of disk writing by kjournald Scott Carey

16 December 2009

• 02:52   Parallel Function calls using multiple processes Vishal Gupta
• 03:35   Re: Parallel Function calls using multiple processes Pavel Stehule
• 04:17   Re: Parallel Function calls using multiple processes Vishal Gupta
• 04:38   Re: Parallel Function calls using multiple processes Pavel Stehule

17 December 2009

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

18 December 2009

• 02:27   Re: seq scan instead of index scan Tom Lane
• 08:46   Re: Issues with \copy from file Sigurgeir Gunnarsson
• 10:18   Re: Automatic optimization of IN clauses via INNER JOIN Robert Haas
• 10:24   Re: Automatic optimization of IN clauses via INNER JOIN Grzegorz Jaśkiewicz
• 11:23   Re: Issues with \copy from file Robert Haas
• 11:23   Re: Automatic optimization of IN clauses via INNER JOIN Robert Haas
• 11:24   Re: Automatic optimization of IN clauses via INNER JOIN Grzegorz Jaśkiewicz
• 11:44   Idea how to get rid of Bitmap Heap Scan Michael N. Mikhulya
• 11:51   Re: Idea how to get rid of Bitmap Heap Scan Matthew Wakeling
• 11:51   Re: Issues with \copy from file Sigurgeir Gunnarsson
• 12:18   Re: Idea how to get rid of Bitmap Heap Scan Michael N. Mikhulya
• 13:29   Re: Idea how to get rid of Bitmap Heap Scan Greg Stark
• 20:22   Re: Automatic optimization of IN clauses via INNER JOIN Robert Haas
• 20:24   Re: Issues with \copy from file Robert Haas
• 20:32   Re: Automatic optimization of IN clauses via INNER JOIN Tom Lane
• 23:33   Re: Automatic optimization of IN clauses via INNER JOIN Robert Haas

19 December 2009

• 22:12   Re: Idea how to get rid of Bitmap Heap Scan Robert Haas

20 December 2009

• 07:38   Re: Idea how to get rid of Bitmap Heap Scan Greg Stark
• 12:26   Re: Idea how to get rid of Bitmap Heap Scan Tom Lane
• 21:57   Re: Idea how to get rid of Bitmap Heap Scan Robert Haas

23 December 2009

• 18:11   hardware priority for an SSD database? Ben Chobot
• 20:26   Re: hardware priority for an SSD database? Greg Smith
• 21:39   Re: FSM - per database or per installation? Craig James
• 22:03   Re: FSM - per database or per installation? Scott Marlowe
• 22:07   Re: FSM - per database or per installation? Alvaro Herrera

24 December 2009

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

26 December 2009

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

27 December 2009

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

28 December 2009

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

29 December 2009

• 06:48   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Greg Stark
• 07:13   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 14:31   Re: [HACKERS] Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) Andres Freund
• 16:12   Re: roopasatish
• 17:37   Re: Performance with partitions/inheritance and multiple tables Anj Adu