Mailing lists [pgsql-performance]

2 January 2011

• 20:56   Re: encourging bitmap AND Jim Nasby
• 20:57   Re: CPU bound Jim Nasby

3 January 2011

• 01:03   Re: How to turn autovacuum prevent wrap around run faster? marc.hsiao
• 15:17   Re: CPU bound Mladen Gogala
• 23:33   Question: BlockSize > 8192 with FusionIO Strange, John W

4 January 2011

• 01:13   Re: Question: BlockSize > 8192 with FusionIO Greg Smith
• 01:28   Re: Performance of PostgreSQL over NFS Greg Smith
• 12:52   Re: adding foreign key constraint locks up table Florian Weimer
• 12:53   Re: concurrent IO in postgres? Greg Smith
• 13:07   Re: PostgreSQL Greg Smith
• 14:21   Re: adding foreign key constraint locks up table Tom Lane
• 15:49   Re: Question: BlockSize > 8192 with FusionIO Merlin Moncure
• 17:03   Same stament sometime fast, something slow Fernando Mertins
• 17:13   Re: Same stament sometime fast, something slow Kevin Grittner
• 17:37   Re: Question: BlockSize > 8192 with FusionIO Ben Chobot
• 19:07   Re: Question: BlockSize > 8192 with FusionIO Strange, John W
• 19:31   Re: Question: BlockSize > 8192 with FusionIO Strange, John W

5 January 2011

• 00:24   Re: Same stament sometime fast, something slow Craig Ringer
• 00:52   Re: Same stament sometime fast, something slow Greg Smith
• 05:49   Re: Question: BlockSize > 8192 with FusionIO Scott Carey
• 19:43   Wrong docs on wal_buffers? Josh Berkus
• 20:45   Re: Wrong docs on wal_buffers? Jeff Janes
• 21:57   plan question - query with order by and limit not choosing index depends on size of limit, table Mike Broers
• 21:58   Re: Wrong docs on wal_buffers? Pierre C
• 22:10   Re: plan question - query with order by and limit not choosing index depends on size of limit, table Kevin Grittner

6 January 2011

• 17:59   Re: Wrong docs on wal_buffers? Josh Berkus
• 20:32   Re: postgres performance tunning Robert Haas
• 20:36   Re: plan question - query with order by and limit not choosing index depends on size of limit, table Mike Broers
• 20:41   Re: postgres performance tunning Scott Marlowe
• 20:42   Re: postgres performance tunning Scott Marlowe
• 20:51   Re: Wrong docs on wal_buffers? Scott Carey
• 22:02   Re: Wrong docs on wal_buffers? Jeff Janes

7 January 2011

• 01:37   "SELECT .. WHERE NOT IN" query running for hours Γιωργος Βαλκανας
• 03:25   Re: "SELECT .. WHERE NOT IN" query running for hours Mladen Gogala
• 03:38   Re: Wrong docs on wal_buffers? Greg Smith
• 07:15   Re: How to turn autovacuum prevent wrap around run faster? marc.hsiao
• 07:55   Re: adding foreign key constraint locks up table kakarukeys
• 07:55   Re: Major performance problem after upgrade from 8.3 to 8.4 Marc Antonio
• 07:55   Re: How to turn autovacuum prevent wrap around run faster? marc47marc47
• 08:29   Re: "SELECT .. WHERE NOT IN" query running for hours Γιωργος Βαλκανας
• 11:45   Wrong docs on checkpoint_segments? Florian Weimer
• 12:39   Re: Wrong docs on checkpoint_segments? Andres Freund
• 12:45   Re: Wrong docs on checkpoint_segments? Florian Weimer
• 12:47   Re: Wrong docs on checkpoint_segments? Andres Freund
• 13:00   Re: plan question - query with order by and limit not choosing index depends on size of limit, table pasman pasmański
• 13:09   Re: Wrong docs on wal_buffers? Samuel Gendler
• 14:07   Re: Wrong docs on wal_buffers? Tom Lane
• 16:30   Re: Wrong docs on wal_buffers? Samuel Gendler
• 17:46   Re: Wrong docs on wal_buffers? Greg Smith

8 January 2011

• 00:59   pgbench to the MAXINT Greg Smith

9 January 2011

• 02:34   Re: adding foreign key constraint locks up table Robert Haas
• 12:58   Re: MySQL HandlerSocket - Is this possible in PG? Dimitri Fontaine

10 January 2011

