Mailing lists [pgsql-performance]

1 April 2011

• 00:53   table contraints checks only happen in planner phase Joseph Shraibman
• 00:53   index usage on queries on inherited tables Joseph Shraibman
• 03:42   Re: good old VACUUM FULL Craig Ringer
• 06:50   Re: COPY with high # of clients, partitioned table locking issues? Greg Smith
• 17:32   Re: table contraints checks only happen in planner phase Josh Berkus

2 April 2011

• 18:52   C on Client versus C on Server Eliot Gable

3 April 2011

• 07:02   Re: C on Client versus C on Server Heikki Linnakangas

4 April 2011

• 09:02   Re: very long updates very small tables Lars Feistner
• 09:40   Postgres Performance Tuning Adarsh Sharma
• 10:28   Re: Postgres Performance Tuning tv@fuzzy.cz
• 10:39   Re: Postgres Performance Tuning Adarsh Sharma
• 10:44   Re: Postgres Performance Tuning Scott Marlowe
• 10:52   Re: Postgres Performance Tuning Sethu Prasad
• 10:54   Re: Postgres Performance Tuning Scott Marlowe
• 11:03   Re: Postgres Performance Tuning Raghavendra
• 11:34   Re: Postgres Performance Tuning Adarsh Sharma
• 11:43   Re: Postgres Performance Tuning Scott Marlowe
• 11:51   Re: Postgres Performance Tuning Adarsh Sharma
• 12:14   Re: Postgres Performance Tuning Achilleas Mantzios
• 12:14   Re: Postgres Performance Tuning Scott Marlowe
• 12:28   Re: Postgres Performance Tuning tv@fuzzy.cz
• 12:34   Re: Postgres Performance Tuning Adarsh Sharma
• 12:38   Re: Postgres Performance Tuning Raghavendra
• 14:33   Re: very long updates very small tables Kevin Grittner
• 16:23   Re: Postgres Performance Tuning Scott Marlowe

5 April 2011

• 01:26   Re: Intel SSDs that may not suck Greg Smith
• 07:33   Re: Postgres Performance Tuning Adarsh Sharma
• 10:27   Which is better Index Adarsh Sharma
• 12:47   Re: Postgres Performance Tuning Ákos Gábriel
• 13:08   Re: Postgres Performance Tuning Scott Marlowe
• 13:20   Re: Postgres Performance Tuning Adarsh Sharma
• 13:50   Re: Postgres Performance Tuning Scott Marlowe
• 14:07   Re: Which is better Index Chetan Suttraway
• 14:07   Re: Intel SSDs that may not suck Merlin Moncure
• 22:36   Partial index slower than regular index Thom Brown
• 23:03   Re: Partial index slower than regular index Kenneth Marshall
• 23:33   Re: Partial index slower than regular index Scott Marlowe
• 23:41   Re: Partial index slower than regular index Mark Kirkwood

6 April 2011

• 02:04   Re: Partial index slower than regular index Mark Kirkwood
• 04:44   Re: Partial index slower than regular index Tom Lane
• 06:55   Re: Which is better Index Greg Smith
• 08:16   Re: Partial index slower than regular index Thom Brown
• 08:35   Re: Partial index slower than regular index Thom Brown
• 11:30   Re: Postgres Performance Tuning Ákos Gábriel
• 11:30   help speeding up a query in postgres 8.4.5 Maria L. Wilson
• 11:41   Re: help speeding up a query in postgres 8.4.5 Szymon Guz
• 13:16   Re: help speeding up a query in postgres 8.4.5 tv@fuzzy.cz
• 14:54   Re: help speeding up a query in postgres 8.4.5 Maria L. Wilson
• 14:54   Re: help speeding up a query in postgres 8.4.5 Maria L. Wilson
• 15:37   Re: help speeding up a query in postgres 8.4.5 Kevin Grittner
• 18:23   Re: help speeding up a query in postgres 8.4.5 Tomas Vondra
• 18:30   Re: very long updates very small tables Tomas Vondra
• 21:02   Re: Intel SSDs that may not suck Scott Carey
• 21:12   Re: Intel SSDs that may not suck Andy
• 22:40   Background fsck Ireneusz Pluta
• 22:48   Re: Background fsck Scott Marlowe
• 22:59   Re: Background fsck Ireneusz Pluta
• 23:03   Re: Intel SSDs that may not suck 

