Home > mailing lists

Mailing lists [pgsql-performance]

1 June 2011

00:44 Re: Hash Anti Join performance degradation Cédric Villemain
01:43 Re: Delete performance Craig Ringer
01:45 Re: Delete performance Jarrod Chesney
06:14 Re: Delete performance Greg Smith
09:19 Re: Speeding up loops in pl/pgsql function Reuven M. Lerner
13:26 Re: Speeding up loops in pl/pgsql function Merlin Moncure
18:53 Re: Strange behavior of child table. Jeff Davis
20:40 Problem query CS DBA
21:15 Re: Problem query Merlin Moncure
21:38 Re: Problem query Kevin Grittner
22:28 Re: Problem query CS DBA
22:33 Re: Problem query CS DBA
23:54 CLUSTER versus a dedicated table Robert James

2 June 2011

00:10 Understanding Hash Join performance Robert James
01:18 Re: CLUSTER versus a dedicated table mark
01:31 Re: Problem query Merlin Moncure
01:33 Re: CLUSTER versus a dedicated table Merlin Moncure
01:46 Re: Delete performance Jarrod Chesney
06:49 Re: Speeding up loops in pl/pgsql function Reuven M. Lerner
13:39 Re: Strange behavior of child table. Jenish
13:47 Re: Problem query Kevin Grittner
15:25 Re: Understanding Hash Join performance Kevin Grittner
15:52 Re: Problem query Kevin Grittner
15:53 Re: Problem query Shaun Thomas
16:36 Re: Problem query Kevin Grittner
18:54 Re: Problem query Shaun Thomas
19:04 Re: Understanding Hash Join performance Claudio Freire
19:05 Re: Understanding Hash Join performance Robert Haas
20:05 Re: Problem query Kevin Grittner
20:20 Re: Problem query CS DBA

3 June 2011

03:55 Re: Understanding Hash Join performance Robert Haas

5 June 2011

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

6 June 2011

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

7 June 2011

00:09 Re: not exits slow compared to not in. (nested loops killing me) Tom Lane
00:18 Re: not exits slow compared to not in. (nested loops killing me) mark
07:53 i want to ask monitory peformance memory postgresql with automatically Didik Prasetyo
08:19 Re: 8.4/9.0 simple query performance regression Vitalii Tymchyshyn
08:26 strange query plan with LIMIT anthony.shipman@symstream.com
09:59 Re: i want to ask monitory peformance memory postgresql with automatically Craig Ringer
10:44 Re: strange query plan with LIMIT Pavel Stehule
16:18 strange query plan with LIMIT anthony.shipman@symstream.com
16:40 Re: strange query plan with LIMIT tv@fuzzy.cz
16:55 Re: i want to ask monitory peformance memory postgresql with automatically Marcos Ortiz

8 June 2011

