Mailing lists [pgsql-performance]

1 October 2012

• 17:09   Re: Postgres becoming slow, only full vacuum fixes it Igor Neyman

2 October 2012

• 00:24   A Tale of 2 algorithms Colin Taylor
• 02:09   Re: NestedLoops over BitmapScan question Виктор Егоров
• 03:15   Re: Inserts in 'big' table slowing down the database Stefan Keller
• 03:36   Re: Inserts in 'big' table slowing down the database Greg Williamson
• 07:54   Re: A Tale of 2 algorithms Craig Ringer
• 10:28   Re: Spurious failure to obtain row lock possible in PG 9.1? henk de wit
• 10:28   deadlock_timeout affect on performance pg noob
• 11:20   Re: hardware advice Glyn Astill
• 11:24   Re: deadlock_timeout affect on performance Heikki Linnakangas
• 17:52   Re: hardware advice - opinions about HP? Franklin, Dan (FEN)
• 18:09   Re: Inserts in 'big' table slowing down the database Shaun Thomas
• 18:14   Re: hardware advice - opinions about HP? Bruce Momjian
• 18:14   Re: hardware advice David Boreham
• 19:01   Re: hardware advice - opinions about HP? Scott Marlowe
• 19:46   suboptimal query plan Nick Hofstede

3 October 2012

• 06:56   Re: suboptimal query plan Tom Lane
• 11:02   Re: suboptimal query plan Nick Hofstede
• 14:46   Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets Andrea Suisani
• 14:56   Re: hardware advice Glyn Astill
• 16:39   Re: Postgres becoming slow, only full vacuum fixes it Kiriakos Tsourapas
• 22:35   Re: Inserts in 'big' table slowing down the database Jeff Janes

4 October 2012

• 17:01   how to avoid deadlock on masive update with multiples delete Anibal David Acosta
• 19:10   Re: how to avoid deadlock on masive update with multiples delete Jeff Janes

5 October 2012

• 03:34   Re: A Tale of 2 algorithms Colin Taylor
• 17:06   Re: how to avoid deadlock on masive update with multiples delete Igor Neyman
• 17:27   Re: how to avoid deadlock on masive update with multiples delete Claudio Freire
• 18:08   Re: how to avoid deadlock on masive update with multiples delete Maciek Sakrejda
• 18:31   Re: how to avoid deadlock on masive update with multiples delete Tom Lane
• 18:36   Re: how to avoid deadlock on masive update with multiples delete Andres Freund
• 18:46   Re: how to avoid deadlock on masive update with multiples delete Tom Lane
• 18:55   Re: how to avoid deadlock on masive update with multiples delete Merlin Moncure
• 18:58   Re: how to avoid deadlock on masive update with multiples delete Claudio Freire
• 19:21   Re: how to avoid deadlock on masive update with multiples delete Tom Lane
• 19:33   Re: how to avoid deadlock on masive update with multiples delete Andres Freund
• 21:34   Re: how to avoid deadlock on masive update with multiples delete Anibal David Acosta

7 October 2012

• 20:33   hash aggregation speedup Korisk

8 October 2012

• 10:39   Re: Same query doing slow then quick Undertaker Rude
• 11:18   Strange behavior after upgrade from 9.0 to 9.2 Andrzej Zawadzki
• 13:15   Re: Strange behavior after upgrade from 9.0 to 9.2 Craig Ringer
• 14:40   Re: Strange behavior after upgrade from 9.0 to 9.2 Andrzej Zawadzki
• 14:40   UPDATE execution time is increasing virag@chem.elte.hu
• 14:41   Re: Same query doing slow then quick Ants Aasma
• 14:41   Re: Guide to Posting Slow Query Questions Ants Aasma
• 15:20   Re: UPDATE execution time is increasing Valentine Gogichashvili
• 15:38   Re: [repost] Help me develop new commit_delay advice Peter Geoghegan
• 17:52   Re: Strange behavior after upgrade from 9.0 to 9.2 Tom Lane
• 18:41   Re: Strange behavior after upgrade from 9.0 to 9.2 Andrzej Zawadzki
• 18:56   Re: Strange behavior after upgrade from 9.0 to 9.2 Tom Lane
• 19:14   Re: Strange behavior after upgrade from 9.0 to 9.2 Andrzej Zawadzki
• 22:44   Scaling 10 million records in PostgreSQL table Navaneethan R
• 22:50   Re: Scaling 10 million records in PostgreSQL table Merlin Moncure
• 22:52   Re: Scaling 10 million records in PostgreSQL table Julien Cigar
• 22:53   Re: Scaling 10 million records in PostgreSQL table Larry Rosenman
• 23:10   Re: Scaling 10 million records in PostgreSQL table Steve Crawford
• 23:27   Re: Scaling 10 million records in PostgreSQL table Craig Ringer

