Mailing lists [pgsql-performance]

1 March 2011

• 00:48   Re: Load and Stress on PostgreSQL 9.0 Selva manickaraja
• 05:20   Re: inheritance: planning time vs children number vs column number Tom Lane
• 06:42   Re: inheritance: planning time vs children number vs column number Marc Cousin
• 07:46   Two different execution plans for similar requests Joby Joba
• 08:10   Re: Two different execution plans for similar requests tv@fuzzy.cz
• 08:25   Re: Two different execution plans for similar requests Joby Joba
• 08:41   Re: Two different execution plans for similar requests tv@fuzzy.cz
• 11:38   Re: Two different execution plans for similar requests Joby Joba
• 11:44   Re: Two different execution plans for similar requests Joby Joba
• 14:34   Re: inheritance: planning time vs children number vs column number Tom Lane
• 14:37   Re: Talking about optimizer, my long dream Merlin Moncure
• 14:39   Re: inheritance: planning time vs children number vs column number Marc Cousin
• 16:07   Re: Two different execution plans for similar requests Maciek Sakrejda
• 16:34   Re: inheritance: planning time vs children number vs column number Tom Lane
• 23:30   Performance trouble finding records through related records sverhagen

2 March 2011

• 02:41   Re: Performance trouble finding records through related records Andy Colson
• 13:08   Re: Pushing IN (subquery) down through UNION ALL? Robert Haas
• 13:12   Re: Pushing IN (subquery) down through UNION ALL? Thom Brown
• 13:22   Re: Pushing IN (subquery) down through UNION ALL? Robert Haas
• 13:26   Re: Pushing IN (subquery) down through UNION ALL? Thom Brown
• 14:29   Re: Anyone tried Flashcache with PostgreSQL? Robert Haas
• 14:40   Re: Query on view radically slower than query on underlying table Robert Haas
• 14:45   Re: Vacuum problem due to temp tables Robert Haas
• 17:19   Re: Performance Test for PostgreSQL9 Robert Haas
• 17:30   Re: Performance Test for PostgreSQL9 Joshua D. Drake
• 23:12   Re: Performance trouble finding records through related records sverhagen
• 23:20   Re: Anyone tried Flashcache with PostgreSQL? Samuel Gendler

3 March 2011

• 00:46   Re: Performance Test for PostgreSQL9 Selva manickaraja
• 02:04   Re: Performance trouble finding records through related records Andy Colson
• 03:01   Re: Performance Test for PostgreSQL9 Greg Smith
• 03:27   Is it require further tuning Adarsh Sharma
• 04:16   Re: Performance Test for PostgreSQL9 Selva manickaraja
• 04:20   Re: Performance Test for PostgreSQL9 Joshua D. Drake
• 07:21   Re: Anyone tried Flashcache with PostgreSQL? Arjen van der Meijden
• 08:07   Re: Is Query need to be optimized Grzegorz Jaśkiewicz
• 08:19   Re: Performance trouble finding records through related records sverhagen
• 13:20   Slowing UPDATEs inside a transaction Matt Burke
• 13:26   Re: Slowing UPDATEs inside a transaction Robert Haas
• 13:55   Re: Performance trouble finding records through related records Andy Colson
• 14:23   Re: Slowing UPDATEs inside a transaction Merlin Moncure

4 March 2011

• 08:22   Re: Slowing UPDATEs inside a transaction Matt Burke
• 09:26   Re: Vacuum problem due to temp tables Vidhya Bondre
• 11:01   Slow join on partitioned table Mark Thornton
• 13:14   Re: Vacuum problem due to temp tables Robert Haas
• 13:21   Re: Slowing UPDATEs inside a transaction Robert Haas
• 13:51   Re: Slowing UPDATEs inside a transaction Merlin Moncure
• 13:55   Re: Is it require further tuning Robert Haas
• 14:18   Calculating 95th percentiles Landreville
• 15:08   Re: Slow join on partitioned table Robert Haas
• 15:47   Re: Slow join on partitioned table Mark Thornton
• 16:00   Re: Slow join on partitioned table Mark Thornton
• 16:34   Linux I/O schedulers - CFQ & random seeks Glyn Astill
• 17:03   Re: Linux I/O schedulers - CFQ & random seeks Wayne Conrad
• 17:06   Re: Slow join on partitioned table Robert Haas
• 17:48   Re: Linux I/O schedulers - CFQ & random seeks Dan Harris
• 18:02   Re: Linux I/O schedulers - CFQ & random seeks Scott Marlowe
• 18:07   Re: Linux I/O schedulers - CFQ & random seeks Kevin Grittner
• 18:09   Re: Linux I/O schedulers - CFQ & random seeks Rosser Schwarz