• 04:17   Re: pgbench to the MAXINT Euler Taveira de Oliveira
• 07:25   Re: pgbench to the MAXINT Greg Smith
• 15:21   Re: plan question - query with order by and limit not choosing index depends on size of limit, table Mike Broers
• 16:28   Re: "SELECT .. WHERE NOT IN" query running for hours Mladen Gogala
• 19:32   Re: "SELECT .. WHERE NOT IN" query running for hours Scott Carey
• 19:38   Re: "SELECT .. WHERE NOT IN" query running for hours Kevin Grittner
• 20:03   Re: "SELECT .. WHERE NOT IN" query running for hours Scott Carey

11 January 2011

• 07:16   Re: Problems with FTS Rauan Maemirov
• 20:41   Re: pgbench to the MAXINT Euler Taveira de Oliveira

12 January 2011

• 00:43   Re: Performance of PostgreSQL over NFS Jignesh Shah
• 05:54   Performance test of Oracle and PostgreSQL using same binary Divakar Singh
• 07:21   Re: How to turn autovacuum prevent wrap around run faster? marc.hsiao
• 11:25   Slow query + why bitmap index scan?? Laszlo Nagy
• 12:42   Re: Slow query + why bitmap index scan?? Florian Weimer
• 12:49   The good, old times Mladen Gogala
• 13:16   Re: The good, old times Guillaume Cottenceau
• 13:22   Re: Slow query + why bitmap index scan?? Laszlo Nagy
• 13:27   Re: Slow query + why bitmap index scan?? Kenneth Marshall
• 13:37   Re: Slow query + why bitmap index scan?? Kevin Grittner
• 14:20   Re: Slow query + why bitmap index scan?? Laszlo Nagy
• 15:32   Re: Slow query + why bitmap index scan?? Kevin Grittner
• 16:12   Re: Performance test of Oracle and PostgreSQL using same binary Jeff Janes
• 19:15   Re: Slow query + why bitmap index scan?? Cédric Villemain

13 January 2011

• 14:55   queries with lots of UNIONed relations Jon Nelson
• 16:13   Re: queries with lots of UNIONed relations Tom Lane
• 18:54   Re: queries with lots of UNIONed relations Jon Nelson
• 19:05   Re: queries with lots of UNIONed relations Tom Lane
• 19:13   Re: queries with lots of UNIONed relations Jon Nelson
• 19:57   queries with lots of UNIONed relations Jon Nelson
• 19:57   Re: adding foreign key constraint locks up table kakarukeys
• 20:44   Re: queries with lots of UNIONed relations Robert Haas
• 21:26   Re: queries with lots of UNIONed relations Tom Lane
• 21:41   Re: queries with lots of UNIONed relations Robert Haas
• 21:42   Re: queries with lots of UNIONed relations Robert Haas
• 21:47   Re: queries with lots of UNIONed relations Andy Colson
• 21:49   Re: queries with lots of UNIONed relations Robert Haas
• 21:52   Re: queries with lots of UNIONed relations Andy Colson
• 21:53   Re: queries with lots of UNIONed relations Jon Nelson
• 22:05   Re: queries with lots of UNIONed relations Tom Lane
• 22:07   Re: queries with lots of UNIONed relations Tom Lane
• 22:14   Re: queries with lots of UNIONed relations Jon Nelson
• 23:10   Re: queries with lots of UNIONed relations Tom Lane

14 January 2011

• 02:19   Re: queries with lots of UNIONed relations Mladen Gogala
• 05:02   Re: The good, old times Craig Ringer
• 10:39   Re: queries with lots of UNIONed relations Vitalii Tymchyshyn
• 15:36   Re: plan question - query with order by and limit not choosing index depends on size of limit, table Mike Broers
• 15:55   Re: The good, old times Mladen Gogala
• 17:03   Re: plan question - query with order by and limit not choosing index depends on size of limit, table Robert Haas
• 18:01   Re: "SELECT .. WHERE NOT IN" query running for hours Robert Haas
• 18:03   Re: Problems with FTS Robert Haas
• 18:42   "COPY TO stdout" statements occurrence in log files Fernando Mertins
• 19:16   Re: queries with lots of UNIONed relations Jon Nelson
• 19:27   Re: "COPY TO stdout" statements occurrence in log files Maciek Sakrejda
• 20:17   Best way to get the latest revision from a table Nikolas Everett
• 21:25   Re: "COPY TO stdout" statements occurrence in log files Chris Browne
• 21:30   Re: Best way to get the latest revision from a table Kevin Grittner
• 21:40   Re: Best way to get the latest revision from a table Nikolas Everett
• 21:43   Re: "COPY TO stdout" statements occurrence in log files Marti Raudsepp
• 21:57   Re: Best way to get the latest revision from a table Kevin Grittner
• 22:22   Re: Best way to get the latest revision from a table Shaun Thomas
• 22:33   Re: Best way to get the latest revision from a table Kevin Grittner
• 22:40   Re: Best way to get the latest revision from a table Tom Lane

