Mailing lists [pgsql-performance]

1 December 2012

• 01:22   Re: shared_buffers on ubuntu precise Daniel Farina
• 01:36   Re: shared_buffers on ubuntu precise Mark Kirkwood
• 01:43   Re: Optimize update query Mark Kirkwood

2 December 2012

• 14:14   Re: Optimize update query Vitalii Tymchyshyn

3 December 2012

• 02:32   Re: Optimize update query Mark Kirkwood
• 12:37   Re: Optimize update query Niels Kristian Schjødt
• 23:40   Re: Hints (was Poor performance using CTE) Gavin Flower

4 December 2012

• 18:07   Slow query: bitmap scan troubles 
• 18:21   Re: Slow query: bitmap scan troubles 
• 18:28   Re: Slow query: bitmap scan troubles Claudio Freire
• 19:28   Re: Comparative tps question John Lister
• 20:22   Re: Slow query: bitmap scan troubles Jeff Janes
• 20:26   Re: Slow query: bitmap scan troubles Claudio Freire
• 20:47   Re: Slow query: bitmap scan troubles 
• 21:03   Re: Slow query: bitmap scan troubles 
• 21:31   Re: Slow query: bitmap scan troubles Claudio Freire
• 21:33   Re: Slow query: bitmap scan troubles Claudio Freire
• 21:50   Re: Slow query: bitmap scan troubles Vitalii Tymchyshyn
• 21:54   Re: Slow query: bitmap scan troubles 
• 21:56   Re: Slow query: bitmap scan troubles 
• 22:09   Re: Slow query: bitmap scan troubles Kevin Grittner
• 23:12   Re: Slow query: bitmap scan troubles Sergey Konoplev

5 December 2012

• 01:34   Re: Slow query: bitmap scan troubles Jeff Janes
• 02:42   Re: Slow query: bitmap scan troubles Jeff Janes
• 11:10   CREATING INDEX on column having null values suhas.basavaraj12
• 11:47   Re: CREATING INDEX on column having null values Willem Leenen
• 18:34   xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance] Andrea Suisani
• 19:51   Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance] Jean-David Beyer
• 19:56   Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance] Claudio Freire
• 20:01   Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance] Andrew Dunstan
• 20:39   Re: Slow query: bitmap scan troubles Jeff Janes
• 20:43   Re: Slow query: bitmap scan troubles Claudio Freire
• 21:05   Re: Slow query: bitmap scan troubles Tom Lane
• 21:28   Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance Shaun Thomas
• 22:39   Any idea on how to improve the statistics estimates for this plan? Guillaume Smet

6 December 2012

• 00:45   Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance Niels Kristian Schjødt
• 01:20   Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance Daniel Farina
• 01:25   Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance Shaun Thomas
• 01:41   Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance Bruce Momjian
• 02:04   Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance Shaun Thomas
• 03:54   Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance Scott Marlowe
• 10:51   Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance Stuart Bishop
• 11:29   Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance] John Lister
• 11:29   Re: Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance John Lister
• 11:44   Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance] Andrea Suisani
• 12:33   Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance] Andrea Suisani
• 14:37   Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance] John Lister
• 15:52   Re: Slow query: bitmap scan troubles 
• 15:53   Re: Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance] Andrea Suisani
• 15:56   Re: Slow query: bitmap scan troubles 
• 17:10   Re: Slow query: bitmap scan troubles 
• 20:27   Re: Slow query: bitmap scan troubles Jeff Janes
• 23:05   Re: Slow query: bitmap scan troubles Claudio Freire

7 December 2012

• 00:09   Re: Slow query: bitmap scan troubles Jeff Janes

8 December 2012

• 05:32   Re: Any idea on how to improve the statistics estimates for this plan? Jeff Janes
• 07:16   Re: Any idea on how to improve the statistics estimates for this plan? Tom Lane
• 17:51   Re: Any idea on how to improve the statistics estimates for this plan? Guillaume Smet
• 18:15   Re: Slow query: bitmap scan troubles Guillaume Lelarge
• 22:03   Re: Any idea on how to improve the statistics estimates for this plan? Jeff Janes

10 December 2012