5 March 2011

• 07:01   Re: Calculating 95th percentiles Pierre C
• 08:37   Table partitioning Tobias Brox
• 08:59   Re: Table partitioning Mark Thornton
• 09:10   Re: Table partitioning Tobias Brox
• 23:35   Re: Calculating 95th percentiles marcin mank
• 23:39   Re: Linux I/O schedulers - CFQ & random seeks Omar Kilani

6 March 2011

• 11:26   Re: Table partitioning Mark Thornton

7 March 2011

• 12:47   Performance issues Andreas Forø Tollefsen
• 13:01   Re: Performance issues Kenneth Marshall
• 13:17   Re: Performance issues Andreas Forø Tollefsen
• 13:22   Re: Performance issues Kenneth Marshall
• 13:29   Re: Performance issues Andreas Forø Tollefsen
• 14:34   Re: Performance issues Oleg Bartunov
• 14:48   Re: Anyone tried Flashcache with PostgreSQL? Cédric Villemain
• 18:15   plan variations: join vs. exists vs. row comparison Jon Nelson
• 18:26   Re: Performance trouble finding records through related records Robert Haas
• 19:00   Re: plan variations: join vs. exists vs. row comparison Tom Lane
• 19:05   Re: plan variations: join vs. exists vs. row comparison Merlin Moncure
• 19:07   Re: plan variations: join vs. exists vs. row comparison Jon Nelson
• 19:24   Re: plan variations: join vs. exists vs. row comparison Kevin Grittner
• 19:27   Re: Performance trouble finding records through related records Merlin Moncure
• 19:41   Re: Query performance with disabled hashjoin and mergejoin Merlin Moncure
• 20:50   Re: Performance issues Andreas Forø Tollefsen
• 22:29   Re: Performance issues David Kerr
• 23:38   Re: Performance issues Tom Lane

8 March 2011

• 03:56   How to tune this query Adarsh Sharma
• 05:43   Re: [GENERAL] How to tune this query Jaiswal Dhaval Sudhirkumar
• 07:42   Re: Performance issues Andreas Forø Tollefsen
• 10:17   Re: Performance trouble finding records through related records sverhagen
• 10:31   Re: Performance trouble finding records through related records sverhagen
• 14:21   Re: Performance issues Andy Colson
• 14:55   Table partitioning problem Samba GUEYE
• 15:59   Re: Performance issues Andreas Forø Tollefsen
• 16:25   Re: Performance issues Andreas Forø Tollefsen
• 17:33   Re: Linux I/O schedulers - CFQ & random seeks Mindaugas Riauba
• 18:13   Re: Performance issues Andy Colson
• 19:57   Re: Query performance with disabled hashjoin and mergejoin Robert Haas
• 20:24   Re: Query performance with disabled hashjoin and mergejoin Tom Lane
• 20:57   Re: Query performance with disabled hashjoin and mergejoin Merlin Moncure

9 March 2011

• 15:48   Re: Query performance with disabled hashjoin and mergejoin Robert Haas
• 21:02   Re: Table partitioning problem Jim Nasby
• 21:43   Re: Slow join on partitioned table Conor Walsh
• 22:01   Re: NULLS LAST performance Jim Nasby

10 March 2011