7 April 2011

• 00:05   Re: Intel SSDs that may not suck Scott Carey
• 00:12   Re: Intel SSDs that may not suck Scott Carey
• 00:20   Re: Intel SSDs that may not suck Scott Carey
• 00:23   Re: Intel SSDs that may not suck Scott Carey
• 00:42   Re: Intel SSDs that may not suck Scott Carey
• 01:07   Re: Intel SSDs that may not suck David Rees
• 01:32   Re: Intel SSDs that may not suck Greg Smith
• 02:21   Re: Intel SSDs that may not suck Greg Smith
• 03:03   Re: Intel SSDs that may not suck David Boreham
• 03:29   Re: Intel SSDs that may not suck 
• 03:52   Re: Intel SSDs that may not suck David Boreham
• 04:28   Re: Intel SSDs that may not suck Jesper Krogh
• 05:48   Re: Intel SSDs that may not suck Greg Smith
• 06:37   Re: Partial index slower than regular index Tom Lane
• 07:11   Re: Partial index slower than regular index Thom Brown
• 07:27   Re: help speeding up a query in postgres 8.4.5 Maria L. Wilson
• 08:02   Re: Partial index slower than regular index Thom Brown
• 13:32   Re: Background fsck Ivan Voras
• 14:02   Re: Background fsck Achilleas Mantzios
• 16:16   Re: Background fsck Greg Smith
• 16:25   Re: Intel SSDs that may not suck Scott Carey

8 April 2011

• 05:56   Re: Background fsck Ireneusz Pluta
• 06:19   Re: Background fsck Achilleas Mantzios
• 06:22   Re: Background fsck Scott Marlowe
• 09:35   Re: Background fsck Ireneusz Pluta
• 10:22   Re: Background fsck Ivan Voras
• 11:52   Re: Background fsck Ireneusz Pluta
• 11:54   Re: Background fsck Ireneusz Pluta
• 12:14   Re: Background fsck Achilleas Mantzios
• 14:36   Re: Background fsck Jochen Erwied
• 14:51   postgresql benchmark Radhya sahal
• 15:45   Re: Why it is using/not using index scan? Merlin Moncure
• 16:12   Re: Background fsck Ireneusz Pluta
• 17:37    Whatever Deep

9 April 2011

• 01:42   Slow query postgres 8.3 Anne Rosset
• 10:36   Re: Slow query postgres 8.3 tv@fuzzy.cz
• 14:59   Re: Why it is using/not using index scan? Tomas Vondra
• 16:55   Multiple index builds on same table - in one sweep? Chris Ruprecht
• 17:10   Re: Multiple index builds on same table - in one sweep? Tom Lane
• 17:24   Re: Multiple index builds on same table - in one sweep? Chris Ruprecht

10 April 2011

• 18:23   optimizer parameters Radhya sahal
• 23:28   Re: optimizer parameters Tomas Vondra

11 April 2011