9 October 2012

• 00:45   Two identical systems, radically different performance Craig James
• 00:57   Re: Two identical systems, radically different performance Evgeny Shishkin
• 01:06   Re: Two identical systems, radically different performance Craig James
• 01:08   Re: Two identical systems, radically different performance Evgeny Shishkin
• 01:09   Re: Two identical systems, radically different performance Claudio Freire
• 01:16   Re: Two identical systems, radically different performance Steve Crawford
• 01:25   Re: Two identical systems, radically different performance Craig James
• 01:29   Re: Two identical systems, radically different performance Imre Samu
• 01:29   Re: Two identical systems, radically different performance Craig James
• 01:33   Re: Two identical systems, radically different performance Evgeny Shishkin
• 01:42   Re: Two identical systems, radically different performance Craig James
• 01:42   Re: Scaling 10 million records in PostgreSQL table Samuel Gendler
• 01:44   Re: Two identical systems, radically different performance Claudio Freire
• 01:46   Re: Two identical systems, radically different performance Evgeny Shishkin
• 01:48   Re: Two identical systems, radically different performance Craig James
• 01:50   Re: Two identical systems, radically different performance Claudio Freire
• 02:03   Re: Two identical systems, radically different performance Craig James
• 02:11   Re: Two identical systems, radically different performance Mark Kirkwood
• 02:13   Re: Two identical systems, radically different performance Claudio Freire
• 02:16   Re: Two identical systems, radically different performance Tomas Vondra
• 02:24   Re: Two identical systems, radically different performance Tomas Vondra
• 02:30   Re: Two identical systems, radically different performance Evgeny Shishkin
• 02:40   Re: Two identical systems, radically different performance Craig James
• 14:20   Re: Two identical systems, radically different performance Yeb Havinga
• 19:02   Re: Two identical systems, radically different performance Shaun Thomas
• 19:12   Re: Two identical systems, radically different performance David Thomas
• 19:41   Re: Two identical systems, radically different performance Craig James
• 19:43   Re: Two identical systems, radically different performance Craig James
• 23:13   Hyperthreading (was: Two identical systems, radically different performance) Craig James
• 23:53   Re: Hyperthreading (was: Two identical systems, radically different performance) Tom Lane
• 23:56   Re: Scaling 10 million records in PostgreSQL table Navaneethan R
• 23:56   Re: Two identical systems, radically different performance Gavin Flower
• 23:56   Re: Hyperthreading (was: Two identical systems, radically different performance) Shaun Thomas
• 23:56   Re: Two identical systems, radically different performance Ants Aasma
• 23:57   Re: Hyperthreading (was: Two identical systems, radically different performance) Josh Berkus

10 October 2012