• 07:25   Re: Table partitioning problem Samba GUEYE
• 13:10   Re: Performance trouble finding records through related records sverhagen
• 14:55   Re: NULLS LAST performance Robert Haas
• 15:10   Tuning massive UPDATES and GROUP BY's? fork
• 15:33   Re: NULLS LAST performance Merlin Moncure
• 15:45   Re: Tuning massive UPDATES and GROUP BY's? Merlin Moncure
• 15:56   Basic performance tuning on dedicated server runner
• 15:56   unexpected stable function behavior Julius Tuskenis
• 17:02   Re: Basic performance tuning on dedicated server Merlin Moncure
• 17:05   Re: Tuning massive UPDATES and GROUP BY's? fork
• 20:15   Re: unexpected stable function behavior Merlin Moncure
• 20:42   big joins not converging Dan Ancona
• 21:13   Re: big joins not converging Steve Atkins
• 21:49   Re: Tuning massive UPDATES and GROUP BY's? Marti Raudsepp
• 22:49   Re: big joins not converging fork
• 23:43   Re: big joins not converging Dan Ancona

11 March 2011

• 03:46   Re: NULLS LAST performance Robert Haas
• 15:23   ANTI-JOIN needs table, index scan not possible? hans wulf
• 15:47   Re: big joins not converging fork
• 16:18   Re: ANTI-JOIN needs table, index scan not possible? Maciek Sakrejda
• 17:31   Re: Table partitioning problem Robert Haas
• 18:07   Re: Tuning massive UPDATES and GROUP BY's? fork
• 21:10   Re: ANTI-JOIN needs table, index scan not possible? hans wulf
• 21:16   Re: ANTI-JOIN needs table, index scan not possible? Kenneth Marshall
• 21:32   Re: ANTI-JOIN needs table, index scan not possible? Kevin Grittner

12 March 2011

• 16:08   Re: Tuning massive UPDATES and GROUP BY's? Marti Raudsepp

13 March 2011

• 10:31   Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1 John Surcombe
• 12:41   Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1 Jeremy
• 16:24   Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1 Tom Lane
• 16:42   Re: Tuning massive UPDATES and GROUP BY's? runner
• 22:10   Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1 Tom Lane

14 March 2011

• 10:18   Re: Tuning massive UPDATES and GROUP BY's? Marti Raudsepp
• 13:34   Re: Tuning massive UPDATES and GROUP BY's? Greg Spiegelberg
• 13:41   Re: unexpected stable function behavior Merlin Moncure
• 14:08   Re: unexpected stable function behavior Andres Freund
• 15:56   Re: Performance regression from 8.3.7 to 9.0.3 Claudio Freire
• 15:56   Re: Tuning massive UPDATES and GROUP BY's? runner
• 16:42   Re: Table partitioning problem Samba GUEYE
• 16:54   Re: unexpected stable function behavior Julius Tuskenis
• 16:54   Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1 John Surcombe
• 17:17   Re: unexpected stable function behavior Tom Lane
• 17:24   Bug in the planner? Claudio Freire
• 17:24   Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1 Tom Lane
• 17:34   Re: Performance regression from 8.3.7 to 9.0.3 Merlin Moncure
• 18:00   Re: Performance regression from 8.3.7 to 9.0.3 Merlin Moncure
• 18:51   Re: Performance regression from 8.3.7 to 9.0.3 Tom Lane
• 19:40   Re: Table partitioning problem Robert Haas
• 20:22   Re: Table partitioning problem Conor Walsh

15 March 2011

• 00:56   Re: Bug in the planner? Tom Lane
• 08:04   Re: unexpected stable function behavior Julius Tuskenis
• 08:12   Re: unexpected stable function behavior Julius Tuskenis
• 10:10   Re: Table partitioning problem Samba GUEYE
• 12:30   Re: Index use difference betweer LIKE, LIKE ANY? Chetan Suttraway
• 13:18   Re: Table partitioning problem Shaun Thomas
• 15:20   Re: Table partitioning problem Samba GUEYE

16 March 2011