• 03:31   Re: Slow query: bitmap scan troubles Philip Scott
• 03:31   Re: Slow query: bitmap scan troubles Philip Scott
• 03:31   Re: Slow query: bitmap scan troubles Philip Scott
• 03:31   Why is PostgreSQL 9.2 slower than 9.1 in my tests? Patryk Sidzina
• 03:35   Perform scan on Toast table classical_89
• 06:53   Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests? Jeff Janes
• 11:57   Re: Perform scan on Toast table Albe Laurenz
• 12:52   Re: Slow query: bitmap scan troubles 

11 December 2012

• 01:52   Do I have a hardware or a software problem? Niels Kristian Schjødt
• 02:00   Re: Do I have a hardware or a software problem? Evgeny Shishkin
• 02:58   Re: Do I have a hardware or a software problem? Jeff Janes
• 13:04   Re: Do I have a hardware or a software problem? Niels Kristian Schjødt
• 16:29   Re: Do I have a hardware or a software problem? Craig Ringer
• 16:35   Re: Do I have a hardware or a software problem? Niels Kristian Schjødt
• 20:16   Re: Do I have a hardware or a software problem? Evgeny Shishkin
• 20:25   Re: Do I have a hardware or a software problem? Jeff Janes
• 21:54   Re: Do I have a hardware or a software problem? Niels Kristian Schjødt
• 22:11   Re: Do I have a hardware or a software problem? Evgeny Shishkin

12 December 2012

• 00:19   Occasional timeouts on TRUNCATE and simple INSERTs Osborn, Jeff
• 00:39   Re: Occasional timeouts on TRUNCATE and simple INSERTs Sergey Konoplev
• 01:16   Re: Occasional timeouts on TRUNCATE and simple INSERTs Merlin Moncure
• 01:34   Re: Occasional timeouts on TRUNCATE and simple INSERTs Osborn, Jeff
• 01:41   Re: Do I have a hardware or a software problem? Niels Kristian Schjødt
• 01:44   Re: Do I have a hardware or a software problem? Evgeny Shishkin
• 02:53   Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests? Jeff Janes
• 03:38   Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests? Tom Lane
• 04:03   Re: Do I have a hardware or a software problem? Craig Ringer
• 04:17   Re: Do I have a hardware or a software problem? Evgeny Shishkin
• 04:29   Re: Do I have a hardware or a software problem? Craig Ringer
• 04:44   Re: Do I have a hardware or a software problem? Evgeny Shishkin
• 04:47   Re: Do I have a hardware or a software problem? Rosser Schwarz
• 05:02   Re: Do I have a hardware or a software problem? Craig Ringer
• 05:13   Re: Do I have a hardware or a software problem? Evgeny Shishkin
• 05:16   Re: Do I have a hardware or a software problem? David Boreham
• 05:20   Re: Do I have a hardware or a software problem? Evgeny Shishkin
• 05:27   Re: Do I have a hardware or a software problem? David Boreham
• 05:38   Re: Do I have a hardware or a software problem? Evgeny Shishkin
• 05:41   Re: Do I have a hardware or a software problem? David Boreham
• 05:48   Re: Do I have a hardware or a software problem? Craig Ringer
• 05:49   Re: Do I have a hardware or a software problem? Evgeny Shishkin
• 06:05   Re: Do I have a hardware or a software problem? Mark Kirkwood
• 06:05   Re: Do I have a hardware or a software problem? David Boreham
• 06:11   Re: Do I have a hardware or a software problem? Evgeny Shishkin
• 06:20   Re: Do I have a hardware or a software problem? David Boreham
• 07:25   hash join vs nested loop join Huan Ruan
• 07:33   Re: hash join vs nested loop join Evgeny Shishkin
• 07:59   Re: hash join vs nested loop join Evgeny Shishkin
• 19:22   Re: Do I have a hardware or a software problem? Niels Kristian Schjødt
• 19:26   Read rows deleted Alejandro Carrillo
• 19:28   Re: hash join vs nested loop join Jeff Janes
• 19:46   Re: Do I have a hardware or a software problem? Niels Kristian Schjødt
• 20:01   Re: Savepoints in transactions for speed? Jeff Janes
• 23:03   track_activity_query_size Andrew Dunstan
• 23:14   Re: Read rows deleted Sergey Konoplev
• 23:24   Re: Read rows deleted Alejandro Carrillo
• 23:30   Re: Read rows deleted Andrew Dunstan