• 02:29   Re: Multiple index builds on same table - in one sweep? Greg Smith
• 02:41   Re: optimizer parameters Greg Smith
• 06:03   Re: Multiple index builds on same table - in one sweep? Scott Marlowe
• 16:09   Re: Slow query postgres 8.3 Anne Rosset
• 16:42   Re: Multiple index builds on same table - in one sweep? Scott Marlowe
• 16:45   Re: Multiple index builds on same table - in one sweep? Greg Smith
• 16:59   Re: Slow query postgres 8.3 Kevin Grittner
• 17:01   Re: Multiple index builds on same table - in one sweep? Scott Marlowe
• 18:04   Linux: more cores = less concurrency. Glyn Astill
• 18:11   Re: Linux: more cores = less concurrency. Kevin Grittner
• 18:19   Re: Linux: more cores = less concurrency. Joshua D. Drake
• 18:21   Re: Multiple index builds on same table - in one sweep? Shaun Thomas
• 18:40   Re: Linux: more cores = less concurrency. Glyn Astill
• 18:45   Re: Linux: more cores = less concurrency. Scott Marlowe
• 18:49   Re: Multiple index builds on same table - in one sweep? Tom Lane
• 18:50   Re: Multiple index builds on same table - in one sweep? Scott Marlowe
• 19:29   Re: Linux: more cores = less concurrency. Scott Marlowe
• 19:42   Re: Linux: more cores = less concurrency. Glyn Astill
• 19:43   Postgres 9 slave lagging Saurabh Agrawal
• 19:52   Re: Linux: more cores = less concurrency. Steve Clark
• 19:56   Re: Linux: more cores = less concurrency. Jesper Krogh
• 20:17   Re: Linux: more cores = less concurrency. Glyn Astill
• 20:18   Re: Linux: more cores = less concurrency. david@lang.hm
• 20:52   Re: Linux: more cores = less concurrency. Scott Marlowe
• 21:13   Re: Linux: more cores = less concurrency. Kevin Grittner
• 21:15   Re: Linux: more cores = less concurrency. Glyn Astill
• 21:30   Re: Linux: more cores = less concurrency. James Cloos
• 21:36   Re: Linux: more cores = less concurrency. Kevin Grittner
• 22:12   Re: Linux: more cores = less concurrency. David Rees
• 22:39   Re: Postgres 9 slave lagging Merlin Moncure
• 23:02   how explain works Radhya sahal
• 23:09   Re: how explain works Nathan Boley
• 23:22   Re: how explain works to Mr Nathan Boley Radhya sahal
• 23:28   Two servers - One Replicated - Same query Ozer, Pam

12 April 2011

• 00:06   Re: Linux: more cores = less concurrency. mark
• 00:18   Re: Linux: more cores = less concurrency. Scott Marlowe
• 00:19   Re: Linux: more cores = less concurrency. Scott Marlowe
• 00:51   Re: Linux: more cores = less concurrency. mark
• 01:59   Re: Linux: more cores = less concurrency. Merlin Moncure
• 02:12   Re: Linux: more cores = less concurrency. Scott Marlowe
• 05:18   Re: Linux: more cores = less concurrency. Jesper Krogh
• 05:28   performance problem with LIMIT (order BY in DESC order). Wrong index used? Dieter Rehbein
• 05:55   Re: Linux: more cores = less concurrency. Scott Marlowe
• 06:49   Poor performance when joining against inherited tables Lucas Madar
• 07:31   Re: Linux: more cores = less concurrency. Arjen van der Meijden
• 07:33   Re: Slow query postgres 8.3 Claudio Freire
• 07:42   Re: performance problem with LIMIT (order BY in DESC order). Wrong index used? Claudio Freire
• 07:51   DBT-5 & Postgres 9.0.3 Sethu Prasad
• 08:55   Re: Linux: more cores = less concurrency. Glyn Astill
• 08:57   Re: Linux: more cores = less concurrency. Glyn Astill
• 08:59   Re: performance problem with LIMIT (order BY in DESC order). Wrong index used? Dieter Rehbein
• 09:07   Re: performance problem with LIMIT (order BY in DESC order). Wrong index used? Claudio Freire
• 09:33   Re: performance problem with LIMIT (order BY in DESC order). Wrong index used? tv@fuzzy.cz
• 09:36   Re: performance problem with LIMIT (order BY in DESC order). Wrong index used? Dieter Rehbein
• 12:35   Re: Linux: more cores = less concurrency. Glyn Astill
• 13:22   Re: Poor performance when joining against inherited tables Shaun Thomas
• 13:23   Re: Linux: more cores = less concurrency. Merlin Moncure
• 13:24   Re: Linux: more cores = less concurrency. Merlin Moncure
• 14:33   Re: Two servers - One Replicated - Same query Kevin Grittner
• 14:38   Re: performance problem with LIMIT (order BY in DESC order). Wrong index used? Tom Lane
• 14:43   Re: Linux: more cores = less concurrency. Kevin Grittner
• 16:01   Re: Linux: more cores = less concurrency. Glyn Astill
• 16:07   Re: Linux: more cores = less concurrency. Glyn Astill
• 16:12   Re: Linux: more cores = less concurrency. Merlin Moncure
• 16:36   Performance Ogden
• 16:40   Re: Linux: more cores = less concurrency. Kevin Grittner
• 16:44   Re: Linux: more cores = less concurrency. Claudio Freire
• 16:59   Re: Linux: more cores = less concurrency. F. BROUARD / SQLpro
• 17:01   Re: Linux: more cores = less concurrency. Greg Smith
• 17:10   Re: Linux: more cores = less concurrency. Greg Smith
• 17:14   Re: Linux: more cores = less concurrency. Merlin Moncure
• 17:19   Re: Performance Andreas Kretschmer
• 17:23   Re: Performance Ogden
• 18:25   Re: Performance Tomas Vondra
• 18:34   Re: Performance Ogden
• 19:26   Re: Linux: more cores = less concurrency. Strange, John W
• 21:10   Re: Performance Tomas Vondra
• 21:21   Re: Performance Ogden
• 22:37   Re: Performance Tomas Vondra
• 23:31   poor execution plan because column dependence Václav Ovsík

