Mailing lists [pgsql-performance]

1 June 2011

• 03:14   Re: Delete performance Greg Smith
• 06:19   Re: Speeding up loops in pl/pgsql function Reuven M. Lerner
• 10:26   Re: Speeding up loops in pl/pgsql function Merlin Moncure
• 15:53   Re: Strange behavior of child table. Jeff Davis
• 17:40   Problem query CS DBA
• 18:15   Re: Problem query Merlin Moncure
• 18:38   Re: Problem query Kevin Grittner
• 19:28   Re: Problem query CS DBA
• 19:33   Re: Problem query CS DBA
• 20:54   CLUSTER versus a dedicated table Robert James
• 21:10   Understanding Hash Join performance Robert James
• 22:18   Re: CLUSTER versus a dedicated table mark
• 22:31   Re: Problem query Merlin Moncure
• 22:33   Re: CLUSTER versus a dedicated table Merlin Moncure
• 22:46   Re: Delete performance Jarrod Chesney

2 June 2011

• 03:49   Re: Speeding up loops in pl/pgsql function Reuven M. Lerner
• 10:39   Re: Strange behavior of child table. Jenish
• 10:47   Re: Problem query Kevin Grittner
• 12:25   Re: Understanding Hash Join performance Kevin Grittner
• 12:52   Re: Problem query Kevin Grittner
• 12:53   Re: Problem query Shaun Thomas
• 13:36   Re: Problem query Kevin Grittner
• 15:54   Re: Problem query Shaun Thomas
• 16:04   Re: Understanding Hash Join performance Claudio Freire
• 16:05   Re: Understanding Hash Join performance Robert Haas
• 17:05   Re: Problem query Kevin Grittner
• 17:20   Re: Problem query CS DBA

3 June 2011

• 00:55   Re: Understanding Hash Join performance Robert Haas

5 June 2011

• 12:25   Re: Why we don't want hints Was: Slow count(*) again... pasman pasmański

6 June 2011

• 05:21   Re: Why we don't want hints Was: Slow count(*) again... Robert Klemme
• 06:44   Re: Index use difference betweer LIKE, LIKE ANY? Heikki Linnakangas
• 06:47   Re: Index use difference betweer LIKE, LIKE ANY? Heikki Linnakangas
• 12:49   Re: Different execution time for same plan Kevin Grittner
• 17:35   poor performance when recreating constraints on large tables Mike Broers
• 17:38   Re: poor performance when recreating constraints on large tables Tom Lane
• 17:38   not exits slow compared to not in. (nested loops killing me) mark
• 18:46   8.4/9.0 simple query performance regression Josh Berkus
• 19:10   Re: poor performance when recreating constraints on large tables Mike Broers
• 20:02   Re: 8.4/9.0 simple query performance regression Tom Lane
• 20:07   Re: not exits slow compared to not in. (nested loops killing me) Craig Ringer
• 21:09   Re: not exits slow compared to not in. (nested loops killing me) Tom Lane
• 21:18   Re: not exits slow compared to not in. (nested loops killing me) mark

7 June 2011

• 04:53   i want to ask monitory peformance memory postgresql with automatically Didik Prasetyo
• 05:19   Re: 8.4/9.0 simple query performance regression Vitalii Tymchyshyn
• 05:26   strange query plan with LIMIT [email protected]
• 06:59   Re: i want to ask monitory peformance memory postgresql with automatically Craig Ringer
• 07:44   Re: strange query plan with LIMIT Pavel Stehule
• 13:18   strange query plan with LIMIT [email protected]
• 13:40   Re: strange query plan with LIMIT [email protected]
• 13:55   Re: i want to ask monitory peformance memory postgresql with automatically Marcos Ortiz

8 June 2011