• 00:24   Re: Hyperthreading (was: Two identical systems, radically different performance) Jeff Janes
• 00:43   Ways to speed up ts_rank Shane Hathaway
• 00:47   Re: Scaling 10 million records in PostgreSQL table Samuel Gendler
• 00:49   Re: Scaling 10 million records in PostgreSQL table Daniel Farina
• 01:21   Why am I getting great/terrible estimates with these CTE queries? Tomas Vondra
• 02:09   Re: Why am I getting great/terrible estimates with these CTE queries? Tom Lane
• 02:30   Re: Hyperthreading (was: Two identical systems, radically different performance) Craig James
• 03:19   Re: Why am I getting great/terrible estimates with these CTE queries? Tomas Vondra
• 10:12   shared_buffers/effective_cache_size on 96GB server Strahinja Kustudić
• 10:19   Re: shared_buffers/effective_cache_size on 96GB server Strahinja Kustudić
• 10:32   Re: shared_buffers/effective_cache_size on 96GB server Tomas Vondra
• 10:40   Re: shared_buffers/effective_cache_size on 96GB server Albe Laurenz
• 11:11   Re: shared_buffers/effective_cache_size on 96GB server Julien Cigar
• 11:30   Re: shared_buffers/effective_cache_size on 96GB server Strahinja Kustudić
• 11:52   Re: shared_buffers/effective_cache_size on 96GB server Julien Cigar
• 14:34   Re: shared_buffers/effective_cache_size on 96GB server Strahinja Kustudić
• 15:38   Re: Ways to speed up ts_rank François Beausoleil
• 15:52   Re: Hyperthreading (was: Two identical systems, radically different performance) Shaun Thomas
• 16:10   Re: shared_buffers/effective_cache_size on 96GB server Shaun Thomas
• 17:36   Re: shared_buffers/effective_cache_size on 96GB server Strahinja Kustudić
• 17:38   Re: shared_buffers/effective_cache_size on 96GB server Shaun Thomas
• 17:46   Re: Hyperthreading (was: Two identical systems, radically different performance) Claudio Freire
• 17:50   Re: shared_buffers/effective_cache_size on 96GB server Strahinja Kustudić
• 17:54   Re: shared_buffers/effective_cache_size on 96GB server Shaun Thomas
• 17:59   Re: Ways to speed up ts_rank Oleg Bartunov
• 18:46   Re: Hyperthreading (was: Two identical systems, radically different performance) Bruce Momjian
• 19:05   Re: shared_buffers/effective_cache_size on 96GB server Bruce Momjian
• 19:09   hash aggregation Korisk
• 19:10   Re: shared_buffers/effective_cache_size on 96GB server Bruce Momjian
• 20:05   Re: shared_buffers/effective_cache_size on 96GB server Claudio Freire
• 20:06   Drawbacks of create index where is not null ? Franck Routier
• 20:28   Re: Hyperthreading (was: Two identical systems, radically different performance) Craig James
• 20:56   Re: shared_buffers/effective_cache_size on 96GB server Bruce Momjian
• 21:08   Re: Hyperthreading (was: Two identical systems, radically different performance) Claudio Freire
• 21:18   Re: shared_buffers/effective_cache_size on 96GB server Shaun Thomas
• 21:24   Re: shared_buffers/effective_cache_size on 96GB server Claudio Freire
• 21:31   Re: Ways to speed up ts_rank Shane Hathaway
• 21:38   Re: Ways to speed up ts_rank Shane Hathaway
• 22:30   Re: shared_buffers/effective_cache_size on 96GB server Jeff Janes
• 23:13   Re: shared_buffers/effective_cache_size on 96GB server Strahinja Kustudić
• 23:48   Re: shared_buffers/effective_cache_size on 96GB server Claudio Freire

11 October 2012

• 00:03   Re: shared_buffers/effective_cache_size on 96GB server Bruce Momjian
• 00:30   Re: hash aggregation Sergey Konoplev
• 01:06   Re: shared_buffers/effective_cache_size on 96GB server Ondrej Ivanič
• 01:14   Re: shared_buffers/effective_cache_size on 96GB server Claudio Freire
• 01:33   Re: shared_buffers/effective_cache_size on 96GB server Jeff Janes
• 01:37   Re: shared_buffers/effective_cache_size on 96GB server Claudio Freire
• 07:13   Re: hash aggregation Korisk
• 07:38   Re: hash aggregation Craig Ringer
• 08:26   Re: Drawbacks of create index where is not null ? Craig Ringer
• 08:36   Re: shared_buffers/effective_cache_size on 96GB server Scott Marlowe
• 08:42   Re: Drawbacks of create index where is not null ? Scott Marlowe
• 08:44   Re: Drawbacks of create index where is not null ? Scott Marlowe
• 09:15   Re: hash aggregation Sergey Konoplev
• 11:22   Re: Drawbacks of create index where is not null ? Franck Routier
• 17:14   Re: Two identical systems, radically different performance Andrea Suisani
• 17:19   Re: Two identical systems, radically different performance Claudio Freire
• 17:40   Re: Two identical systems, radically different performance Andrea Suisani
• 18:15   Re: hash aggregation Korisk
• 20:55   Re: hash aggregation Sergey Konoplev
• 21:19   Re: shared_buffers/effective_cache_size on 96GB server Josh Berkus