15 January 2011

• 00:00   Re: Best way to get the latest revision from a table Kevin Grittner
• 00:50   Re: Best way to get the latest revision from a table Nikolas Everett
• 12:37   Re: The good, old times Craig Ringer
• 17:02   Problem with query Barbara Woolums
• 17:22   Re: queries with lots of UNIONed relations Jon Nelson
• 18:58   Re: Best way to get the latest revision from a table Shaun Thomas
• 19:17   Re: Best way to get the latest revision from a table Shaun Thomas

16 January 2011

• 05:51   Re: The good, old times Craig Ringer

17 January 2011

• 02:22   Possible to improve query plan? Jeremy Palmer
• 03:22   Re: Possible to improve query plan? Andy Colson
• 03:44   Possible to improve query plan? Jeremy Palmer
• 03:57   Re: Possible to improve query plan? Andy Colson
• 04:13   Re: Possible to improve query plan? Jeremy Palmer
• 07:46   Re: Possible to improve query plan? Jayadevan M
• 12:30   Re: Possible to improve query plan? Ing. Marcos Ortiz Valmaseda
• 14:35   "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Achilleas Mantzios
• 15:44   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Ing. Marcos Ortiz Valmaseda
• 15:47   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Mladen Gogala
• 15:48   Re: Possible to improve query plan? Kevin Grittner
• 19:03   Bad plan when join on function Zotov
• 19:13   Re: Bad plan when join on function Pavel Stehule
• 19:24   Re: Possible to improve query plan? Tom Lane
• 19:51   Re: Bad plan when join on function Kevin Grittner
• 19:52   Re: Possible to improve query plan? Jeremy Palmer
• 20:01   Re: Possible to improve query plan? Jeremy Palmer
• 20:25   Re: Bad plan when join on function Pavel Stehule
• 20:33   Re: Bad plan when join on function Tom Lane
• 20:37   Re: Bad plan when join on function Pavel Stehule
• 21:11   Re: Possible to improve query plan? Mladen Gogala
• 22:42   Re: Problem with query Fernando Hevia

18 January 2011

• 07:06   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Achilleas Mantzios
• 07:43   Re: The good, old times Devrim GÜNDÜZ
• 08:04   Re: The good, old times Dave Page
• 13:15   Re: Bad plan when join on function Shaun Thomas
• 13:31   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Mladen Gogala
• 17:14   Migrating to Postgresql and new hardware Lars
• 17:57   Re: hashed subplan 5000x slower than two sequential operations masterchief
• 18:17   Re: Migrating to Postgresql and new hardware Andy Colson
• 18:19   Re: Migrating to Postgresql and new hardware Andy Colson
• 20:42   Re: hashed subplan 5000x slower than two sequential operations Віталій Тимчишин
• 21:06   Re: Migrating to Postgresql and new hardware Strange, John W
• 22:01   Re: Migrating to Postgresql and new hardware Mark Felder

19 January 2011

• 03:09   Re: Migrating to Postgresql and new hardware mark
• 06:26   Re: Migrating to Postgresql and new hardware Craig Ringer
• 06:49   Re: Migrating to Postgresql and new hardware Scott Marlowe
• 08:10   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Achilleas Mantzios
• 10:40   Re: Migrating to Postgresql and new hardware Lars
• 10:40   Re: Migrating to Postgresql and new hardware Lars
• 10:40   Re: Migrating to Postgresql and new hardware Lars
• 10:40   the XID question Charles.Hou
• 10:40   Re: the XID question Charles.Hou
• 11:01   Re: the XID question Filip Rembiałkowski
• 13:40   Re: the XID question Kevin Grittner
• 16:07   Re: Running PostgreSQL as fast as possible no matter the consequences Bruce Momjian
• 16:27   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Tom Lane
• 16:27   Re: Running PostgreSQL as fast as possible no matter the consequences Fabrízio de Royes Mello
• 17:25   Re: the XID question Chris Browne
• 17:32   Re: the XID question Andres Freund
• 17:41   Re: the XID question Kevin Grittner
• 18:47   Re: anti-join chosen even when slower than old plan Bruce Momjian
• 19:03   Re: anti-join chosen even when slower than old plan Bruce Momjian
• 19:04   Re: anti-join chosen even when slower than old plan Bruce Momjian
• 21:47   Re: the XID question Greg Smith
• 23:43   Re: Migrating to Postgresql and new hardware Craig Ringer