• 08:45   big distinct clause vs. group by Uwe Bartels
• 14:10   Custom operator class costs Ben Beecher
• 16:17   pg_xlog size Tech Madhu
• 16:17   Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Timothy Garnett
• 16:17   Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Timothy Garnett
• 16:17   Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Timothy Garnett
• 16:17   Help with Query Tuning Adarsh Sharma
• 16:37   Re: Help with Query Tuning Kenneth Marshall
• 16:41   Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Kevin Grittner
• 17:02   Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Tom Lane
• 17:05   Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Shaun Thomas
• 17:24   Re: Help with Query Tuning Reid Thompson
• 17:27   Re: pg_xlog size Euler Taveira de Oliveira
• 17:38   Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Tom Lane
• 17:44   Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Kevin Grittner
• 18:35   Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Shaun Thomas
• 18:39   Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Claudio Freire
• 19:41   Updating histogram_bounds after a delete Derrick Rice
• 19:42   Re: Updating histogram_bounds after a delete Derrick Rice
• 19:42   Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Kevin Grittner
• 21:56   Re: Updating histogram_bounds after a delete Kevin Grittner

17 March 2011

• 03:09   Re: pg_xlog size Fujii Masao
• 04:51   Re: Help with Query Tuning Adarsh Sharma
• 06:20   Re: Help with Query Tuning Adarsh Sharma
• 09:35   Re: Help with Query Tuning tv@fuzzy.cz
• 09:36   Re: pg_xlog size Tech Madhu
• 13:27   Re: Updating histogram_bounds after a delete Derrick Rice
• 14:50   Re: Updating histogram_bounds after a delete Kevin Grittner
• 14:55   Re: Updating histogram_bounds after a delete Kenneth Marshall
• 15:01   Re: Updating histogram_bounds after a delete Tom Lane
• 15:05   Re: Updating histogram_bounds after a delete Kevin Grittner
• 16:14   Xeon twice the performance of opteron Jeff
• 16:42   Re: Xeon twice the performance of opteron J Sisson
• 16:51   Re: Xeon twice the performance of opteron Claudio Freire
• 17:29   Re: Xeon twice the performance of opteron Craig James
• 17:56   Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Timothy Garnett
• 18:14   Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Kevin Grittner
• 23:20   Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3 Timothy Garnett
• 23:20   Fastest pq_restore? Michael Andreasen

18 March 2011

• 00:58   Request for feedback on hardware for a new database server Oliver Charles
• 01:08   Re: Fastest pq_restore? Andy Colson
• 01:24   Re: Xeon twice the performance of opteron mark
• 01:39   Re: Xeon twice the performance of opteron Scott Marlowe
• 02:05   Re: Request for feedback on hardware for a new database server Steve Atkins
• 03:02   Re: Request for feedback on hardware for a new database server Scott Marlowe
• 04:12   Re: Help with Query Tuning Adarsh Sharma
• 06:19   Re: Request for feedback on hardware for a new database server Jesper Krogh
• 06:58   Disabling nested loops - worst case performance Anssi Kääriäinen
• 07:02   Re: Disabling nested loops - worst case performance Pavel Stehule
• 07:17   Re: Request for feedback on hardware for a new database server Arjen van der Meijden
• 09:11   Re: Request for feedback on hardware for a new database server Scott Marlowe
• 10:41   Re: Disabling nested loops - worst case performance Anssi Kääriäinen
• 10:52   Re: Disabling nested loops - worst case performance Vitalii Tymchyshyn
• 11:14   Re: Disabling nested loops - worst case performance Thomas Kellerer
• 11:41   Re: Disabling nested loops - worst case performance Anssi Kääriäinen
• 12:01   Re: Disabling nested loops - worst case performance Anssi Kääriäinen
• 12:15   Re: Xeon twice the performance of opteron Jeff
• 12:45   Re: Request for feedback on hardware for a new database server Arjen van der Meijden
• 14:05   Re: Help with Query Tuning Reid Thompson
• 14:08   Help: massive parallel update to the same table Red Maple
• 14:28   Re: Help: massive parallel update to the same table Kevin Grittner
• 14:34   Re: Help: massive parallel update to the same table Nicholson, Brad (Toronto, ON, CA)
• 14:38   Re: Fastest pq_restore? Kevin Grittner
• 15:26   Re: Disabling nested loops - worst case performance Claudio Freire
• 15:30   Re: Help with Query Tuning tv@fuzzy.cz
• 16:02   Re: Request for feedback on hardware for a new database server Claudio Freire
• 16:07   Re: Help: massive parallel update to the same table Kevin Grittner
• 16:32   Re: Request for feedback on hardware for a new database server Scott Marlowe
• 18:21   Re: Help: massive parallel update to the same table Red Maple
• 19:10   Re: Fastest pq_restore? Andy Colson
• 19:21   Re: Help: massive parallel update to the same table Kevin Grittner
• 20:29   Re: Request for feedback on hardware for a new database server Scott Marlowe