12 October 2012

• 00:46   Re: problems with large objects dump Sergio Gabriel Rodriguez
• 01:16   Re: problems with large objects dump Tom Lane
• 01:26   Re: problems with large objects dump Marcos Ortiz
• 01:31   Re: Drawbacks of create index where is not null ? Sergey Konoplev
• 06:55   Re: hash aggregation Korisk
• 07:01   Re: hash aggregation Sergey Konoplev
• 07:14   Re: hash aggregation Korisk
• 07:33   Re: hash aggregation Ondrej Ivanič
• 10:10   Re: hash aggregation Sergey Konoplev
• 17:37   Re: hash aggregation Korisk
• 23:06   Do cast affects index usage? Anibal David Acosta
• 23:37   Re: Do cast affects index usage? Scott Marlowe
• 23:38   Re: Do cast affects index usage? Tom Lane

13 October 2012

• 00:14   Re: hash aggregation Tomas Vondra
• 00:28   Re: hash aggregation Tomas Vondra
• 01:35   Re: problems with large objects dump Sergio Gabriel Rodriguez
• 02:18   Re: problems with large objects dump Tom Lane
• 03:27   Re: Do cast affects index usage? Anibal David Acosta
• 04:32   Re: problems with large objects dump Tom Lane
• 04:34   Re: Do cast affects index usage? Tom Lane

14 October 2012

• 03:43   Index over all partitions (aka global index)? Stefan Keller
• 08:39   Re: Index over all partitions (aka global index)? Jeff Janes
• 09:55   Query with limit goes from few ms to hours henk de wit
• 10:04   Re: Query with limit goes from few ms to hours henk de wit
• 15:22   Re: Index over all partitions (aka global index)? Stefan Keller
• 19:15   Re: Query with limit goes from few ms to hours Tom Lane

15 October 2012

• 11:22   WebSphere Application Server support for postgres John Nash
• 11:27   Re: Two identical systems, radically different performance Andrea Suisani
• 13:19   Re: problems with large objects dump Sergio Gabriel Rodriguez
• 15:31   Re: Query with limit goes from few ms to hours Robert Klemme
• 18:01   Re: Two identical systems, radically different performance Craig James
• 18:01   Re: Two identical systems, radically different performance Claudio Freire
• 18:25   Re: Two identical systems, radically different performance Andrea Suisani
• 18:28   Re: Two identical systems, radically different performance Claudio Freire
• 18:32   Re: Two identical systems, radically different performance Scott Marlowe
• 18:34   Re: Two identical systems, radically different performance Scott Marlowe
• 18:45   Re: Two identical systems, radically different performance Andrea Suisani
• 18:56   Re: Two identical systems, radically different performance Andrea Suisani
• 18:56   Re: Two identical systems, radically different performance Andrea Suisani
• 20:50   Re: Query with limit goes from few ms to hours henk de wit
• 23:59   SELECT AND AGG huge tables houmanb

16 October 2012