20 January 2011

• 05:18   Re: the XID question Charles.Hou
• 06:05   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Achilleas Mantzios
• 08:17   Re: anti-join chosen even when slower than old plan Cédric Villemain
• 13:19   Re: anti-join chosen even when slower than old plan Robert Haas
• 13:48   Re: Migrating to Postgresql and new hardware Andy Colson
• 14:08   Re: the XID question Charles.Hou
• 14:25   Re: Running PostgreSQL as fast as possible no matter the consequences Robert Haas
• 14:44   Re: Migrating to Postgresql and new hardware Scott Marlowe
• 15:16   Re: anti-join chosen even when slower than old plan Cédric Villemain
• 15:36   Re: anti-join chosen even when slower than old plan Cédric Villemain
• 16:05   Re: the XID question Kevin Grittner
• 19:12   copy command and blobs Madhu Ramachandran
• 19:17   Re: copy command and blobs Mladen Gogala
• 20:11   Re: copy command and blobs Tom Lane

21 January 2011

• 16:09   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Robert Haas
• 16:14   Re: Best way to get the latest revision from a table Robert Haas
• 16:42   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Mladen Gogala
• 16:49   Re: the XID question Robert Haas
• 16:51   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Robert Haas
• 17:13   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Mladen Gogala
• 17:16   Fun little performance IMPROVEMENT... grant@amadensor.com
• 17:29   Re: Fun little performance IMPROVEMENT... Andy Colson
• 17:55   Re: Best way to get the latest revision from a table Nikolas Everett
• 18:26   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Tom Lane
• 18:50   Re: Fun little performance IMPROVEMENT... Tom Lane
• 19:00   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Kevin Grittner
• 19:19   Re: Fun little performance IMPROVEMENT... Greg Smith
• 19:22   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Tom Lane
• 19:22   Re: Fun little performance IMPROVEMENT... grant@amadensor.com
• 19:27   Re: Fun little performance IMPROVEMENT... grant@amadensor.com
• 20:08   Re: Fun little performance IMPROVEMENT... Scott Carey
• 20:28   Re: Fun little performance IMPROVEMENT... grant@amadensor.com
• 20:30   Re: Fun little performance IMPROVEMENT... grant@amadensor.com
• 21:10   Re: copy command and blobs Madhu Ramachandran

23 January 2011

• 02:41   Re: copy command and blobs Robert Haas

24 January 2011

• 14:40   Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 Achilleas Mantzios
• 15:33   Re: Possible to improve query plan? Robert Haas
• 15:50   Re: Possible to improve query plan? Kevin Grittner
• 16:31   Re: Possible to improve query plan? Tom Lane
• 16:33   Re: Possible to improve query plan? Tom Lane
• 16:38   Re: Possible to improve query plan? Kevin Grittner
• 18:01   How to use indexes for GROUP BY Dimi Paun
• 18:27   Re: How to use indexes for GROUP BY Shaun Thomas
• 18:33   Re: How to use indexes for GROUP BY Scott Marlowe
• 19:07   Re: How to use indexes for GROUP BY hubert depesz lubaczewski
• 20:55   Re: Possible to improve query plan? Jeremy Palmer
• 22:55   Re: Possible to improve query plan? Kevin Grittner
• 23:01   Re: Possible to improve query plan? Kevin Grittner
• 23:25   Re: Possible to improve query plan? Jeremy Palmer

25 January 2011

• 01:26   Bloat issue on 8.3; autovac ignores HOT page splits? Josh Berkus
• 04:03   Re: How to use indexes for GROUP BY Dimi Paun
• 12:44   Re: Possible to improve query plan? Cédric Villemain
• 14:27   Re: Fun little performance IMPROVEMENT... Ivan Voras
• 15:41   Re: Bloat issue on 8.3; autovac ignores HOT page splits? Robert Haas
• 17:28   Re: Bloat issue on 8.3; autovac ignores HOT page splits? Josh Berkus
• 20:29   Re: Bloat issue on 8.3; autovac ignores HOT page splits? Mark Kirkwood
• 20:50   Queries becoming slow under heavy load Anne Rosset
• 21:12   Re: Queries becoming slow under heavy load Andy Colson
• 21:12   Re: Queries becoming slow under heavy load Kevin Grittner
• 21:27   Re: Queries becoming slow under heavy load Ing. Marcos Ortiz Valmaseda