04:19 100% CPU Utilization when we run queries. bakkiya
05:07 Re: 100% CPU Utilization when we run queries. Craig Ringer
05:08 Re: strange query plan with LIMIT anthony.shipman@symstream.com
07:39 Re: strange query plan with LIMIT Claudio Freire
08:33 Re: strange query plan with LIMIT tv@fuzzy.cz
08:34 Re: strange query plan with LIMIT anthony.shipman@symstream.com
08:40 Re: strange query plan with LIMIT Pavel Stehule
09:05 Set of related slow queries John Williams
09:21 Re: Set of related slow queries Craig Ringer
09:36 Re: strange query plan with LIMIT anthony.shipman@symstream.com
09:47 Re: strange query plan with LIMIT tv@fuzzy.cz
09:58 Re: strange query plan with LIMIT Pavel Stehule
11:08 Re: Set of related slow queries tv@fuzzy.cz
11:30 Re: Set of related slow queries tv@fuzzy.cz
13:10 Re: Set of related slow queries Craig Ringer
13:36 Re: Set of related slow queries Shaun Thomas
15:18 Oracle v. Postgres 9.0 query performance Tony Capobianco
15:31 Re: Oracle v. Postgres 9.0 query performance tv@fuzzy.cz
15:33 Re: Oracle v. Postgres 9.0 query performance Tom Lane
15:40 Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
15:52 Re: Oracle v. Postgres 9.0 query performance Stephen Frost
15:52 Re: Oracle v. Postgres 9.0 query performance Vitalii Tymchyshyn
16:22 Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
16:28 Re: Oracle v. Postgres 9.0 query performance Pavel Stehule
16:28 Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
16:34 Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
16:37 Re: Set of related slow queries John Williams
17:04 Re: Oracle v. Postgres 9.0 query performance Tom Lane
17:18 Re: Oracle v. Postgres 9.0 query performance Pavel Stehule
19:03 Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
19:29 Re: poor performance when recreating constraints on large tables Robert Haas
19:31 Re: Oracle v. Postgres 9.0 query performance Kevin Grittner
19:39 Re: Oracle v. Postgres 9.0 query performance Samuel Gendler
19:45 Re: poor performance when recreating constraints on large tables Samuel Gendler
19:53 Re: poor performance when recreating constraints on large tables Kevin Grittner
19:55 Re: Oracle v. Postgres 9.0 query performance Tony Capobianco
19:57 Re: poor performance when recreating constraints on large tables Samuel Gendler
21:57 Re: poor performance when recreating constraints on large tables Claudio Freire

9 June 2011

05:57 Re: poor performance when recreating constraints on large tables Greg Smith
06:04 Re: strange query plan with LIMIT anthony.shipman@symstream.com
06:16 Re: strange query plan with LIMIT anthony.shipman@symstream.com
07:50 enable database user login/logout information muthu krishnan
07:55 Re: enable database user login/logout information Alexander Shulgin
09:20 Postgresql on itanium server muthu krishnan
09:30 Re: Postgresql on itanium server Jochen Erwied
10:03 Re: Postgresql on itanium server muthu krishnan
10:47 Re: Postgresql on itanium server Jochen Erwied
10:53 Re: Postgresql on itanium server Marti Raudsepp
11:43 Re: [PERFORMANCE] expanding to SAN: which portion best to move Willy-Bas Loos
12:04 Re: poor performance when recreating constraints on large tables Samuel Gendler
15:23 Re: Postgresql on itanium server Jochen Erwied
15:24 Triggering autovacuum Reuven M. Lerner
16:20 Re: Postgresql on itanium server Tom Lane
16:52 Re: Triggering autovacuum Greg Smith
17:44 Re: [GENERAL] [PERFORMANCE] expanding to SAN: which portion best to move Greg Smith

10 June 2011

02:21 Re: Oracle v. Postgres 9.0 query performance Tatsuo Ishii
02:25 Re: Oracle v. Postgres 9.0 query performance Tom Lane
07:39 Re: 100% CPU Utilization when we run queries. bakkiya
08:38 Re: strange query plan with LIMIT anthony.shipman@symstream.com
09:01 Re: 100% CPU Utilization when we run queries. Marti Raudsepp
10:02 Re: [GENERAL] [PERFORMANCE] expanding to SAN: which portion best to move Robert Klemme
11:23 Re: strange query plan with LIMIT tv@fuzzy.cz
11:58 how much postgres can scale up? Anibal David Acosta
12:10 Re: how much postgres can scale up? tv@fuzzy.cz
12:15 change sample size for statistics Willy-Bas Loos
12:37 Re: 100% CPU Utilization when we run queries. Craig Ringer
13:02 Re: how much postgres can scale up? Anibal David Acosta
13:02 Re: how much postgres can scale up? Craig Ringer
13:13 Re: how much postgres can scale up? Craig Ringer
13:19 Re: how much postgres can scale up? Anibal David Acosta
14:16 Re: how much postgres can scale up? Pierre C
15:22 Re: strange query plan with LIMIT Claudio Freire
16:21 Re: how much postgres can scale up? Pierre C
16:49 Re: how much postgres can scale up? Greg Smith
18:22 Re: how much postgres can scale up? Anibal David Acosta
19:58 Re: change sample size for statistics Josh Berkus
20:07 Re: change sample size for statistics Nathan Boley