• 00:09   Re: SELECT AND AGG huge tables Merlin Moncure
• 00:42   Re: SELECT AND AGG huge tables Matheus de Oliveira
• 00:54   Re: SELECT AND AGG huge tables Ondrej Ivanič
• 02:45   Re: SELECT AND AGG huge tables Bob Lunney
• 03:04   Re: SELECT AND AGG huge tables Jeff Janes
• 05:42   Re: SELECT AND AGG huge tables Craig Ringer
• 08:07   Re: Two identical systems, radically different performance Marinos Yannikos
• 10:50   Slow Delete : Seq scan instead of index scan Sylvain CAILLET
• 11:01   Re: Slow Delete : Seq scan instead of index scan Sékine Coulibaly
• 11:09   Re: Slow Delete : Seq scan instead of index scan Craig Ringer
• 11:13   Re: Slow Delete : Seq scan instead of index scan Sylvain CAILLET
• 11:24   Re: Slow Delete : Seq scan instead of index scan Sylvain CAILLET
• 11:41   Re: Slow Delete : Seq scan instead of index scan Filippos Kalamidas
• 11:47   LIKE op with B-Tree Index? Sam Wong
• 15:26   Support Create package Alejandro Carrillo
• 15:48   Re: Support Create package Pavel Stehule
• 15:53   Re: Support Create package ktm@rice.edu
• 20:38   Re: Guide to Posting Slow Query Questions Jeff Janes
• 22:11   LIKE op with B-Tree Index? Sam Wong
• 22:15   limit order by performance issue Pedro Jiménez
• 22:24   Re: limit order by performance issue Pavel Stehule
• 22:28   Re: limit order by performance issue Shaun Thomas
• 22:47   Re: limit order by performance issue Karl Denninger
• 23:29   Re: LIKE op with B-Tree Index? Merlin Moncure

17 October 2012

• 01:11   Re: limit order by performance issue Marti Raudsepp
• 02:52   Have: Seq Scan - Want: Index Scan - what am I doing wrong? Chris Ruprecht
• 03:01   Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong? Evgeny Shishkin
• 03:19   Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong? Chris Ruprecht
• 03:31   Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong? Bruce Momjian
• 03:43   Re: Have: Seq Scan - Want: Index Scan - what am I doing wrong? Chris Ruprecht
• 04:01   Re: LIKE op with B-Tree Index? Sam Wong
• 09:20   Re: Slow Delete : Seq scan instead of index scan Craig Ringer
• 10:05   pgbounce max_client_conn and default_pool_size Yetkin Öztürk
• 10:26   have: seq scan - want: index scan Chris Ruprecht
• 11:26   Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6 Maciek Sakrejda
• 11:53   Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6 Martin French
• 12:08   Re: have: seq scan - want: index scan Samuel Gendler
• 12:13   Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6 Maciek Sakrejda
• 12:29   Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6 Martin French
• 14:24   Re: SELECT AND AGG huge tables houmanb
• 16:52   High cost estimates when n_distinct is set Niko Kiirala
• 17:18   Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6 Tom Lane
• 18:09   Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6 Maciek Sakrejda
• 18:45   Re: Two identical systems, radically different performance Andrea Suisani
• 19:35   Re: Two identical systems, radically different performance Scott Marlowe
• 20:45   Re: LIKE op with B-Tree Index? Merlin Moncure

18 October 2012

• 08:59   Re: LIKE op with B-Tree Index? Sam Wong
• 09:57   Re: Two identical systems, radically different performance Andrea Suisani
• 10:03   Re: LIKE op with B-Tree Index? Albe Laurenz
• 19:12   Unused index influencing sequential scan plan Thom Brown
• 19:14   Re: Unused index influencing sequential scan plan Thom Brown
• 19:24   Re: Unused index influencing sequential scan plan Peter Geoghegan
• 19:39   Re: Two identical systems, radically different performance Craig James
• 19:44   Re: Unused index influencing sequential scan plan Tom Lane
• 19:46   Re: Unused index influencing sequential scan plan Thom Brown
• 19:48   Re: Unused index influencing sequential scan plan Thom Brown
• 19:52   Re: Unused index influencing sequential scan plan Tom Lane
• 20:00   Re: Unused index influencing sequential scan plan Peter Geoghegan
• 20:01   Re: Unused index influencing sequential scan plan Thom Brown
• 20:02   Re: Unused index influencing sequential scan plan Thom Brown
• 20:06   Re: Unused index influencing sequential scan plan Tom Lane
• 20:54   Re: shared_buffers/effective_cache_size on 96GB server Jeff Janes
• 22:24   Re: shared_buffers/effective_cache_size on 96GB server Jeff Janes
• 22:50   Re: shared_buffers/effective_cache_size on 96GB server Jeff Janes
• 23:43   Re: shared_buffers/effective_cache_size on 96GB server Claudio Freire

19 October 2012