• 01:19   100% CPU Utilization when we run queries. bakkiya
• 02:07   Re: 100% CPU Utilization when we run queries. Craig Ringer
• 02:08   Re: strange query plan with LIMIT [email protected]
• 04:39   Re: strange query plan with LIMIT Claudio Freire
• 05:33   Re: strange query plan with LIMIT [email protected]
• 05:34   Re: strange query plan with LIMIT [email protected]
• 05:40   Re: strange query plan with LIMIT Pavel Stehule
• 06:05   Set of related slow queries John Williams
• 06:21   Re: Set of related slow queries Craig Ringer
• 06:36   Re: strange query plan with LIMIT [email protected]
• 06:47   Re: strange query plan with LIMIT [email protected]
• 06:58   Re: strange query plan with LIMIT Pavel Stehule
• 08:08   Re: Set of related slow queries [email protected]
• 08:30   Re: Set of related slow queries [email protected]
• 10:10   Re: Set of related slow queries Craig Ringer
• 10:36   Re: Set of related slow queries Shaun Thomas
• 12:18   Oracle v. Postgres 9.0 query performance Tony Capobianco
• 12:31   Re: Oracle v. Postgres 9.0 query performance [email protected]
• 12:33   Re: Oracle v. Postgres 9.0 query performance Tom Lane
• 12:40   Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
• 12:52   Re: Oracle v. Postgres 9.0 query performance Stephen Frost
• 12:52   Re: Oracle v. Postgres 9.0 query performance Vitalii Tymchyshyn
• 13:22   Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
• 13:28   Re: Oracle v. Postgres 9.0 query performance Pavel Stehule
• 13:28   Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
• 13:34   Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
• 13:37   Re: Set of related slow queries John Williams
• 14:04   Re: Oracle v. Postgres 9.0 query performance Tom Lane
• 14:18   Re: Oracle v. Postgres 9.0 query performance Pavel Stehule
• 16:03   Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
• 16:29   Re: poor performance when recreating constraints on large tables Robert Haas
• 16:31   Re: Oracle v. Postgres 9.0 query performance Kevin Grittner
• 16:39   Re: Oracle v. Postgres 9.0 query performance Samuel Gendler
• 16:45   Re: poor performance when recreating constraints on large tables Samuel Gendler
• 16:53   Re: poor performance when recreating constraints on large tables Kevin Grittner
• 16:55   Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
• 16:57   Re: poor performance when recreating constraints on large tables Samuel Gendler
• 18:57   Re: poor performance when recreating constraints on large tables Claudio Freire

9 June 2011

• 02:57   Re: poor performance when recreating constraints on large tables Greg Smith
• 03:04   Re: strange query plan with LIMIT [email protected]
• 03:16   Re: strange query plan with LIMIT [email protected]
• 04:50   enable database user login/logout information muthu krishnan
• 04:55   Re: enable database user login/logout information Alexander Shulgin
• 06:20   Postgresql on itanium server muthu krishnan
• 06:30   Re: Postgresql on itanium server Jochen Erwied
• 07:03   Re: Postgresql on itanium server muthu krishnan
• 07:47   Re: Postgresql on itanium server Jochen Erwied
• 07:53   Re: Postgresql on itanium server Marti Raudsepp
• 08:43   Re: [PERFORMANCE] expanding to SAN: which portion best to move Willy-Bas Loos
• 09:04   Re: poor performance when recreating constraints on large tables Samuel Gendler
• 12:23   Re: Postgresql on itanium server Jochen Erwied
• 12:24   Triggering autovacuum Reuven M. Lerner
• 13:20   Re: Postgresql on itanium server Tom Lane
• 13:52   Re: Triggering autovacuum Greg Smith
• 14:44   Re: [GENERAL] [PERFORMANCE] expanding to SAN: which portion best to move Greg Smith
• 23:21   Re: Oracle v. Postgres 9.0 query performance Tatsuo Ishii
• 23:25   Re: Oracle v. Postgres 9.0 query performance Tom Lane

10 June 2011