19 March 2011

• 03:07   REINDEX takes half a day (and still not complete!) Phoenix Kiula
• 04:58   Re: REINDEX takes half a day (and still not complete!) Scott Marlowe
• 05:30   Re: REINDEX takes half a day (and still not complete!) Scott Marlowe
• 09:00   Performance on AIX phb07
• 13:17   Re: Performance on AIX Andy Colson
• 16:58   Re: Fastest pq_restore? bricklen

20 March 2011

• 06:47   Select in subselect vs select = any array Adam Tistler
• 06:52   Re: Select in subselect vs select = any array Pavel Stehule
• 08:04   Re: REINDEX takes half a day (and still not complete!) Phoenix Kiula

21 March 2011

• 03:21   Re: Select in subselect vs select = any array Adam Tistler
• 05:56   Re: Select in subselect vs select = any array Pavel Stehule
• 06:17   Re: Select in subselect vs select = any array Adam Tistler
• 06:39   Re: Select in subselect vs select = any array Pavel Stehule
• 13:28   Re: REINDEX takes half a day (and still not complete!) Merlin Moncure

22 March 2011

• 02:48   Re: REINDEX takes half a day (and still not complete!) Scott Marlowe
• 02:56   Re: Select in subselect vs select = any array mark
• 13:54   Re: Request for feedback on hardware for a new database server Merlin Moncure
• 14:13   Re: Help: massive parallel update to the same table Red Maple
• 18:41   Analyze on temp table taking very long Mahadevan, Mridula
• 21:29   Re: Performance on AIX Josh Berkus
• 22:57   Re: Analyze on temp table taking very long Tom Lane

23 March 2011

• 00:53   good old VACUUM FULL felix
• 04:25   Re: good old VACUUM FULL Chris
• 04:32   Re: ANTI-JOIN needs table, index scan not possible? Robert Haas
• 06:17   Re: good old VACUUM FULL Scott Marlowe
• 06:23   Reason of Slowness of query Adarsh Sharma
• 07:17   Re: Reason of Slowness of query Chetan Suttraway
• 07:21   Re: Reason of Slowness of query Samuel Gendler
• 07:25   Re: Reason of Slowness of query Vitalii Tymchyshyn
• 07:25   Re: Reason of Slowness of query Adarsh Sharma
• 07:26   Re: Reason of Slowness of query Chetan Suttraway
• 08:51   Re: Reason of Slowness of query Vitalii Tymchyshyn
• 09:13   Re-Reason of Slowness of Query Adarsh Sharma
• 09:27   Re: Re-Reason of Slowness of Query Vitalii Tymchyshyn
• 10:05   Re: Re-Reason of Slowness of Query Adarsh Sharma
• 10:12   Re: Re-Reason of Slowness of Query Vitalii Tymchyshyn
• 10:14   Re: Re-Reason of Slowness of Query Adarsh Sharma
• 10:37   Re: Re-Reason of Slowness of Query Vitalii Tymchyshyn
• 10:38   Re: Re-Reason of Slowness of Query tv@fuzzy.cz
• 10:40   Re: Re-Reason of Slowness of Query Chetan Suttraway
• 10:51   Re: Re-Reason of Slowness of Query Chetan Suttraway
• 11:16   Re: Re-Reason of Slowness of Query Adarsh Sharma
• 11:21   Re: Re-Reason of Slowness of Query Vitalii Tymchyshyn
• 11:24   Re: Re-Reason of Slowness of Query Chetan Suttraway
• 11:26   Re: Re-Reason of Slowness of Query Adarsh Sharma
• 11:34   Re: Re-Reason of Slowness of Query Adarsh Sharma
• 11:52   Re: Re-Reason of Slowness of Query tv@fuzzy.cz
• 12:51   buffercache/bgwriter Uwe Bartels
• 13:13   Re: good old VACUUM FULL Shaun Thomas
• 13:20   Re: buffercache/bgwriter Jochen Erwied
• 13:34   Re: Re-Reason of Slowness of Query Shaun Thomas
• 13:40   Re: buffercache/bgwriter Uwe Bartels
• 14:16   Re: Re-Reason of Slowness of Query tv@fuzzy.cz
• 14:20   Re: Re-Reason of Slowness of Query Shaun Thomas
• 14:42   Re: buffercache/bgwriter tv@fuzzy.cz
• 14:54   Re: buffercache/bgwriter Uwe Bartels
• 15:00   Re: buffercache/bgwriter Nicholson, Brad (Toronto, ON, CA)
• 15:26   Re: buffercache/bgwriter Uwe Bartels
• 15:40   Re: buffercache/bgwriter Jeff Janes
• 16:16   Re: buffercache/bgwriter Uwe Bartels
• 16:16   Re: buffercache/bgwriter Jeff Janes
• 17:12   Shouldn't we have a way to avoid "risky" plans? Josh Berkus
• 17:37   Re: Shouldn't we have a way to avoid "risky" plans? Claudio Freire
• 20:24   Re: buffercache/bgwriter Cédric Villemain
• 20:29   Re: Shouldn't we have a way to avoid "risky" plans? Josh Berkus
• 20:35   Slow query on CLUTER -ed tables Laszlo Nagy
• 20:46   Re: Shouldn't we have a way to avoid "risky" plans? Claudio Freire
• 21:00   Re: Shouldn't we have a way to avoid "risky" plans? Justin Pitts
• 21:00   Re: Shouldn't we have a way to avoid "risky" plans? Tom Lane
• 21:08   Re: Shouldn't we have a way to avoid "risky" plans? Claudio Freire
• 21:56   Re: Slow query on CLUTER -ed tables Marti Raudsepp