• 01:06   Re: shared_buffers/effective_cache_size on 96GB server Scott Marlowe
• 13:47   Recursive query gets slower when adding an index Thomas Kellerer
• 17:01   Re: limit order by performance issue Pedro Jiménez Pérez
• 17:01   How to upgrade from 9.1 to 9.2 with replication? delongboy
• 17:01   Re: SELECT AND AGG huge tables Ants Aasma
• 17:21   Re: Recursive query gets slower when adding an index Tom Lane
• 17:29   Tablespace-derived stats? Shaun Thomas
• 17:44   Re: How to upgrade from 9.1 to 9.2 with replication? Karl Denninger
• 17:51   Re: Tablespace-derived stats? Tom Lane
• 17:51   Re: How to upgrade from 9.1 to 9.2 with replication? Shaun Thomas
• 17:54   Re: Tablespace-derived stats? Shaun Thomas
• 18:02   Re: How to upgrade from 9.1 to 9.2 with replication? Claudio Freire
• 18:05   Re: Tablespace-derived stats? Jeff Janes
• 18:07   Re: Tablespace-derived stats? Shaun Thomas
• 18:26   Re: Tablespace-derived stats? Jeff Janes
• 18:49   Re: How to upgrade from 9.1 to 9.2 with replication? Karl Denninger
• 19:03   Re: How to upgrade from 9.1 to 9.2 with replication? Shaun Thomas
• 19:19   Re: limit order by performance issue Claudio Freire
• 20:22   Re: Recursive query gets slower when adding an index Thomas Kellerer

20 October 2012

• 04:10   Connection Options -- SSL already uses compression? Karl Denninger

21 October 2012

• 10:51   Re: Connection Options -- SSL already uses compression? Magnus Hagander

22 October 2012

• 20:35   Tons of free RAM. Can't make it go away. Shaun Thomas
• 20:44   Re: Tons of free RAM. Can't make it go away. Claudio Freire
• 20:49   Re: Tons of free RAM. Can't make it go away. Shaun Thomas
• 20:50   Re: Tons of free RAM. Can't make it go away. Frank Lanitz
• 20:53   Re: Tons of free RAM. Can't make it go away. Claudio Freire
• 20:56   Re: Tons of free RAM. Can't make it go away. Marcus Larsson
• 21:01   Re: Tons of free RAM. Can't make it go away. Shaun Thomas
• 21:14   Re: Tons of free RAM. Can't make it go away. Claudio Freire
• 21:20   Re: Tons of free RAM. Can't make it go away. Franklin, Dan (FEN)
• 21:25   Re: Tons of free RAM. Can't make it go away. Shaun Thomas
• 21:28   Re: Tons of free RAM. Can't make it go away. Shaun Thomas
• 21:44   Re: Tons of free RAM. Can't make it go away. Claudio Freire

23 October 2012

• 19:49   Re: Tons of free RAM. Can't make it go away. Shaun Thomas
• 22:29   Re: Query with limit goes from few ms to hours Kevin Grittner
• 23:08   Re: Query with limit goes from few ms to hours Steve Crawford

24 October 2012

• 18:41   Query-Planer from 6seconds TO DAYS Böckler Andreas
• 19:55   Setting Statistics on Functional Indexes Shaun Thomas
• 21:52   Re: Query-Planer from 6seconds TO DAYS Böckler Andreas
• 22:11   Re: Setting Statistics on Functional Indexes Tom Lane
• 22:31   Re: Setting Statistics on Functional Indexes Shaun Thomas
• 22:55   Re: Setting Statistics on Functional Indexes Shaun Thomas
• 23:39   Re: Out of shared mem on new box with more mem, 9.1.5 -> 9.1.6 Kevin Grittner

25 October 2012

• 15:17   Re: How to upgrade from 9.1 to 9.2 with replication? Kevin Grittner
• 15:48   Re: How to upgrade from 9.1 to 9.2 with replication? Shaun Thomas
• 17:27   Re: How to upgrade from 9.1 to 9.2 with replication? Claudio Freire
• 19:21   Re: Query-Planer from 6seconds TO DAYS Jeff Janes
• 22:08   Re: Query-Planer from 6seconds TO DAYS Kevin Grittner

26 October 2012