13 April 2011

• 00:18   Re: poor execution plan because column dependence Bob Lunney
• 00:52   Re: poor execution plan because column dependence Tom Lane
• 07:56   Re: poor execution plan because column dependence Václav Ovsík
• 08:24   Re: poor execution plan because column dependence Václav Ovsík
• 09:48   Re: Linux: more cores = less concurrency. Glyn Astill
• 14:05   Re: Performance Ogden
• 14:15   Re: Performance tv@fuzzy.cz
• 14:32   Re: Performance Kevin Grittner
• 16:25   Re: poor execution plan because column dependence Tom Lane
• 16:35   Re: Linux: more cores = less concurrency. Scott Carey
• 17:08   Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why? Scott Carey
• 17:22   Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why? Scott Carey
• 17:35   Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why? Tom Lane
• 18:31   Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why? Scott Carey
• 20:16   Re: Slow query postgres 8.3 Tomas Vondra
• 20:19   Re: how explain works to Mr Nathan Boley Tomas Vondra
• 21:18   Re: Performance Claudio Freire
• 21:37   Re: Slow query postgres 8.3 Claudio Freire
• 21:52   Re: Performance Tom Lane
• 21:55   Re: Performance Claudio Freire
• 21:59   Re: Performance Kevin Grittner
• 22:05   Re: Performance Nathan Boley
• 22:15   Re: Performance Kevin Grittner
• 22:19   Re: Performance Tomas Vondra
• 23:10   Re: Performance Claudio Freire
• 23:26   Re: Performance Tomas Vondra

14 April 2011

• 00:03   Re: Performance Tom Lane
• 00:37   Re: Performance Joshua D. Drake
• 03:39   Re: Performance Scott Marlowe
• 04:23   Re: Linux: more cores = less concurrency. Greg Smith
• 06:50   Re: Performance Claudio Freire
• 08:12   Re: poor execution plan because column dependence Václav Ovsík
• 08:23   Re: Performance tv@fuzzy.cz
• 10:10   Re: Linux: more cores = less concurrency. Florian Weimer
• 11:08   Re: Linux: more cores = less concurrency. Cédric Villemain
• 11:30   Re: Performance Cédric Villemain
• 14:11   Re: poor execution plan because column dependence Tom Lane
• 20:05   Re: Linux: more cores = less concurrency. Scott Carey
• 20:20   Re: Linux: more cores = less concurrency. Claudio Freire
• 22:43   Re: Linux: more cores = less concurrency. Scott Carey

15 April 2011