26 January 2011

• 00:32   Re: Running PostgreSQL as fast as possible no matter the consequences Bruce Momjian
• 12:25   Re: Queries becoming slow under heavy load Ivan Voras
• 15:04   FW: Queries becoming slow under heavy load Anne Rosset
• 16:16   Re: FW: Queries becoming slow under heavy load Shaun Thomas
• 20:27   Real vs Int performance David Greco
• 20:53   Re: Real vs Int performance Kevin Grittner
• 21:12   Re: Real vs Int performance Tom Lane

27 January 2011

• 00:41   Re: anti-join chosen even when slower than old plan Bruce Momjian
• 01:35   Re: Queries becoming slow under heavy load mark
• 03:18   Re: FW: Queries becoming slow under heavy load Scott Marlowe
• 04:07   Re: FW: Queries becoming slow under heavy load Scott Marlowe
• 09:37   High load, Michael Kohl
• 10:24   Re: High load, Cédric Villemain
• 10:38   Re: High load, Michael Kohl
• 10:58   Re: High load, Cédric Villemain
• 11:25   Why I lost the last pg_xlog file? Waldomiro
• 11:35   Re: High load, Andres Freund
• 11:56   Re: High load, Michael Kohl
• 12:24   Re: High load, Cédric Villemain
• 12:26   Re: High load, Andres Freund
• 13:06   Re: High load, Justin Pitts
• 13:06   Re: Real vs Int performance David Greco
• 13:17   Re: Why I lost the last pg_xlog file? Shaun Thomas
• 13:18   Re: Real vs Int performance Tom Lane
• 13:30   Re: Real vs Int performance Shaun Thomas
• 13:51   Re: Why I lost the last pg_xlog file? Kevin Grittner
• 14:06   Re: High load, Andy Colson
• 14:09   Re: High load, Michael Kohl
• 14:11   Re: Real vs Int performance Mladen Gogala
• 14:41   Postgres 9.0 has a bias against indexes Mladen Gogala
• 14:45   Re: Postgres 9.0 has a bias against indexes Kenneth Marshall
• 14:49   Re: Postgres 9.0 has a bias against indexes Kevin Grittner
• 14:51   Re: Postgres 9.0 has a bias against indexes J Sisson
• 14:56   Re: Postgres 9.0 has a bias against indexes Mladen Gogala
• 14:57   Re: Postgres 9.0 has a bias against indexes Mladen Gogala
• 15:09   Re: Postgres 9.0 has a bias against indexes David Wilson
• 15:17   Re: Real vs Int performance Igor Neyman
• 15:40   Re: Postgres 9.0 has a bias against indexes Tom Lane
• 15:51   Re: Running PostgreSQL as fast as possible no matter the consequences Jeff Janes
• 16:00   Re: Postgres 9.0 has a bias against indexes Mladen Gogala
• 16:05   Re: High load, Scott Marlowe
• 16:07   Re: Running PostgreSQL as fast as possible no matter the consequences Bruce Momjian
• 16:20   Re: High load, Andy Colson
• 16:54   Re: High load, Stephen Frost
• 17:13   Re: High load, Scott Marlowe
• 17:14   Re: High load, Scott Marlowe
• 17:19   Re: High load, Andres Freund
• 18:26   Re: pgbench - tps for Postgresql-9.0.2 is more than tps for Postgresql-8.4.1 DM
• 19:11   Re: Postgres 9.0 has a bias against indexes Igor Neyman
• 19:21   Re: High load, Ing. Marcos Ortiz Valmaseda
• 19:32   Re: Postgres 9.0 has a bias against indexes Mladen Gogala
• 19:37   Re: Postgres 9.0 has a bias against indexes Scott Marlowe
• 19:44   Re: Postgres 9.0 has a bias against indexes Mladen Gogala
• 19:59   Re: Postgres 9.0 has a bias against indexes Scott Marlowe
• 20:13   Re: Postgres 9.0 has a bias against indexes Igor Neyman
• 20:16   Re: Postgres 9.0 has a bias against indexes Scott Marlowe
• 20:18   Re: Postgres 9.0 has a bias against indexes Igor Neyman
• 20:21   Re: Postgres 9.0 has a bias against indexes Kenneth Marshall
• 20:29   Re: Postgres 9.0 has a bias against indexes Scott Marlowe
• 20:31   Re: Postgres 9.0 has a bias against indexes Mladen Gogala
• 20:32   Re: Postgres 9.0 has a bias against indexes Igor Neyman
• 20:33   Re: Postgres 9.0 has a bias against indexes Scott Marlowe
• 20:33   Re: Postgres 9.0 has a bias against indexes Mladen Gogala
• 20:43   Re: Postgres 9.0 has a bias against indexes Kevin Grittner
• 22:11   How to best use 32 15k.7 300GB drives? Robert Schnabel
• 22:33   Re: How to best use 32 15k.7 300GB drives? david@lang.hm
• 23:11   Re: How to best use 32 15k.7 300GB drives? Alan Hodgson
• 23:27   Re: How to best use 32 15k.7 300GB drives? Robert Schnabel
• 23:53   Re: How to best use 32 15k.7 300GB drives? david@lang.hm