• 04:39   Re: 100% CPU Utilization when we run queries. bakkiya
• 05:38   Re: strange query plan with LIMIT [email protected]
• 06:01   Re: 100% CPU Utilization when we run queries. Marti Raudsepp
• 07:02   Re: [GENERAL] [PERFORMANCE] expanding to SAN: which portion best to move Robert Klemme
• 08:23   Re: strange query plan with LIMIT [email protected]
• 08:58   how much postgres can scale up? Anibal David Acosta
• 09:10   Re: how much postgres can scale up? [email protected]
• 09:15   change sample size for statistics Willy-Bas Loos
• 09:37   Re: 100% CPU Utilization when we run queries. Craig Ringer
• 10:02   Re: how much postgres can scale up? Anibal David Acosta
• 10:02   Re: how much postgres can scale up? Craig Ringer
• 10:13   Re: how much postgres can scale up? Craig Ringer
• 10:19   Re: how much postgres can scale up? Anibal David Acosta
• 11:16   Re: how much postgres can scale up? Pierre C
• 12:22   Re: strange query plan with LIMIT Claudio Freire
• 13:21   Re: how much postgres can scale up? Pierre C
• 13:49   Re: how much postgres can scale up? Greg Smith
• 15:22   Re: how much postgres can scale up? Anibal David Acosta
• 16:58   Re: change sample size for statistics Josh Berkus
• 17:07   Re: change sample size for statistics Nathan Boley

11 June 2011

• 19:38   Re: Triggering autovacuum Reuven M. Lerner

12 June 2011

• 00:55   Re: Triggering autovacuum Scott Marlowe
• 12:15   Re: how much postgres can scale up? Benjamin Krajmalnik

13 June 2011

• 19:34   Re: change sample size for statistics Willy-Bas Loos

14 June 2011

• 13:01   need to repeat the same condition on joined tables in order to choose the proper plan Svetlin Manavski
• 13:29   Re: need to repeat the same condition on joined tables in order to choose the proper plan Tom Lane
• 17:21   Re: need to repeat the same condition on joined tables in order to choose the proper plan Robert Klemme

15 June 2011

• 12:39   Re: need to repeat the same condition on joined tables in order to choose the proper plan Svetlin Manavski

16 June 2011

• 01:35   Re: 100% CPU Utilization when we run queries. bakkiya
• 12:10   Performance advice for a new low(er)-power server Haestan
• 13:21   seq scan in the case of max() on the primary key column Svetlin Manavski
• 14:03   Re: seq scan in the case of max() on the primary key column Jesper Krogh
• 14:26   Re: seq scan in the case of max() on the primary key column Magnus Hagander
• 15:19   Re: Performance advice for a new low(er)-power server Merlin Moncure
• 15:29   Re: Performance advice for a new low(er)-power server Jesper Krogh
• 15:36   Re: seq scan in the case of max() on the primary key column Shaun Thomas
• 15:43   Re: Performance advice for a new low(er)-power server Greg Smith
• 15:52   Re: Performance advice for a new low(er)-power server Scott Marlowe
• 16:04   Re: Performance advice for a new low(er)-power server Merlin Moncure
• 16:40   generating a large XML document Julius Tuskenis
• 19:12   Re: Performance advice for a new low(er)-power server Greg Smith
• 19:44   Re: Performance advice for a new low(er)-power server Merlin Moncure

17 June 2011

• 05:42   Re: Performance advice for a new low(er)-power server Haestan
• 06:13   Re: Performance advice for a new low(er)-power server Haestan
• 06:30   Re: Performance advice for a new low(er)-power server [email protected]
• 09:43   Re: seq scan in the case of max() on the primary key column Shaun Thomas
• 10:29   Re: Performance advice for a new low(er)-power server Merlin Moncure
• 10:50   Re: seq scan in the case of max() on the primary key column Svetlin Manavski
• 10:50   Degrading PostgreSQL 8.4 write performance Kabu Taah
• 11:08   Re: Degrading PostgreSQL 8.4 write performance Merlin Moncure
• 14:54   Re: Degrading PostgreSQL 8.4 write performance Greg Smith
• 15:00   Re: seq scan in the case of max() on the primary key column Greg Smith
• 20:19   Re: seq scan in the case of max() on the primary key column Jim Nasby

19 June 2011

• 01:06   Large rows number, and large objects Jose Ildefonso Camargo Tolosa
• 08:38   Re: Large rows number, and large objects Samuel Gendler
• 12:49   Re: Large rows number, and large objects Craig James
• 15:59   hstore - Implementation and performance issues around its operators Stefan Keller
• 20:14   Re: Degrading PostgreSQL 8.4 write performance Pierre C
• 23:19   Re: Large rows number, and large objects Jose Ildefonso Camargo Tolosa

20 June 2011