13 December 2012

• 00:07   encouraging index-only scans Andrew Dunstan
• 01:12   Re: encouraging index-only scans Andrew Dunstan
• 01:27   Re: encouraging index-only scans Andrew Dunstan
• 02:26   Re: Do I have a hardware or a software problem? Craig Ringer
• 02:47   Re: hash join vs nested loop join Kevin Grittner
• 07:08   Limit & offset effect on query plans Amitabh Kant
• 07:43   Re: Limit & offset effect on query plans Pavan Deolasee
• 07:52   Memory issue for inheritance tables. Hari Babu
• 18:10   Re: Do I have a hardware or a software problem? Jeff Janes
• 18:27   Re: hash join vs nested loop join Kevin Grittner
• 18:37   problem with large inserts Lutz Fischer
• 18:47   Re: Limit & offset effect on query plans Kevin Grittner
• 18:49   Re: problem with large inserts Willem Leenen
• 19:09   Re: problem with large inserts Filip Rembiałkowski
• 19:10   Re: problem with large inserts Tom Lane
• 19:20   Re: Limit & offset effect on query plans Tom Lane
• 19:33   Re: problem with large inserts Lutz Fischer
• 19:44   Re: problem with large inserts Filip Rembiałkowski
• 20:07   Re: Limit & offset effect on query plans Kevin Grittner
• 20:12   Re: Limit & offset effect on query plans Tom Lane
• 21:14   Re: Limit & offset effect on query plans Kevin Grittner
• 21:51   How do I track stats on foreign table access through foreign data wrapper? David Crawford
• 21:52   Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests? Patryk Sidzina
• 21:52   Re: encouraging index-only scans Tom Lane
• 21:52   Re: hash join vs nested loop join Huan Ruan
• 21:53   Re: hash join vs nested loop join Huan Ruan
• 21:59   Slow queries after vacuum analyze Ghislain ROUVIGNAC
• 23:42   Re: Slow queries after vacuum analyze Kevin Grittner
• 23:57   Re: Occasional timeouts on TRUNCATE and simple INSERTs Osborn, Jeff

14 December 2012

• 01:12   Why does the number of rows are different in actual and estimated. AI Rumman
• 01:36   Re: Why does the number of rows are different in actual and estimated. Andrew Dunstan
• 01:40   Re: Why does the number of rows are different in actual and estimated. Evgeny Shishkin
• 01:42   Re: Why does the number of rows are different in actual and estimated. Claudio Freire
• 02:10   Re: Why does the number of rows are different in actual and estimated. Andrew Dunstan
• 02:13   Re: Why does the number of rows are different in actual and estimated. Evgeny Shishkin
• 02:37   Re: Why does the number of rows are different in actual and estimated. Tom Lane
• 02:50   Re: Why does the number of rows are different in actual and estimated. Evgeny Shishkin
• 02:51   Re: hash join vs nested loop join Huan Ruan
• 03:39   Re: Why does the number of rows are different in actual and estimated. Claudio Freire
• 03:54   Re: hash join vs nested loop join Kevin Grittner
• 07:50   Re: hash join vs nested loop join Huan Ruan
• 16:48   Re: hash join vs nested loop join Kevin Grittner
• 21:40   backend suddenly becomes slow, then remains slow Andrew Dunstan
• 22:01   Re: Why does the number of rows are different in actual and estimated. AI Rumman
• 22:13   Re: Why does the number of rows are different in actual and estimated. Claudio Freire
• 22:14   Re: Why does the number of rows are different in actual and estimated. Kevin Grittner
• 22:22   Re: Why does the number of rows are different in actual and estimated. Tom Lane
• 22:28   Re: Why does the number of rows are different in actual and estimated. AI Rumman
• 22:56   Re: backend suddenly becomes slow, then remains slow Tom Lane
• 23:11   Re: Why does the number of rows are different in actual and estimated. Claudio Freire
• 23:16   Re: backend suddenly becomes slow, then remains slow Andrew Dunstan
• 23:25   Re: Why does the number of rows are different in actual and estimated. AI Rumman
• 23:32   Re: Why does the number of rows are different in actual and estimated. Claudio Freire
• 23:34   Re: Why does the number of rows are different in actual and estimated. Kevin Grittner