28 January 2011

• 04:12   Re: FW: Queries becoming slow under heavy load Anne Rosset
• 07:46   Re: High load, Michael Kohl
• 12:14   Re: How to best use 32 15k.7 300GB drives? Stephen Frost
• 12:17   Re: High load, Mladen Gogala
• 12:24   Re: How to best use 32 15k.7 300GB drives? Grant Johnson
• 13:06   Re: High load, Ivan Voras
• 14:31   Re: FW: Queries becoming slow under heavy load Shaun Thomas
• 15:40   Re: How to best use 32 15k.7 300GB drives? Robert Schnabel
• 16:00   Re: How to best use 32 15k.7 300GB drives? Scott Marlowe
• 16:10   Re: How to best use 32 15k.7 300GB drives? Robert Schnabel
• 16:14   Re: How to best use 32 15k.7 300GB drives? Stephen Frost
• 16:28   Re: How to best use 32 15k.7 300GB drives? Stephen Frost
• 16:42   Re: How to best use 32 15k.7 300GB drives? Scott Carey
• 16:45   Re: How to best use 32 15k.7 300GB drives? Scott Carey
• 16:48   Re: How to best use 32 15k.7 300GB drives? Scott Carey
• 17:46   Re: FW: Queries becoming slow under heavy load Mladen Gogala
• 17:55   Re: How to best use 32 15k.7 300GB drives? Scott Marlowe
• 19:09   postgres 9 query performance yazan suleiman
• 19:34   Re: postgres 9 query performance Scott Marlowe
• 19:50   Re: postgres 9 query performance Kenneth Marshall
• 20:19   Re: postgres 9 query performance Andres Freund
• 20:19   Re: How to best use 32 15k.7 300GB drives? Robert Schnabel
• 20:33   Re: How to best use 32 15k.7 300GB drives? Robert Schnabel
• 23:27   Re: Migrating to Postgresql and new hardware Greg Smith

29 January 2011

• 08:03   Re: postgres 9 query performance yazan suleiman
• 08:03   Re: postgres 9 query performance yazan suleiman

30 January 2011

• 15:26   Re: How to best use 32 15k.7 300GB drives? Віталій Тимчишин
• 18:25   Re: pgbench - tps for Postgresql-9.0.2 is more than tps for Postgresql-8.4.1 Robert Haas
• 19:19   Any experience using "shake" defragmenter? Mladen Gogala
• 20:31   Re: Any experience using "shake" defragmenter? Mark Felder
• 21:22   Re: postgres 9 query performance Tom Lane
• 21:35   Re: Any experience using "shake" defragmenter? Marcin Mirosław
• 21:43   Re: postgres 9 query performance Andres Freund

31 January 2011

• 03:49   Re: Any experience using "shake" defragmenter? Mladen Gogala
• 03:53   Re: Any experience using "shake" defragmenter? Mladen Gogala
• 15:49   Re: Any experience using "shake" defragmenter? Florian Weimer
• 15:50   Re: Any experience using "shake" defragmenter? Florian Weimer
• 17:58   Re: Bloat issue on 8.3; autovac ignores HOT new pages? Josh Berkus
• 19:12   Re: Migrating to Postgresql and new hardware Lars
• 19:12   Re: Any experience using "shake" defragmenter? Lew
• 20:28   Re: Bloat issue on 8.3; autovac ignores HOT new pages? Mark Kirkwood
• 20:57   Re: Bloat issue on 8.3; autovac ignores HOT new pages? Scott Marlowe
• 22:55   Configuration for a new server. Benjamin Krajmalnik