Архив рассылок [pgsql-performance]

1 октября 2012 г.

• 14:09   Re: Postgres becoming slow, only full vacuum fixes it Igor Neyman
• 21:24   A Tale of 2 algorithms Colin Taylor
• 23:09   Re: NestedLoops over BitmapScan question Виктор Егоров

2 октября 2012 г.

• 00:15   Re: Inserts in 'big' table slowing down the database Stefan Keller
• 00:36   Re: Inserts in 'big' table slowing down the database Greg Williamson
• 04:54   Re: A Tale of 2 algorithms Craig Ringer
• 07:28   Re: Spurious failure to obtain row lock possible in PG 9.1? henk de wit
• 07:28   deadlock_timeout affect on performance pg noob
• 08:20   Re: hardware advice Glyn Astill
• 08:24   Re: deadlock_timeout affect on performance Heikki Linnakangas
• 14:52   Re: hardware advice - opinions about HP? Franklin, Dan (FEN)
• 15:09   Re: Inserts in 'big' table slowing down the database Shaun Thomas
• 15:14   Re: hardware advice - opinions about HP? Bruce Momjian
• 15:14   Re: hardware advice David Boreham
• 16:01   Re: hardware advice - opinions about HP? Scott Marlowe
• 16:46   suboptimal query plan Nick Hofstede

3 октября 2012 г.

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

4 октября 2012 г.

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

5 октября 2012 г.

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

7 октября 2012 г.

• 17:33   hash aggregation speedup Korisk

8 октября 2012 г.

• 07:39   Re: Same query doing slow then quick Undertaker Rude
• 08:18   Strange behavior after upgrade from 9.0 to 9.2 Andrzej Zawadzki
• 10:15   Re: Strange behavior after upgrade from 9.0 to 9.2 Craig Ringer
• 11:40   Re: Strange behavior after upgrade from 9.0 to 9.2 Andrzej Zawadzki
• 11:40   UPDATE execution time is increasing virag@chem.elte.hu
• 11:41   Re: Same query doing slow then quick Ants Aasma
• 11:41   Re: Guide to Posting Slow Query Questions Ants Aasma
• 12:20   Re: UPDATE execution time is increasing Valentine Gogichashvili
• 12:38   Re: [repost] Help me develop new commit_delay advice Peter Geoghegan
• 14:52   Re: Strange behavior after upgrade from 9.0 to 9.2 Tom Lane
• 15:41   Re: Strange behavior after upgrade from 9.0 to 9.2 Andrzej Zawadzki
• 15:56   Re: Strange behavior after upgrade from 9.0 to 9.2 Tom Lane
• 16:14   Re: Strange behavior after upgrade from 9.0 to 9.2 Andrzej Zawadzki
• 19:44   Scaling 10 million records in PostgreSQL table Navaneethan R
• 19:50   Re: Scaling 10 million records in PostgreSQL table Merlin Moncure
• 19:52   Re: Scaling 10 million records in PostgreSQL table Julien Cigar
• 19:53   Re: Scaling 10 million records in PostgreSQL table Larry Rosenman
• 20:10   Re: Scaling 10 million records in PostgreSQL table Steve Crawford
• 20:27   Re: Scaling 10 million records in PostgreSQL table Craig Ringer
• 21:45   Two identical systems, radically different performance Craig James
• 21:57   Re: Two identical systems, radically different performance Evgeny Shishkin
• 22:06   Re: Two identical systems, radically different performance Craig James
• 22:08   Re: Two identical systems, radically different performance Evgeny Shishkin
• 22:09   Re: Two identical systems, radically different performance Claudio Freire
• 22:16   Re: Two identical systems, radically different performance Steve Crawford
• 22:25   Re: Two identical systems, radically different performance Craig James
• 22:29   Re: Two identical systems, radically different performance Imre Samu
• 22:29   Re: Two identical systems, radically different performance Craig James
• 22:33   Re: Two identical systems, radically different performance Evgeny Shishkin
• 22:42   Re: Two identical systems, radically different performance Craig James
• 22:42   Re: Scaling 10 million records in PostgreSQL table Samuel Gendler
• 22:44   Re: Two identical systems, radically different performance Claudio Freire
• 22:46   Re: Two identical systems, radically different performance Evgeny Shishkin
• 22:48   Re: Two identical systems, radically different performance Craig James
• 22:50   Re: Two identical systems, radically different performance Claudio Freire
• 23:03   Re: Two identical systems, radically different performance Craig James
• 23:11   Re: Two identical systems, radically different performance Mark Kirkwood
• 23:13   Re: Two identical systems, radically different performance Claudio Freire
• 23:16   Re: Two identical systems, radically different performance Tomas Vondra
• 23:24   Re: Two identical systems, radically different performance Tomas Vondra
• 23:30   Re: Two identical systems, radically different performance Evgeny Shishkin
• 23:40   Re: Two identical systems, radically different performance Craig James