15 December 2012

• 01:12   Re: Why does the number of rows are different in actual and estimated. AI Rumman
• 01:47   Re: Why does the number of rows are different in actual and estimated. Kevin Grittner
• 03:22   Re: Do I have a hardware or a software problem? Scott Marlowe

17 December 2012

• 12:21   Re: How can i find out top high load sql queries in PostgreSQL. suhas.basavaraj12
• 19:33   Re: How can i find out top high load sql queries in PostgreSQL. Vibhor Kumar

18 December 2012

• 23:20   Re: Slow queries after vacuum analyze Kevin Grittner

19 December 2012

• 04:55   Re: hash join vs nested loop join Huan Ruan
• 16:28   Re: hash join vs nested loop join Kevin Grittner
• 22:13   Re: How can i find out top high load sql queries in PostgreSQL. Igor Neyman
• 22:36   PG 9.1 performance loss due to query plan being changed depending on db data (4s vs 200ms) Rodrigo Rosenfeld Rosas

20 December 2012

• 00:13   Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 02:00   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Sergey Konoplev
• 02:49   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 03:09   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Sergey Konoplev
• 03:22   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 04:02   Re: hash join vs nested loop join Huan Ruan
• 06:06   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Tom Lane
• 08:12   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Jeff Janes
• 08:52   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 08:57   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 17:06   Re: hash join vs nested loop join Kevin Grittner
• 18:43   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Tom Lane
• 18:49   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Tom Lane
• 20:29   Performance on Bulk Insert to Partitioned Table Charles Gomes
• 20:39   Re: Performance on Bulk Insert to Partitioned Table Scott Marlowe
• 21:55   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 23:02   Re: Performance on Bulk Insert to Partitioned Table Stephen Frost
• 23:08   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes

21 December 2012

• 00:16   Re: hash join vs nested loop join Huan Ruan
• 01:31   Re: Performance on Bulk Insert to Partitioned Table Jeff Janes
• 01:43   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 01:50   Re: Performance on Bulk Insert to Partitioned Table Ondrej Ivanič
• 01:56   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 01:59   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 02:39   Re: Performance on Bulk Insert to Partitioned Table Tom Lane
• 03:19   Re: Performance on Bulk Insert to Partitioned Table Scott Marlowe
• 05:34   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 06:16   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 06:24   Re: Performance on Bulk Insert to Partitioned Table Jeff Janes
• 06:40   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Jeff Janes
• 08:15   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Jeff Janes
• 08:15   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Jeff Janes
• 17:14   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 17:30   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 18:34   Re: Slow queries after vacuum analyze Kevin Grittner

22 December 2012

• 20:29   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 20:46   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill

24 December 2012

• 01:55   Re: Performance on Bulk Insert to Partitioned Table Jeff Janes
• 01:55   Re: Performance on Bulk Insert to Partitioned Table Jeff Janes
• 01:55   Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests? Jeff Janes
• 18:51   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 20:07   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 20:11   Re: Performance on Bulk Insert to Partitioned Table Evgeny Shishkin
• 21:36   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 21:37   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?) Richard Neill
• 22:29   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 23:42   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?) John Rouillard

27 December 2012