• 06:58   Re: Linux: more cores = less concurrency. Claudio Freire
• 07:59   Re: poor execution plan because column dependence Václav Ovsík
• 15:15   Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why? pasman pasmański
• 17:25   Bad Query Plan with Range Query Mark Williams
• 17:38   Re: Bad Query Plan with Range Query Kenneth Marshall
• 17:54   Re: Bad Query Plan with Range Query Kevin Grittner
• 18:08   Re: Bad Query Plan with Range Query Mark Williams
• 18:13   Re: Bad Query Plan with Range Query Kevin Grittner
• 22:32   Re: Bad Query Plan with Range Query Mark Williams

17 April 2011

• 15:30   Re: REINDEX takes half a day (and still not complete!) Phoenix Kiula
• 15:44   Re: REINDEX takes half a day (and still not complete!) Scott Marlowe
• 15:45   Re: REINDEX takes half a day (and still not complete!) Jesper Krogh
• 16:10   Re: REINDEX takes half a day (and still not complete!) Scott Marlowe
• 17:00   Re: REINDEX takes half a day (and still not complete!) Phoenix
• 18:14   Re: REINDEX takes half a day (and still not complete!) Alan Hodgson
• 18:39   Re: REINDEX takes half a day (and still not complete!) Scott Marlowe

18 April 2011

• 05:14   Re: REINDEX takes half a day (and still not complete!) Phoenix Kiula
• 05:19   Re: REINDEX takes half a day (and still not complete!) Phoenix Kiula
• 06:40   Re: REINDEX takes half a day (and still not complete!) Claudio Freire
• 06:42   Re: REINDEX takes half a day (and still not complete!) Claudio Freire
• 07:04   Re: REINDEX takes half a day (and still not complete!) Shashank Tripathi
• 07:26   Re: REINDEX takes half a day (and still not complete!) Scott Marlowe
• 07:35   Re: REINDEX takes half a day (and still not complete!) Scott Marlowe
• 07:39   Re: REINDEX takes half a day (and still not complete!) Scott Marlowe
• 07:45   Re: REINDEX takes half a day (and still not complete!) Phoenix Kiula
• 07:48   Re: REINDEX takes half a day (and still not complete!) Scott Marlowe
• 11:15   Re: REINDEX takes half a day (and still not complete!) Sethu Prasad
• 15:05   Is there a way to selective dump of records in Postgres 9.0.3? Sethu Prasad
• 15:12   Re: Is there a way to selective dump of records in Postgres 9.0.3? Nikolas Everett
• 15:16   Re: REINDEX takes half a day (and still not complete!) tv@fuzzy.cz
• 16:33   Re: Is there a way to selective dump of records in Postgres 9.0.3? Samuel Gendler
• 16:35   Re: Index use difference betweer LIKE, LIKE ANY? Robert Haas
• 16:38   Re: big distinct clause vs. group by Robert Haas
• 16:40   Re: Custom operator class costs Robert Haas
• 16:52   Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Robert Haas
• 19:16   Assessing performance of fetches John Rouillard
• 19:41   Re: Assessing performance of fetches Tom Lane
• 21:49   Re: Background fsck Pierre C
• 21:56   Re: Select in subselect vs select = any array Robert Haas
• 22:00   Re: big distinct clause vs. group by Uwe Bartels
• 22:10   How to configure a read-only database server? Stefan Keller

19 April 2011

• 08:30   Re: big distinct clause vs. group by Robert Klemme
• 08:48   Re: big distinct clause vs. group by Uwe Bartels
• 08:58   Re: How to configure a read-only database server? Robert Klemme
• 09:09   Re: big distinct clause vs. group by Robert Klemme
• 09:15   postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Laurent Laborde
• 09:22   Re: big distinct clause vs. group by Claudio Freire
• 09:28   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Laurent Laborde
• 12:11   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Greg Smith
• 12:36   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Laurent Laborde
• 12:49   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Laurent Laborde
• 13:22   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Nicholson, Brad (Toronto, ON, CA)
• 13:44   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Laurent Laborde
• 14:23   Re: Shouldn't we have a way to avoid "risky" plans? Robert Haas
• 14:29   Re: Shouldn't we have a way to avoid "risky" plans? Robert Haas
• 14:30   Re: How to configure a read-only database server? Greg Smith
• 15:54   Re: How to configure a read-only database server? philippe