11 June 2011

22:38 Re: Triggering autovacuum Reuven M. Lerner

12 June 2011

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

13 June 2011

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

14 June 2011

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

15 June 2011

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

16 June 2011

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

17 June 2011

08:42 Re: Performance advice for a new low(er)-power server Haestan
09:13 Re: Performance advice for a new low(er)-power server Haestan
09:30 Re: Performance advice for a new low(er)-power server jesper@krogh.cc
12:43 Re: seq scan in the case of max() on the primary key column Shaun Thomas
13:29 Re: Performance advice for a new low(er)-power server Merlin Moncure
13:50 Re: seq scan in the case of max() on the primary key column Svetlin Manavski
13:50 Degrading PostgreSQL 8.4 write performance Kabu Taah
14:08 Re: Degrading PostgreSQL 8.4 write performance Merlin Moncure
17:54 Re: Degrading PostgreSQL 8.4 write performance Greg Smith
18:00 Re: seq scan in the case of max() on the primary key column Greg Smith
23:19 Re: seq scan in the case of max() on the primary key column Jim Nasby

19 June 2011

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

20 June 2011

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

21 June 2011

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

22 June 2011

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

23 June 2011

15:55 Re: bitmask index Robert Klemme
16:05 Long Running Update Harry Mantheakis
17:18 Re: Long Running Update Claudio Freire
19:32 Re: Long Running Update Kevin Grittner
23:04 Re: Improve the Postgres Query performance Tripura

24 June 2011

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

27 June 2011

12:46 Getting rid of a seq scan in query on a large table Jens Hoffrichter
14:23 Performance issue with Insert Jenish
14:30 Re: Getting rid of a seq scan in query on a large table Kevin Grittner
14:38 Re: Performance issue with Insert Kevin Grittner
15:02 Re: Performance issue with Insert Jenish
15:02 Re: Long Running Update - My Solution Harry Mantheakis
15:12 Re: Long Running Update - My Solution Kevin Grittner
15:32 Re: Performance issue with Insert tv@fuzzy.cz
15:37 Re: Long Running Update - My Solution tv@fuzzy.cz
15:58 Re: Performance issue with Insert Jenish
16:12 Re: Performance issue with Insert Merlin Moncure
19:29 Re: Long Running Update - My Solution Robert Klemme
19:46 Re: Performance issue with Insert Tomas Vondra
19:48 Re: Performance issue with Insert Tomas Vondra
20:14 Re: Performance issue with Insert Jenish
20:47 Re: Performance issue with Insert Tomas Vondra
20:56 Re: Performance issue with Insert Kevin Grittner
23:01 Fw: Getting rid of a seq scan in query on a large table Denis de Bernardy

28 June 2011

00:37 Re: Long Running Update - My Solution Greg Smith
09:49 Re: Long Running Update - My Solution Harry Mantheakis
21:29 Slow performance when querying millions of rows Craig McIlwee
22:39 Re: Slow performance when querying millions of rows Tomas Vondra
22:43 Re: Slow performance when querying millions of rows Greg Smith
23:26 Re: Slow performance when querying millions of rows Craig McIlwee
23:51 Re: Slow performance when querying millions of rows Craig McIlwee

29 June 2011

00:03 Re: Slow performance when querying millions of rows Tomas Vondra
00:11 Re: Slow performance when querying millions of rows Tomas Vondra
00:51 Re: Slow performance when querying millions of rows Greg Smith
01:02 Re: Slow performance when querying millions of rows Greg Smith
02:55 Re: change sample size for statistics Robert Haas
16:18 is parallel union all possible over dblink? Svetlin Manavski
18:37 Re: is parallel union all possible over dblink? Marinos Yannikos
19:14 Re: is parallel union all possible over dblink? Greg Spiegelberg
19:38 Re: is parallel union all possible over dblink? Shaun Thomas

30 June 2011

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