• 17:37   Re: Query-Planer from 6seconds TO DAYS Böckler Andreas
• 17:55   Re: Query-Planer from 6seconds TO DAYS ktm@rice.edu
• 18:15   Re: Query-Planer from 6seconds TO DAYS Böckler Andreas
• 18:30   BAD performance with enable_bitmapscan = on with Postgresql 9.0.X (X = 3 and 10) Alberto Marchesini
• 18:30   Re: Query-Planer from 6seconds TO DAYS ktm@rice.edu
• 18:31   Re: Query-Planer from 6seconds TO DAYS Böckler Andreas
• 18:40   Re: Query-Planer from 6seconds TO DAYS Kevin Grittner
• 18:41   Re: Query-Planer from 6seconds TO DAYS Kevin Grittner
• 19:02   Re: Query-Planer from 6seconds TO DAYS Kevin Grittner
• 20:58   Re: Query-Planer from 6seconds TO DAYS Jeff Janes
• 20:59   PSA: New Kernels and intel_idle cpuidle Driver! Shaun Thomas
• 21:00   Re: Query-Planer from 6seconds TO DAYS Jeff Janes
• 21:33   Re: Query-Planer from 6seconds TO DAYS Böckler Andreas
• 21:34   Slower Performance on Postgres 9.1.6 vs 8.2.11 robcron
• 22:35   Re: Setting Statistics on Functional Indexes Tom Lane
• 22:57   Re: Setting Statistics on Functional Indexes Shaun Thomas
• 22:58   Re: Slower Performance on Postgres 9.1.6 vs 8.2.11 Tom Lane
• 23:14   Re: Query-Planer from 6seconds TO DAYS Jeff Janes
• 23:26   Re: Slower Performance on Postgres 9.1.6 vs 8.2.11 robcron
• 23:57   Re: Slower Performance on Postgres 9.1.6 vs 8.2.11 robcron

27 October 2012

• 00:08   Re: Setting Statistics on Functional Indexes Tom Lane
• 00:19   Re: Setting Statistics on Functional Indexes Claudio Freire
• 01:01   Re: Setting Statistics on Functional Indexes Tom Lane
• 01:05   Re: Setting Statistics on Functional Indexes Claudio Freire
• 01:05   Re: Setting Statistics on Functional Indexes Claudio Freire
• 07:50   Re: Slower Performance on Postgres 9.1.6 vs 8.2.11 Pavel Stehule

28 October 2012

• 06:49   Re: Tons of free RAM. Can't make it go away. Віталій Тимчишин
• 17:19   Prepared statements slow in 9.2 still (bad query plan) Daniel Burbridge
• 17:19   Re: How to upgrade from 9.1 to 9.2 with replication? delongboy
• 18:06   Re: Prepared statements slow in 9.2 still (bad query plan) Tom Lane
• 18:15   Re: How to upgrade from 9.1 to 9.2 with replication? Karl Denninger

29 October 2012

• 02:40   Re: How to upgrade from 9.1 to 9.2 with replication? Claudio Freire
• 13:42   Re: How to upgrade from 9.1 to 9.2 with replication? Matheus de Oliveira
• 14:53   Re: How to upgrade from 9.1 to 9.2 with replication? Claudio Freire
• 15:10   Re: How to upgrade from 9.1 to 9.2 with replication? Matheus de Oliveira
• 15:23   Re: How to upgrade from 9.1 to 9.2 with replication? Claudio Freire
• 15:31   Re: How to upgrade from 9.1 to 9.2 with replication? Matheus de Oliveira
• 16:05   Replaying 48 WAL files takes 80 minutes Albe Laurenz
• 16:19   Re: Replaying 48 WAL files takes 80 minutes ktm@rice.edu
• 16:25   Re: Prepared statements slow in 9.2 still (bad query plan) Shaun Thomas
• 17:29   Re: Replaying 48 WAL files takes 80 minutes Alvaro Herrera
• 18:05   Re: Replaying 48 WAL files takes 80 minutes Albe Laurenz
• 18:27   Re: Setting Statistics on Functional Indexes Shaun Thomas
• 19:17   Re: Tons of free RAM. Can't make it go away. Shaun Thomas
• 19:42   Re: Replaying 48 WAL files takes 80 minutes Jeff Janes
• 20:41   Request for help with slow query Woolcock, Sean
• 22:18   Re: Request for help with slow query salah jubeh
• 22:21   Re: Setting Statistics on Functional Indexes Kevin Grittner
• 22:28   Re: Request for help with slow query Woolcock, Sean
• 22:33   Re: Request for help with slow query Joshua D. Drake
• 22:36   Re: Request for help with slow query Shaun Thomas
• 22:50   Re: Request for help with slow query salah jubeh
• 22:55   Re: Request for help with slow query Woolcock, Sean
• 22:58   Re: Request for help with slow query Kevin Grittner