• 03:18   Inoptimal query plan for max() and multicolumn index Vladimir Kulev
• 03:36   Re: generating a large XML document Julius Tuskenis
• 03:52   Re: generating a large XML document Pavel Stehule
• 04:21   Re: generating a large XML document Samuel Gendler
• 04:29   Re: generating a large XML document Julius Tuskenis
• 04:38   Re: generating a large XML document Julius Tuskenis
• 04:47   Re: generating a large XML document Pavel Stehule
• 04:57   how to know slowly query in lock postgre Didik Prasetyo
• 04:59   Re: generating a large XML document Pavel Stehule
• 06:03   Re: generating a large XML document Julius Tuskenis
• 06:45   Re: how to know slowly query in lock postgre Claudio Freire
• 12:41   Re: Inoptimal query plan for max() and multicolumn index Kevin Grittner
• 12:45   sequential scan unduly favored over text search gin index Sushant Sinha
• 12:58   Re: sequential scan unduly favored over text search gin index Kevin Grittner
• 13:01   bad plan: 8.4.8, hashagg, work_mem=1MB. Jon Nelson
• 13:04   Re: sequential scan unduly favored over text search gin index Sushant Sinha
• 13:08   Re: bad plan: 8.4.8, hashagg, work_mem=1MB. Tom Lane
• 15:59   Re: sequential scan unduly favored over text search gin index Jesper Krogh
• 16:01   Re: sequential scan unduly favored over text search gin index Tomas Vondra
• 16:09   Re: how to know slowly query in lock postgre Tomas Vondra
• 16:31   Re: bad plan: 8.4.8, hashagg, work_mem=1MB. Jon Nelson
• 23:25   Re: sequential scan unduly favored over text search gin index Sushant Sinha

21 June 2011

• 00:42   Cross Table (Pivot) Mario Guerrero
• 01:04   Contemplating SSD Hardware RAID Dan Harris
• 02:53   Re: sequential scan unduly favored over text search gin index Tom Lane
• 03:33   Re: Contemplating SSD Hardware RAID Greg Smith
• 04:24   Re: Inoptimal query plan for max() and multicolumn index Vladimir Kulev
• 04:52   Re: Contemplating SSD Hardware RAID Yeb Havinga
• 04:55   Re: Contemplating SSD Hardware RAID Yeb Havinga
• 07:49   Re: Inoptimal query plan for max() and multicolumn index F. BROUARD / SQLpro
• 08:19   Re: Contemplating SSD Hardware RAID Florian Weimer
• 12:12   Re: Contemplating SSD Hardware RAID Greg Smith
• 15:39   Re: Contemplating SSD Hardware RAID Anton Rommerskirchen
• 16:49   Re: seq scan in the case of max() on the primary key column Shaun Thomas
• 17:11   Re: Contemplating SSD Hardware RAID Yeb Havinga
• 17:26   Re: Contemplating SSD Hardware RAID Yeb Havinga
• 17:32   Re: Contemplating SSD Hardware RAID Scott Marlowe
• 18:35   Re: Contemplating SSD Hardware RAID Merlin Moncure
• 19:17   Re: Contemplating SSD Hardware RAID Greg Smith

22 June 2011

• 03:00   Improve the Postgres Query performance Tripura
• 04:05   Re: Improve the Postgres Query performance Craig Ringer
• 06:56   Re: seq scan in the case of max() on the primary key column Marti Raudsepp
• 10:12   Re: seq scan in the case of max() on the primary key column Shaun Thomas
• 12:50   Re: Contemplating SSD Hardware RAID Shaun Thomas
• 14:01   Re: seq scan in the case of max() on the primary key column Greg Smith
• 15:12   Re: seq scan in the case of max() on the primary key column Scott Marlowe
• 15:15   Re: seq scan in the case of max() on the primary key column Shaun Thomas
• 18:34   bitmask index Marcus Engene
• 18:35   Re: seq scan in the case of max() on the primary key column Greg Smith
• 18:42   Re: bitmask index Greg Smith

23 June 2011

• 12:55   Re: bitmask index Robert Klemme
• 13:05   Long Running Update Harry Mantheakis
• 14:18   Re: Long Running Update Claudio Freire
• 16:32   Re: Long Running Update Kevin Grittner
• 20:04   Re: Improve the Postgres Query performance Tripura