20 April 2011

• 01:50   Re: Shouldn't we have a way to avoid "risky" plans? Josh Berkus
• 07:58   Re: Two different execution plans for similar requests Joby Joba
• 08:47   not using partial index Willy-Bas Loos
• 12:39   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Jeff
• 13:26   Re: not using partial index Tom Lane
• 14:01   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Laurent Laborde
• 15:40   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Shaun Thomas
• 23:49   Constraint exclusion can't process simple constant expressions? Josh Berkus

21 April 2011

• 00:49   Re: Constraint exclusion can't process simple constant expressions? Tom Lane
• 01:59   Re: Constraint exclusion can't process simple constant expressions? Josh Berkus
• 02:05   Re: Constraint exclusion can't process simple constant expressions? Brendan Jurd
• 02:13   Re: Constraint exclusion can't process simple constant expressions? Josh Berkus
• 02:14   rant ? check the BBWC mark
• 02:17   Re: Constraint exclusion can't process simple constant expressions? Brendan Jurd
• 02:18   Re: Constraint exclusion can't process simple constant expressions? Josh Berkus
• 02:45   Re: Constraint exclusion can't process simple constant expressions? Tom Lane
• 05:54   %100 CPU on Windows Server 2003 Allen Sooredoo
• 06:02   Re: %100 CPU on Windows Server 2003 Pavel Stehule
• 07:30   Re: Constraint exclusion can't process simple constant expressions? Claudio Freire
• 07:35   Re: Constraint exclusion can't process simple constant expressions? Claudio Freire
• 08:02   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Laurent Laborde
• 08:28   oom_killer Tory M Blue
• 12:37   Re: oom_killer yoshi watanabe
• 12:48   Re: oom_killer Stephen Frost
• 12:53   Re: oom_killer Claudio Freire
• 13:02   Re: oom_killer Claudio Freire
• 14:27   Re: oom_killer Merlin Moncure
• 15:52   Re: oom_killer Tory M Blue
• 15:54   Re: oom_killer Tory M Blue
• 15:58   Re: oom_killer Claudio Freire
• 16:15   Re: oom_killer Tory M Blue
• 16:37   Re: oom_killer Claudio Freire
• 17:36   Re: Constraint exclusion can't process simple constant expressions? Josh Berkus
• 20:04   Re: oom_killer Scott Marlowe
• 20:08   Re: oom_killer Tory M Blue
• 20:08   Re: oom_killer J Sisson
• 20:12   Re: oom_killer Scott Marlowe
• 20:12   Re: oom_killer Merlin Moncure

22 April 2011

• 09:21   Checkpoint execution overrun impact? drvillo
• 11:03   Re: oom_killer Cédric Villemain
• 14:04   OT (slightly) testing for data loss on an SSD drive due to power failure John Rouillard
• 16:27   Re: oom_killer Tory M Blue
• 16:34   Re: oom_killer Kevin Grittner
• 16:37   Re: oom_killer Tory M Blue
• 16:46   Re: oom_killer Cédric Villemain
• 16:46   Re: oom_killer Cédric Villemain
• 17:18   Re: oom_killer Tory M Blue
• 18:16   Re: oom_killer David Rees
• 18:22   Re: oom_killer Tory M Blue
• 19:03   Re: oom_killer Tory M Blue
• 19:19   Re: oom_killer Cédric Villemain
• 21:53   Re: postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1 Marinos Yannikos
• 23:19   Re: oom_killer Claudio Freire

23 April 2011

• 02:47   Re: OT (slightly) testing for data loss on an SSD drive due to power failure Greg Smith
• 15:45   Re: not using partial index Henry
• 16:09   Re: How to configure a read-only database server? Robert Haas
• 16:11   Re: Shouldn't we have a way to avoid "risky" plans? Robert Haas
• 19:24   Re: oom_killer Robert Haas
• 19:33   Re: big distinct clause vs. group by Robert Haas
• 19:44   Re: REINDEX takes half a day (and still not complete!) Robert Haas
• 19:47   Issue with partition elimination Paul Pierce