30 October 2012

• 00:40   Re: Slower Performance on Postgres 9.1.6 vs 8.2.11 robcron
• 03:12   How to keep queries low latency as concurrency increases Catalin Iacob
• 10:34   Slow query, where am I going wrong? Andy
• 11:25   Re: Slow query, where am I going wrong? Albe Laurenz
• 11:51   Re: Replaying 48 WAL files takes 80 minutes Albe Laurenz
• 12:02   Re: Request for help with slow query Albe Laurenz
• 12:14   out of memory Mahavir Trivedi
• 12:24   PostgreSQL server failed to start vignesh
• 12:47   Re: Slow query, where am I going wrong? AndyG
• 13:07   Re: Replaying 48 WAL files takes 80 minutes Heikki Linnakangas
• 13:09   Re: out of memory Tatsuo Ishii
• 14:56   Re: How to keep queries low latency as concurrency increases Kevin Grittner
• 15:15   Seq scan on 10million record table.. why? Vincenzo Melandri
• 15:54   High %SYS CPU usage Cesar Martin
• 16:05   Re: Replaying 48 WAL files takes 80 minutes ktm@rice.edu
• 16:11   Re: Replaying 48 WAL files takes 80 minutes Albe Laurenz
• 16:17   Re: Replaying 48 WAL files takes 80 minutes Albe Laurenz
• 16:41   Re: Replaying 48 WAL files takes 80 minutes ktm@rice.edu
• 16:45   Re: Seq scan on 10million record table..why? Gabriele Bartolini
• 16:53   Re: Seq scan on 10million record table.. why? Shaun Thomas
• 17:02   Re: How to keep queries low latency as concurrency increases Shaun Thomas
• 17:04   Re: Seq scan on 10million record table.. why? Віталій Тимчишин
• 17:54   Re: Slow query, where am I going wrong? AndyG
• 18:43   Re: PostgreSQL server failed to start Maciek Sakrejda
• 18:49   Re: Slow query, where am I going wrong? Albe Laurenz
• 21:19   Re: Seq scan on 10million record table.. why? Vincenzo Melandri
• 22:07   Re: High %SYS CPU usage Josh Berkus

31 October 2012

• 00:18   Re: How to keep queries low latency as concurrency increases Kevin Grittner
• 00:31   Re: set-returning calls and overhead Jon Nelson
• 00:58   Re: How to keep queries low latency as concurrency increases Jeff Janes
• 01:12   Re: How to keep queries low latency as concurrency increases Greg Williamson
• 01:16   Re: How to keep queries low latency as concurrency increases Scott Marlowe
• 12:18   Re: Slow query, where am I going wrong? AndyG
• 12:37   Re: Slow query, where am I going wrong? Albe Laurenz
• 13:18   Re: Slow query, where am I going wrong? AndyG
• 13:24   Invalid memory alloc request size Mahavir Trivedi
• 13:29   Re: Invalid memory alloc request size Pavel Stehule
• 13:34   Re: Invalid memory alloc request size Samuel Gendler
• 13:56   Seq scan on big table, episode 2 Vincenzo Melandri
• 14:28   Re: Slow query, where am I going wrong? AndyG
• 14:47   Re: Seq scan on big table, episode 2 Vincenzo Melandri
• 16:05   Re: Seq scan on big table, episode 2 Shaun Thomas
• 16:30   Re: Slow query, where am I going wrong? Albe Laurenz
• 17:59   Re: Slow query, where am I going wrong? AndyG
• 19:45   Re: How to keep queries low latency as concurrency increases Jeff Janes
• 21:40   Re: How to keep queries low latency as concurrency increases Merlin Moncure