24 March 2011

• 00:06   Re: Shouldn't we have a way to avoid "risky" plans? Josh Berkus
• 02:04   pg9.0.3 explain analyze running very slow compared to a different box with much less configuration DM
• 05:05   Re: Re-Reason of Slowness of Query Adarsh Sharma
• 08:44   Re: Shouldn't we have a way to avoid "risky" plans? Віталій Тимчишин
• 09:11   Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration Achilleas Mantzios
• 09:19   Re: buffercache/bgwriter Uwe Bartels
• 11:40   Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration Marti Raudsepp
• 12:07   Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration Achilleas Mantzios
• 13:56   maintenance_work_mem + create index Uwe Bartels
• 14:13   Re: maintenance_work_mem + create index Stephen Frost
• 14:40   Re: maintenance_work_mem + create index Uwe Bartels
• 15:15   Re: maintenance_work_mem + create index Shaun Thomas
• 15:29   Re: maintenance_work_mem + create index Uwe Bartels
• 15:39   Re: maintenance_work_mem + create index Shaun Thomas
• 17:35   Re: maintenance_work_mem + create index Euler Taveira de Oliveira
• 19:31   Re: Shouldn't we have a way to avoid "risky" plans? Merlin Moncure
• 20:31   Re: Shouldn't we have a way to avoid "risky" plans? Nathan Boley
• 22:23   Re: Shouldn't we have a way to avoid "risky" plans? Claudio Freire

25 March 2011