24 April 2011

• 04:22   Re: oom_killer Tory M Blue
• 09:39   Re: How to configure a read-only database server? Stefan Keller
• 12:37   Re: How to configure a read-only database server? Tomas Vondra
• 19:01   Re: big distinct clause vs. group by Uwe Bartels

25 April 2011

• 14:22   Re: big distinct clause vs. group by Віталій Тимчишин
• 18:11   Re: Issue with partition elimination Josh Berkus
• 19:01   Re: big distinct clause vs. group by Uwe Bartels
• 19:31   Time to put theory to the test? J Sisson
• 23:44   Re: %100 CPU on Windows Server 2003 Robert Haas
• 23:54   Re: Slow deleting tables with foreign keys Robert Haas

26 April 2011

• 03:11   Re: Time to put theory to the test? Rob Wultsch
• 05:30   Re: Performance Robert Haas
• 05:34   Re: Performance Robert Haas
• 06:31   Re: Time to put theory to the test? Mark Kirkwood
• 07:49   Re: Performance Claudio Freire
• 14:44   Re: Time to put theory to the test? J Sisson
• 15:07   Re: Time to put theory to the test? Kevin Grittner
• 15:08   Re: Time to put theory to the test? Scott Marlowe
• 15:20   tuning on ec2 Joel Reymont
• 15:21   optimizing a cpu-heavy query Joel Reymont
• 15:24   Re: Time to put theory to the test? 
• 15:51   Re: Time to put theory to the test? Tom Lane
• 15:54   Re: Time to put theory to the test? Magnus Hagander
• 17:04   Re: Time to put theory to the test? Kenneth Marshall
• 17:57   Re: Time to put theory to the test? Josh Berkus
• 18:54   Re: Performance Tomas Vondra
• 20:15   reducing random_page_cost from 4 to 2 to force index scan Sok Ann Yap
• 21:37   Re: reducing random_page_cost from 4 to 2 to force index scan Kevin Grittner

27 April 2011

• 01:04   Re: reducing random_page_cost from 4 to 2 to force index scan Merlin Moncure
• 07:22   Re: reducing random_page_cost from 4 to 2 to force index scan Claudio Freire
• 07:23   Re: reducing random_page_cost from 4 to 2 to force index scan Claudio Freire
• 12:41   Re: reducing random_page_cost from 4 to 2 to force index scan Kevin Grittner
• 15:28   Query Performance with Indexes on Integer type vs. Date type. Dhimant Patel
• 16:12   Re: Query Performance with Indexes on Integer type vs. Date type. Tom Lane
• 16:12   Re: Query Performance with Indexes on Integer type vs. Date type. Maciek Sakrejda
• 16:18   Re: Query Performance with Indexes on Integer type vs. Date type. Kevin Grittner
• 16:46   Re: Query Performance with Indexes on Integer type vs. Date type. Phoenix Kiula
• 18:34   Re: Query Performance with Indexes on Integer type vs. Date type. Dhimant Patel
• 18:50   Re: Performance Greg Smith
• 18:57   Re: Performance Kevin Grittner
• 20:29   Re: Performance Robert Haas
• 20:33   Re: Performance Robert Haas
• 20:36   Re: index usage on queries on inherited tables Robert Haas
• 20:44   Re: Performance Tomas Vondra
• 21:01   Re: Performance Claudio Freire
• 21:42   Re: index usage on queries on inherited tables Joseph Shraibman
• 21:55   Re: Performance Greg Smith
• 23:23   Re: reducing random_page_cost from 4 to 2 to force index scan Kevin Grittner

28 April 2011