24 June 2011

• 08:16   Re: Long Running Update Harry Mantheakis
• 08:19   Re: Long Running Update Harry Mantheakis
• 08:40   Re: Long Running Update Claudio Freire
• 08:45   Re: Long Running Update Vitalii Tymchyshyn
• 09:40   Re: Long Running Update Harry Mantheakis
• 10:01   Re: Long Running Update Mark Thornton
• 10:43   Re: Long Running Update Kevin Grittner
• 11:00   Re: Long Running Update Kevin Grittner
• 11:43   Cost of creating an emply WAL segment Devrim GÜNDÜZ
• 12:12   Re: Long Running Update Kevin Grittner
• 13:18   Re: Cost of creating an emply WAL segment Greg Smith
• 13:29   Re: Long Running Update Harry Mantheakis
• 13:32   Re: Long Running Update Harry Mantheakis
• 13:41   Re: Long Running Update Kevin Grittner
• 13:50   Re: Long Running Update Harry Mantheakis
• 15:55   Re: Cost of creating an emply WAL segment Shaun Thomas
• 20:26   Re: Cost of creating an emply WAL segment Greg Smith

27 June 2011

• 09:46   Getting rid of a seq scan in query on a large table Jens Hoffrichter
• 11:23   Performance issue with Insert Jenish
• 11:30   Re: Getting rid of a seq scan in query on a large table Kevin Grittner
• 11:38   Re: Performance issue with Insert Kevin Grittner
• 12:02   Re: Performance issue with Insert Jenish
• 12:02   Re: Long Running Update - My Solution Harry Mantheakis
• 12:12   Re: Long Running Update - My Solution Kevin Grittner
• 12:32   Re: Performance issue with Insert [email protected]
• 12:37   Re: Long Running Update - My Solution [email protected]
• 12:58   Re: Performance issue with Insert Jenish
• 13:12   Re: Performance issue with Insert Merlin Moncure
• 16:29   Re: Long Running Update - My Solution Robert Klemme
• 16:46   Re: Performance issue with Insert Tomas Vondra
• 16:48   Re: Performance issue with Insert Tomas Vondra
• 17:14   Re: Performance issue with Insert Jenish
• 17:47   Re: Performance issue with Insert Tomas Vondra
• 17:56   Re: Performance issue with Insert Kevin Grittner
• 20:01   Fw: Getting rid of a seq scan in query on a large table Denis de Bernardy
• 21:37   Re: Long Running Update - My Solution Greg Smith

28 June 2011

• 06:49   Re: Long Running Update - My Solution Harry Mantheakis
• 18:29   Slow performance when querying millions of rows Craig McIlwee
• 19:39   Re: Slow performance when querying millions of rows Tomas Vondra
• 19:43   Re: Slow performance when querying millions of rows Greg Smith
• 20:26   Re: Slow performance when querying millions of rows Craig McIlwee
• 20:51   Re: Slow performance when querying millions of rows Craig McIlwee
• 21:03   Re: Slow performance when querying millions of rows Tomas Vondra
• 21:11   Re: Slow performance when querying millions of rows Tomas Vondra
• 21:51   Re: Slow performance when querying millions of rows Greg Smith
• 22:02   Re: Slow performance when querying millions of rows Greg Smith
• 23:55   Re: change sample size for statistics Robert Haas

29 June 2011

• 13:18   is parallel union all possible over dblink? Svetlin Manavski
• 15:37   Re: is parallel union all possible over dblink? Marinos Yannikos
• 16:14   Re: is parallel union all possible over dblink? Greg Spiegelberg
• 16:38   Re: is parallel union all possible over dblink? Shaun Thomas

30 June 2011

• 00:42   Re: sequential scan unduly favored over text search gin index Jeff Janes
• 00:59   Re: sequential scan unduly favored over text search gin index Jeff Janes
• 05:53   near identical queries have vastly different plans Samuel Gendler
• 06:40   Re: near identical queries have vastly different plans Samuel Gendler
• 09:37   Re: is parallel union all possible over dblink? Greg Spiegelberg
• 16:07   Re: Poor performance when joining against inherited tables Robert Haas
• 17:35   Re: near identical queries have vastly different plans Samuel Gendler