• 01:12   Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration DM
• 06:31   Why Index is not used Adarsh Sharma
• 06:44   Re: Why Index is not used Andreas Kretschmer
• 06:47   Re: Why Index is not used Adarsh Sharma
• 06:56   Re: Why Index is not used Chetan Suttraway
• 07:04   Re: Why Index is not used Adarsh Sharma
• 07:24   Re: Why Index is not used Thomas Kellerer
• 08:14   Re: Why Index is not used Chetan Suttraway
• 08:30   Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration Marti Raudsepp
• 08:50   Re: Why Index is not used Adarsh Sharma
• 09:08   Re: Why Index is not used Chetan Suttraway
• 09:30   Re: Why Index is not used tv@fuzzy.cz
• 09:43   Re: Shouldn't we have a way to avoid "risky" plans? Vitalii Tymchyshyn
• 09:48   Re: Why Index is not used Adarsh Sharma
• 12:24   Re: Slow query on CLUTER -ed tables Laszlo Nagy
• 13:25   Re: Why Index is not used Shaun Thomas
• 14:12   Re: Shouldn't we have a way to avoid "risky" plans? Tom Lane
• 14:24   Re: Shouldn't we have a way to avoid "risky" plans? Tom Lane
• 14:32   Re: pg9.0.3 explain analyze running very slow compared to a different box with much less configuration Strange, John W
• 14:41   Re: Shouldn't we have a way to avoid "risky" plans? Vitalii Tymchyshyn
• 16:49   Re: Why Index is not used Maciek Sakrejda
• 18:02   Re: Shouldn't we have a way to avoid "risky" plans? Scott Carey
• 22:43   Re: Shouldn't we have a way to avoid "risky" plans? Nathan Boley

26 March 2011

• 01:03   Re: Shouldn't we have a way to avoid "risky" plans? Joshua Berkus

28 March 2011

• 06:18   Re: buffercache/bgwriter Greg Smith
• 06:21   Re: Xeon twice the performance of opteron Greg Smith
• 20:21   Intel SSDs that may not suck Greg Smith
• 20:23   Re: buffercache/bgwriter Uwe Bartels
• 23:55   Re: Intel SSDs that may not suck Andy

29 March 2011

• 04:14   Re: Intel SSDs that may not suck Merlin Moncure
• 04:55   Re: Intel SSDs that may not suck Jesper Krogh
• 05:02   Re: Intel SSDs that may not suck Scott Marlowe
• 07:22   Re: Analyze on temp table taking very long Mahadevan, Mridula
• 07:22   Re: Intel SSDs that may not suck Justin Pitts
• 10:34   Re: Intel SSDs that may not suck Yeb Havinga
• 14:17   Re: Intel SSDs that may not suck Jeff
• 14:31   Re: Intel SSDs that may not suck Cédric Villemain
• 14:33   Re: Intel SSDs that may not suck Jeff
• 15:07   very long updates very small tables Lars Feistner
• 15:37   Re: Intel SSDs that may not suck Strange, John W
• 16:12   Re: Intel SSDs that may not suck Jesper Krogh
• 16:51   Re: Intel SSDs that may not suck Jeff
• 16:58   Re: Intel SSDs that may not suck 
• 19:28   Re: Intel SSDs that may not suck Greg Smith
• 20:06   Re: very long updates very small tables Kevin Grittner
• 20:13   Re: Intel SSDs that may not suck Jesper Krogh
• 22:18   multiple table scan performance Samuel Gendler
• 22:28   Re: multiple table scan performance Claudio Freire

30 March 2011

• 00:05   Re: multiple table scan performance Marti Raudsepp
• 00:12   Re: multiple table scan performance Samuel Gendler
• 01:11   Re: multiple table scan performance Craig James
• 07:35   Re: very long updates very small tables Lars Feistner
• 07:55   Re: Why Index is not used Greg Smith
• 15:24   Re: very long updates very small tables pasman pasmański
• 16:55   Re: very long updates very small tables Kevin Grittner
• 20:56   COPY with high # of clients, partitioned table locking issues? Strange, John W

31 March 2011

• 00:48   Re: COPY with high # of clients, partitioned table locking issues? Bob Lunney
• 01:31   Re: COPY with high # of clients, partitioned table locking issues? Samuel Gendler
• 02:16   Slow deleting tables with foreign keys Jeremy Palmer
• 10:43   Re: COPY with high # of clients, partitioned table locking issues? Emanuel Calvo
• 14:54   Re: Slow deleting tables with foreign keys Bob Lunney
• 16:53   Re: COPY with high # of clients, partitioned table locking issues? Maciek Sakrejda
• 17:26   Why it is using/not using index scan? Laszlo Nagy
• 17:31   Re: Calculating 95th percentiles Landreville
• 19:43   Re: Slow deleting tables with foreign keys Jeremy Palmer