9 октября 2012 г.

• 11:20   Re: Two identical systems, radically different performance Yeb Havinga
• 16:02   Re: Two identical systems, radically different performance Shaun Thomas
• 16:12   Re: Two identical systems, radically different performance David Thomas
• 16:41   Re: Two identical systems, radically different performance Craig James
• 16:43   Re: Two identical systems, radically different performance Craig James
• 20:13   Hyperthreading (was: Two identical systems, radically different performance) Craig James
• 20:53   Re: Hyperthreading (was: Two identical systems, radically different performance) Tom Lane
• 20:56   Re: Scaling 10 million records in PostgreSQL table Navaneethan R
• 20:56   Re: Two identical systems, radically different performance Gavin Flower
• 20:56   Re: Hyperthreading (was: Two identical systems, radically different performance) Shaun Thomas
• 20:56   Re: Two identical systems, radically different performance Ants Aasma
• 20:57   Re: Hyperthreading (was: Two identical systems, radically different performance) Josh Berkus
• 21:24   Re: Hyperthreading (was: Two identical systems, radically different performance) Jeff Janes
• 21:43   Ways to speed up ts_rank Shane Hathaway
• 21:47   Re: Scaling 10 million records in PostgreSQL table Samuel Gendler
• 21:49   Re: Scaling 10 million records in PostgreSQL table Daniel Farina
• 22:21   Why am I getting great/terrible estimates with these CTE queries? Tomas Vondra
• 23:09   Re: Why am I getting great/terrible estimates with these CTE queries? Tom Lane
• 23:30   Re: Hyperthreading (was: Two identical systems, radically different performance) Craig James

10 октября 2012 г.

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

11 октября 2012 г.

• 04:13   Re: hash aggregation Korisk
• 04:38   Re: hash aggregation Craig Ringer
• 05:26   Re: Drawbacks of create index where is not null ? Craig Ringer
• 05:36   Re: shared_buffers/effective_cache_size on 96GB server Scott Marlowe
• 05:42   Re: Drawbacks of create index where is not null ? Scott Marlowe
• 05:44   Re: Drawbacks of create index where is not null ? Scott Marlowe
• 06:15   Re: hash aggregation Sergey Konoplev
• 08:22   Re: Drawbacks of create index where is not null ? Franck Routier
• 14:14   Re: Two identical systems, radically different performance Andrea Suisani
• 14:19   Re: Two identical systems, radically different performance Claudio Freire
• 14:40   Re: Two identical systems, radically different performance Andrea Suisani
• 15:15   Re: hash aggregation Korisk
• 17:55   Re: hash aggregation Sergey Konoplev
• 18:19   Re: shared_buffers/effective_cache_size on 96GB server Josh Berkus
• 21:46   Re: problems with large objects dump Sergio Gabriel Rodriguez
• 22:16   Re: problems with large objects dump Tom Lane
• 22:26   Re: problems with large objects dump Marcos Ortiz
• 22:31   Re: Drawbacks of create index where is not null ? Sergey Konoplev

12 октября 2012 г.

• 03:55   Re: hash aggregation Korisk
• 04:01   Re: hash aggregation Sergey Konoplev
• 04:14   Re: hash aggregation Korisk
• 04:33   Re: hash aggregation Ondrej Ivanič
• 07:10   Re: hash aggregation Sergey Konoplev
• 14:37   Re: hash aggregation Korisk
• 20:06   Do cast affects index usage? Anibal David Acosta
• 20:37   Re: Do cast affects index usage? Scott Marlowe
• 20:38   Re: Do cast affects index usage? Tom Lane
• 21:14   Re: hash aggregation Tomas Vondra
• 21:28   Re: hash aggregation Tomas Vondra
• 22:35   Re: problems with large objects dump Sergio Gabriel Rodriguez
• 23:18   Re: problems with large objects dump Tom Lane

13 октября 2012 г.

• 00:27   Re: Do cast affects index usage? Anibal David Acosta
• 01:32   Re: problems with large objects dump Tom Lane
• 01:34   Re: Do cast affects index usage? Tom Lane

14 октября 2012 г.

• 00:43   Index over all partitions (aka global index)? Stefan Keller
• 05:39   Re: Index over all partitions (aka global index)? Jeff Janes
• 06:55   Query with limit goes from few ms to hours henk de wit
• 07:04   Re: Query with limit goes from few ms to hours henk de wit
• 12:22   Re: Index over all partitions (aka global index)? Stefan Keller
• 16:15   Re: Query with limit goes from few ms to hours Tom Lane

15 октября 2012 г.