• 07:03   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Jeff Janes
• 07:03   Re: Performance on Bulk Insert to Partitioned Table Jeff Janes
• 07:03   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?) Jeff Janes
• 07:03   backend suddenly becomes slow, then remains slow Jeff Janes
• 07:03   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? (solved?) Jeff Janes
• 08:41   Re: Performance on Bulk Insert to Partitioned Table Pavel Stehule
• 13:52   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 16:02   Improve performance for writing Markus Innerebner
• 17:45   Re: Improve performance for writing Charles Gomes
• 19:16   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 19:17   Why does the query planner use two full indexes, when a dedicated partial index exists? Jeff Janes
• 19:43   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 20:05   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Tom Lane
• 20:10   explain analyze reports that my queries are fast but they run very slowly Nikolas Everett
• 20:21   Re: explain analyze reports that my queries are fast but they run very slowly François Beausoleil
• 20:35   Re: explain analyze reports that my queries are fast but they run very slowly Richard Neill
• 20:43   Re: backend suddenly becomes slow, then remains slow Andrew Dunstan
• 20:46   Re: explain analyze reports that my queries are fast but they run very slowly Nikolas Everett
• 20:58   Re: explain analyze reports that my queries are fast but they run very slowly Nikolas Everett
• 21:00   Re: explain analyze reports that my queries are fast but they run very slowly Nikolas Everett
• 21:07   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Jeff Janes
• 21:11   Performance on Bulk Insert to Partitioned Table Jeff Janes
• 21:24   Re: Performance on Bulk Insert to Partitioned Table Jeff Janes
• 21:46   Re: Performance on Bulk Insert to Partitioned Table Pavel Stehule
• 22:00   Re: Performance on Bulk Insert to Partitioned Table Charles Gomes
• 22:00   Re: Performance on Bulk Insert to Partitioned Table Stephen Frost
• 22:21   Re: explain analyze reports that my queries are fast but they run very slowly Tom Lane
• 22:22   Re: Performance on Bulk Insert to Partitioned Table Pavel Stehule
• 22:28   Re: explain analyze reports that my queries are fast but they run very slowly Nikolas Everett
• 22:29   Re: explain analyze reports that my queries are fast but they run very slowly Nikolas Everett
• 22:42   Re: explain analyze reports that my queries are fast but they run very slowly Tom Lane
• 22:45   Re: Performance on Bulk Insert to Partitioned Table Emmanuel Cecchet
• 22:45   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Richard Neill
• 22:46   Re: Slow queries after vacuum analyze Ghislain ROUVIGNAC
• 22:57   sched_migration_cost for high-connection counts Shaun Thomas

28 December 2012

• 00:33   Re: explain analyze reports that my queries are fast but they run very slowly Tom Lane
• 01:02   Re: explain analyze reports that my queries are fast but they run very slowly Nikolas Everett
• 02:12   Re: explain analyze reports that my queries are fast but they run very slowly Tom Lane
• 02:36   Re: explain analyze reports that my queries are fast but they run very slowly Nikolas Everett
• 03:11   Re: backend suddenly becomes slow, then remains slow Jeff Janes
• 05:35   Re: Why does the query planner use two full indexes, when a dedicated partial index exists? Jeff Janes
• 15:35   Re: Performance on Bulk Insert to Partitioned Table Vitalii Tymchyshyn
• 15:39   Re: Performance on Bulk Insert to Partitioned Table Vitalii Tymchyshyn
• 15:41   Re: Performance on Bulk Insert to Partitioned Table Stephen Frost
• 15:49   Re: Performance on Bulk Insert to Partitioned Table Pavel Stehule
• 16:18   Re: Performance on Bulk Insert to Partitioned Table Vitalii Tymchyshyn
• 16:25   Re: Performance on Bulk Insert to Partitioned Table Vitalii Tymchyshyn
• 16:42   Re: Performance on Bulk Insert to Partitioned Table Pavel Stehule
• 17:05   Re: Performance on Bulk Insert to Partitioned Table Jeff Janes
• 17:10   Re: Performance on Bulk Insert to Partitioned Table Stephen Frost
• 17:11   Re: Performance on Bulk Insert to Partitioned Table Stephen Frost
• 17:45   Re: Performance on Bulk Insert to Partitioned Table Pavel Stehule
• 19:30   Re: Performance on Bulk Insert to Partitioned Table Jeff Janes
• 21:00   RES: Performance on Bulk Insert to Partitioned Table Luciano Ernesto da Silva
• 21:05   Re: Performance on Bulk Insert to Partitioned Table Pavel Stehule

29 December 2012

• 23:57   serious under-estimation of n_distinct for clustered distributions Stefan Andreatta

30 December 2012

• 00:57   Re: serious under-estimation of n_distinct for clustered distributions Peter Geoghegan
• 21:02   Re: serious under-estimation of n_distinct for clustered distributions Stefan Andreatta
• 22:24   Re: serious under-estimation of n_distinct for clustered distributions Claudio Freire

31 December 2012

• 05:03   Slow connections on Win 7 John Kasarda
• 06:00   Re: Slow connections on Win 7 Sam Gendler
• 16:08   Re: High %SYS CPU usage Cesar Martin