• 00:59   Re: index usage on queries on inherited tables Samuel Gendler
• 02:18   Re: index usage on queries on inherited tables Greg Smith
• 06:19   Re: reducing random_page_cost from 4 to 2 to force index scan Sok Ann Yap
• 06:19   Re: reducing random_page_cost from 4 to 2 to force index scan Sok Ann Yap
• 06:19   VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql? HSIEN-WEN CHU
• 06:19   Re: reducing random_page_cost from 4 to 2 to force index scan Sok Ann Yap
• 08:03   Re: Performance Sethu Prasad
• 09:20   Order of tables Rishabh Kumar Jain
• 11:32   Re: reducing random_page_cost from 4 to 2 to force index scan Samuel Gendler
• 12:31   Re: Order of tables Robert Klemme
• 12:33   Re: Order of tables Heikki Linnakangas
• 15:56   Re: reducing random_page_cost from 4 to 2 to force index scan Jeff Janes

29 April 2011

• 00:13   Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql? Greg Smith
• 00:22   Re: Performance Tomas Vondra
• 04:58   Re: Performance Joshua Berkus
• 07:13   Will shared_buffers crash a server Qiang Wang
• 07:42   Re: Will shared_buffers crash a server Claudio Freire
• 07:48   Re: Will shared_buffers crash a server Achilleas Mantzios
• 08:35   Re: Performance James Mansion
• 10:34   Re: Will shared_buffers crash a server Scott Marlowe
• 11:07   Re: Order of tables Rishabh Kumar Jain
• 14:24   FUSION-IO io cards Mark Steben
• 14:33   Re: FUSION-IO io cards Stephen Cook
• 14:41   Re: FUSION-IO io cards Ivan Voras
• 14:45   Re: FUSION-IO io cards 
• 14:54   Re: FUSION-IO io cards Ben Chobot
• 15:25   Re: FUSION-IO io cards Tyler Mills
• 15:40   Re: {Spam} Will shared_buffers crash a server French, Martin
• 15:40   pgpoolAdmin handling several pgpool-II clusters Jorgen
• 16:34   Re: FUSION-IO io cards Joachim Worringen
• 16:52   Re: FUSION-IO io cards 
• 18:29   8.4.7, incorrect estimate Wayne Conrad
• 18:56   Re: Performance Greg Smith
• 19:03   Re: FUSION-IO io cards Greg Smith
• 19:13   Re: 8.4.7, incorrect estimate Kevin Grittner
• 19:15   Re: FUSION-IO io cards Joachim Worringen
• 19:34   Re: 8.4.7, incorrect estimate Kevin Grittner
• 20:23   Re: Performance Andy Colson
• 20:27   Re: Performance James Mansion
• 20:58   Re: 8.4.7, incorrect estimate Tom Lane
• 22:00   Re: Performance Greg Smith
• 22:08   Re: Performance Claudio Freire
• 22:53   Re: index usage on queries on inherited tables Robert Haas
• 23:00   Re: Performance Robert Haas
• 23:02   Re: Performance Robert Haas

30 April 2011

• 01:28   Re: pgpoolAdmin handling several pgpool-II clusters Tatsuo Ishii
• 04:46   Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql? Greg Smith
• 08:08   Re: REINDEX takes half a day (and still not complete!) Greg Smith
• 09:26   Re: REINDEX takes half a day (and still not complete!) Phoenix Kiula
• 14:34   Re: REINDEX takes half a day (and still not complete!) Kenneth Marshall
• 16:57   stored proc and inserting hundreds of thousands of rows Joel Reymont
• 17:28   Re: stored proc and inserting hundreds of thousands of rows Kevin Grittner
• 18:01   Re: stored proc and inserting hundreds of thousands of rows Joel Reymont
• 18:13   Re: stored proc and inserting hundreds of thousands of rows Pierre C
• 18:19   Re: stored proc and inserting hundreds of thousands of rows Joel Reymont
• 18:24   Re: stored proc and inserting hundreds of thousands of rows Kevin Grittner
• 18:37   Re: stored proc and inserting hundreds of thousands of rows Kevin Grittner
• 21:15   Re: stored proc and inserting hundreds of thousands of rows Joel Reymont
• 21:23   Re: stored proc and inserting hundreds of thousands of rows Joel Reymont
• 22:12   Re: stored proc and inserting hundreds of thousands of rows Jeff Janes
• 22:29   Re: stored proc and inserting hundreds of thousands of rows Joel Reymont