• 08:22   WebSphere Application Server support for postgres John Nash
• 08:27   Re: Two identical systems, radically different performance Andrea Suisani
• 10:19   Re: problems with large objects dump Sergio Gabriel Rodriguez
• 12:31   Re: Query with limit goes from few ms to hours Robert Klemme
• 15:01   Re: Two identical systems, radically different performance Craig James
• 15:01   Re: Two identical systems, radically different performance Claudio Freire
• 15:25   Re: Two identical systems, radically different performance Andrea Suisani
• 15:28   Re: Two identical systems, radically different performance Claudio Freire
• 15:32   Re: Two identical systems, radically different performance Scott Marlowe
• 15:34   Re: Two identical systems, radically different performance Scott Marlowe
• 15:45   Re: Two identical systems, radically different performance Andrea Suisani
• 15:56   Re: Two identical systems, radically different performance Andrea Suisani
• 15:56   Re: Two identical systems, radically different performance Andrea Suisani
• 17:50   Re: Query with limit goes from few ms to hours henk de wit
• 20:59   SELECT AND AGG huge tables houmanb
• 21:09   Re: SELECT AND AGG huge tables Merlin Moncure
• 21:42   Re: SELECT AND AGG huge tables Matheus de Oliveira
• 21:54   Re: SELECT AND AGG huge tables Ondrej Ivanič
• 23:45   Re: SELECT AND AGG huge tables Bob Lunney

16 октября 2012 г.

• 00:04   Re: SELECT AND AGG huge tables Jeff Janes
• 02:42   Re: SELECT AND AGG huge tables Craig Ringer
• 05:07   Re: Two identical systems, radically different performance Marinos Yannikos
• 07:50   Slow Delete : Seq scan instead of index scan Sylvain CAILLET
• 08:01   Re: Slow Delete : Seq scan instead of index scan Sékine Coulibaly
• 08:09   Re: Slow Delete : Seq scan instead of index scan Craig Ringer
• 08:13   Re: Slow Delete : Seq scan instead of index scan Sylvain CAILLET
• 08:24   Re: Slow Delete : Seq scan instead of index scan Sylvain CAILLET
• 08:41   Re: Slow Delete : Seq scan instead of index scan Filippos Kalamidas
• 08:47   LIKE op with B-Tree Index? Sam Wong
• 12:26   Support Create package Alejandro Carrillo
• 12:48   Re: Support Create package Pavel Stehule
• 12:53   Re: Support Create package ktm@rice.edu
• 17:38   Re: Guide to Posting Slow Query Questions Jeff Janes
• 19:11   LIKE op with B-Tree Index? Sam Wong
• 19:15   limit order by performance issue Pedro Jiménez
• 19:24   Re: limit order by performance issue Pavel Stehule
• 19:28   Re: limit order by performance issue Shaun Thomas
• 19:47   Re: limit order by performance issue Karl Denninger
• 20:29   Re: LIKE op with B-Tree Index? Merlin Moncure
• 22:11   Re: limit order by performance issue Marti Raudsepp
• 23:52   Have: Seq Scan - Want: Index Scan - what am I doing wrong? Chris Ruprecht

17 октября 2012 г.

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

18 октября 2012 г.

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

19 октября 2012 г.

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

20 октября 2012 г.

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

21 октября 2012 г.

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

22 октября 2012 г.

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

23 октября 2012 г.

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

24 октября 2012 г.

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

25 октября 2012 г.

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

26 октября 2012 г.

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

27 октября 2012 г.

• 04:50   Re: Slower Performance on Postgres 9.1.6 vs 8.2.11 Pavel Stehule

28 октября 2012 г.

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

29 октября 2012 г.

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

30 октября 2012 г.

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

31 октября 2012 г.

• 09:18   Re: Slow query, where am I going wrong? AndyG
• 09:37   Re: Slow query, where am I going wrong? Albe Laurenz
• 10:18   Re: Slow query, where am I going wrong? AndyG
• 10:24   Invalid memory alloc request size Mahavir Trivedi
• 10:29   Re: Invalid memory alloc request size Pavel Stehule
• 10:34   Re: Invalid memory alloc request size Samuel Gendler
• 10:56   Seq scan on big table, episode 2 Vincenzo Melandri
• 11:28   Re: Slow query, where am I going wrong? AndyG
• 11:47   Re: Seq scan on big table, episode 2 Vincenzo Melandri
• 13:05   Re: Seq scan on big table, episode 2 Shaun Thomas
• 13:30   Re: Slow query, where am I going wrong? Albe Laurenz
• 14:59   Re: Slow query, where am I going wrong? AndyG
• 16:45   Re: How to keep queries low latency as concurrency increases Jeff Janes
• 18:40   Re: How to keep queries low latency as concurrency increases Merlin Moncure
• 22:51   dbt2 performance regresses from 9.1.6 to 9.2.1 Dong Ye