Mailing lists [pgsql-performance]

1 August 2013

• 04:58   Re: PG performance issues related to storage I/O waits KONDO Mitsumasa
• 12:55   Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 13:04   Re: Looks like merge join planning time is too big, 55 seconds Thomas Reiss
• 14:27   Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 14:45   Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 17:30   Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 18:17   Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 20:58   Re: Looks like merge join planning time is too big, 55 seconds David Kerr
• 20:58   Re: Performance bug in prepared statement binding in 9.2? Josh Berkus
• 21:24   Re: Looks like merge join planning time is too big, 55 seconds Jeff Janes
• 22:13   Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 22:20   Re: Performance bug in prepared statement binding in 9.2? Jeff Janes
• 22:40   subselect requires offset 0 for good performance. Scott Marlowe
• 22:51   Re: Looks like merge join planning time is too big, 55 seconds Jeff Janes

2 August 2013

• 00:15   Re: subselect requires offset 0 for good performance. Merlin Moncure
• 00:50   Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 02:44   Re: subselect requires offset 0 for good performance. Tom Lane
• 03:16   Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 04:22   Re: subselect requires offset 0 for good performance. Scott Marlowe
• 06:19   Re: Looks like merge join planning time is too big, 55 seconds Alvaro Herrera
• 10:37   Re: subselect requires offset 0 for good performance. Vik Fearing
• 16:43   Sub-optimal plan for a paginated query on a view with another view inside of it. 
• 18:29   Re: Looks like merge join planning time is too big, 55 seconds Jeff Janes
• 18:35   Re: Looks like merge join planning time is too big, 55 seconds Jeff Janes
• 18:50   Re: Looks like merge join planning time is too big, 55 seconds Tom Lane
• 19:20   Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 20:08   Re: subselect requires offset 0 for good performance. Scott Marlowe
• 20:11   Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 20:16   Re: Looks like merge join planning time is too big, 55 seconds Alvaro Herrera
• 22:31   Re: subselect requires offset 0 for good performance. Tom Lane
• 22:43   Re: Looks like merge join planning time is too big, 55 seconds Tom Lane
• 22:58   Re: subselect requires offset 0 for good performance. Scott Marlowe
• 23:26   Re: subselect requires offset 0 for good performance. Scott Marlowe
• 23:51   Re: subselect requires offset 0 for good performance. Tom Lane

3 August 2013

• 00:03   Re: to many locks held Kevin Grittner
• 00:18   Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan
• 00:27   Re: subselect requires offset 0 for good performance. Scott Marlowe
• 23:38   Re: PG performance issues related to storage I/O waits Tomas Vondra

5 August 2013

• 11:14   Re: Sub-optimal plan for a paginated query on a view with another view inside of it. 
• 23:28   Re: PG performance issues related to storage I/O waits Tomas Vondra

6 August 2013

• 02:04   ORDER BY, LIMIT and indexes Ivan Voras
• 02:26   Re: ORDER BY, LIMIT and indexes Claudio Freire
• 03:20   Re: ORDER BY, LIMIT and indexes Michael Paquier
• 04:22   Re: ORDER BY, LIMIT and indexes Josh Berkus
• 04:43   Re: ORDER BY, LIMIT and indexes Sergey Konoplev
• 04:54   Re: ORDER BY, LIMIT and indexes David Johnston
• 07:47   Re: PG performance issues related to storage I/O waits Tasos Petalas
• 13:05   Re: ORDER BY, LIMIT and indexes Ivan Voras
• 13:47   Re: ORDER BY, LIMIT and indexes Ivan Voras
• 18:47   Re: ORDER BY, LIMIT and indexes Claudio Freire
• 19:10   Re: ORDER BY, LIMIT and indexes Nikolas Everett
• 19:57   Re: ORDER BY, LIMIT and indexes Jeff Janes
• 22:02   Re: Sub-optimal plan for a paginated query on a view with another view inside of it. Pavel Stehule

7 August 2013

• 01:12   Re: subselect requires offset 0 for good performance. Scott Marlowe
• 01:56   Re: ORDER BY, LIMIT and indexes Mark Kirkwood
• 02:04   Re: ORDER BY, LIMIT and indexes Claudio Freire
• 02:10   Re: ORDER BY, LIMIT and indexes Claudio Freire
• 02:51   Re: ORDER BY, LIMIT and indexes Sergey Konoplev
• 03:00   Re: ORDER BY, LIMIT and indexes Sergey Konoplev
• 07:53   Re: ORDER BY, LIMIT and indexes Tom Lane
• 15:42   Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. 
• 16:46   Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Igor Neyman
• 17:43   RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. 
• 17:48   Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Igor Neyman
• 17:49   Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Pavel Stehule
• 17:50   Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Pavel Stehule
• 18:33   RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. 
• 18:39   Better performance possible for a pathological query? Alexis Lê-Quôc
• 18:50   Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Igor Neyman
• 18:53   Re: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Tom Lane
• 19:07   Re: Better performance possible for a pathological query? Tom Lane
• 19:29   Re: Better performance possible for a pathological query? Alexis Lê-Quôc
• 21:12   Efficiently query for the most recent record for a given user Robert DiFalco
• 21:19   Re: Efficiently query for the most recent record for a given user Claudio Freire
• 21:34   Re: Efficiently query for the most recent record for a given user Tom Lane
• 21:35   Re: Efficiently query for the most recent record for a given user Igor Neyman
• 21:39   Re: Efficiently query for the most recent record for a given user Robert DiFalco
• 21:39   Re: Efficiently query for the most recent record for a given user Claudio Freire
• 22:04   Re: Efficiently query for the most recent record for a given user Tom Lane
• 22:05   Re: Efficiently query for the most recent record for a given user Alvaro Herrera
• 22:13   Re: Efficiently query for the most recent record for a given user Claudio Freire

8 August 2013

• 09:59   Re: [PERFORM] RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. 
• 21:06   Efficient Correlated Update Robert DiFalco
• 23:09   Re: Efficiently query for the most recent record for a given user Claudio Freire

9 August 2013

• 01:09   Re: subselect requires offset 0 for good performance. Vik Fearing
• 01:21   Re: Efficient Correlated Update Robert DiFalco
• 18:44   Re: Efficient Correlated Update Kevin Grittner
• 18:49   Re: Efficient Correlated Update Klaus Ita
• 18:52   Re: Efficient Correlated Update Robert DiFalco
• 18:54   Re: Efficient Correlated Update Igor Neyman

12 August 2013

• 15:22   function execute on v.9.2 slow down Александр Белинский
• 18:00   Function execute slow down in 9.2 Александр Белинский
• 18:25   Re: Function execute slow down in 9.2 Pavel Stehule

13 August 2013

• 23:48   Index on a range array Daniel Cristian Cruz

14 August 2013

• 00:01   Re: subselect requires offset 0 for good performance. Scott Marlowe
• 01:51   Re: subselect requires offset 0 for good performance. Tom Lane
• 02:42   Re: subselect requires offset 0 for good performance. Scott Marlowe
• 03:41   Interesting case of IMMUTABLE significantly hurting performance Craig Ringer
• 05:48   Re: Interesting case of IMMUTABLE significantly hurting performance Craig Ringer
• 06:53   Re: Interesting case of IMMUTABLE significantly hurting performance Pavel Stehule
• 06:57   Re: Interesting case of IMMUTABLE significantly hurting performance Craig Ringer
• 07:17   Re: Interesting case of IMMUTABLE significantly hurting performance Tom Lane
• 07:44   Re: Interesting case of IMMUTABLE significantly hurting performance Craig Ringer
• 08:39   Need some basic information M Tarkeshwar Rao
• 15:21   Re: Index on a range array Daniel Cristian Cruz
• 18:33   queries with DISTINCT / GROUP BY giving different plans Tomas Vondra
• 21:35   Re: queries with DISTINCT / GROUP BY giving different plans Tom Lane
• 22:05   Re: Interesting case of IMMUTABLE significantly hurting performance Tom Lane

15 August 2013

• 10:31   Re: Index on a range array Heikki Linnakangas

16 August 2013

• 03:57   Re: Need some basic information Josh Berkus
• 07:13   DBT5 execution failed due to undefined symbol: PQescapeLiteral amul sul
• 10:26   Re: DBT5 execution failed due to undefined symbol: PQescapeLiteral Albe Laurenz
• 15:28   Re: Function execute slow down in 9.2 Александр Белинский
• 22:20   Re: queries with DISTINCT / GROUP BY giving different plans Tomas Vondra
• 22:36   Re: queries with DISTINCT / GROUP BY giving different plans Tomas Vondra

17 August 2013

• 23:19   Create one query out of two Robert DiFalco

18 August 2013

• 03:31   Re: Create one query out of two Calvin Dodge
• 23:23   Re: Create one query out of two Kevin Grittner

20 August 2013

• 04:44   How to investiage slow insert problem Rural Hunter
• 05:38   Re: How to investiage slow insert problem Sergey Konoplev
• 05:46   Re: How to investiage slow insert problem Rural Hunter
• 06:01   Re: How to investiage slow insert problem Sergey Konoplev
• 07:34   Re: How to investiage slow insert problem Jeff Janes
• 08:30   Re: How to investiage slow insert problem Rural Hunter
• 10:14   Re: DBT5 execution failed due to undefined symbol: PQescapeLiteral amulsul
• 18:13   Re: queries with DISTINCT / GROUP BY giving different plans Tomas Vondra
• 19:25   Re: queries with DISTINCT / GROUP BY giving different plans Tom Lane
• 20:56   Re: queries with DISTINCT / GROUP BY giving different plans Tomas Vondra
• 21:07   Can query planner prefer a JOIN over a high-cost Function? David McNett
• 22:53   Re: Can query planner prefer a JOIN over a high-cost Function? Tom Lane

21 August 2013

• 00:02   Re: queries with DISTINCT / GROUP BY giving different plans Tom Lane
• 01:21   Re: queries with DISTINCT / GROUP BY giving different plans Tomas Vondra
• 02:32   Re: queries with DISTINCT / GROUP BY giving different plans Tom Lane
• 03:24   How to investiage slow insert problem Jeff Janes
• 04:33   Re: How to investiage slow insert problem Rural Hunter
• 12:04   Re: Function execute slow down in 9.2 Pavel Stehule
• 16:10   Re: How to investiage slow insert problem Matheus de Oliveira
• 16:17   Re: How to investiage slow insert problem Matheus de Oliveira

22 August 2013

• 14:30   PostgreSQL 9.2.4 very slow on laptop with windows 8 girish subbaramu
• 18:26   Re: PostgreSQL 9.2.4 very slow on laptop with windows 8 Imre Samu

23 August 2013

• 11:14   Re: PostgreSQL 9.2.4 very slow on laptop with windows 8 Richard Huxton

26 August 2013

• 08:10   Poor performance on simple queries compared to sql server express Adam Ma'ruf
• 09:37   Re: Poor performance on simple queries compared to sql server express Pavel Stehule
• 10:23   Re: PostgreSQL 9.2.4 very slow on laptop with windows 8 girish subbaramu
• 14:04   stable and immutable functions in GROUP BY clauses. Marc Mamin
• 15:33   SQL statement over 500% slower with 9.2 compared with 9.1 Rafael Martinez
• 16:02   Re: Poor performance on simple queries compared to sql server express Adam Ma'ruf
• 16:40   Re: Poor performance on simple queries compared to sql server express Tomas Vondra

27 August 2013

• 07:06   Re: Poor performance on simple queries compared to sql server express Adam Ma'ruf
• 10:57   Cpu usage 100% on slave. s_lock problem. Дмитрий Дегтярёв
• 12:19   Re: SQL statement over 500% slower with 9.2 compared with 9.1 Rafael Martinez
• 16:23   Re: Cpu usage 100% on slave. s_lock problem. Merlin Moncure
• 16:39   Re: Cpu usage 100% on slave. s_lock problem. Merlin Moncure
• 17:13   Re: Cpu usage 100% on slave. s_lock problem. Merlin Moncure
• 17:57   Re: Cpu usage 100% on slave. s_lock problem. Merlin Moncure
• 18:56   Re: Cpu usage 100% on slave. s_lock problem. Andres Freund
• 20:18   Re: Cpu usage 100% on slave. s_lock problem. Merlin Moncure

28 August 2013

• 00:27   Re: SQL statement over 500% slower with 9.2 compared with 9.1 Tomas Vondra
• 00:37   Re: Poor performance on simple queries compared to sql server express Tomas Vondra
• 07:10   Re: SQL statement over 500% slower with 9.2 compared with 9.1 Jeff Janes
• 12:07   Re: SQL statement over 500% slower with 9.2 compared with 9.1 Rafael Martinez
• 13:15   Re: SQL statement over 500% slower with 9.2 compared with 9.1 Rafael Martinez
• 22:08   Re: SQL statement over 500% slower with 9.2 compared with 9.1 Tom Lane
• 23:39   Poor OFFSET performance in PostgreSQL 9.1.6 

29 August 2013

• 00:26   Re: Poor OFFSET performance in PostgreSQL 9.1.6 Greg Spiegelberg
• 01:08   Re: Poor OFFSET performance in PostgreSQL 9.1.6 
• 02:10   Re: Poor OFFSET performance in PostgreSQL 9.1.6 Merlin Moncure
• 07:43   Re: Poor OFFSET performance in PostgreSQL 9.1.6 David Rowley
• 14:00   Re: Poor OFFSET performance in PostgreSQL 9.1.6 hubert depesz lubaczewski
• 15:14   How clustering for scale out works in PostgreSQL bsreejithin
• 17:59   Re: How clustering for scale out works in PostgreSQL Richard Huxton
• 18:08   Re: How clustering for scale out works in PostgreSQL Joshua D. Drake
• 19:13   Re: How clustering for scale out works in PostgreSQL bsreejithin
• 19:21   Re: How clustering for scale out works in PostgreSQL Mike Blackwell
• 19:42   Re: How clustering for scale out works in PostgreSQL bsreejithin
• 19:46   Re: How clustering for scale out works in PostgreSQL Joshua D. Drake
• 19:50   Re: How clustering for scale out works in PostgreSQL Igor Neyman
• 19:52   Re: How clustering for scale out works in PostgreSQL bsreejithin
• 19:54   Re: How clustering for scale out works in PostgreSQL bsreejithin
• 20:45   Re: How clustering for scale out works in PostgreSQL Thomas Kellerer
• 20:48   Re: How clustering for scale out works in PostgreSQL bsreejithin

30 August 2013

• 05:22   Optimising views Bastiaan Olij
• 12:06   Query plan change with multiple elements in IN clause Mathieu De Zutter
• 17:01   Re: Query plan change with multiple elements in IN clause Tom Lane

31 August 2013

• 16:36   Varchar vs foreign key vs enumerator - table and index size Łukasz Walkowski
• 17:44   Re: How clustering for scale out works in PostgreSQL Kevin Grittner
• 18:21   Re: Varchar vs foreign key vs enumerator - table and index size Tom Lane
• 20:06   Re: Varchar vs foreign key vs enumerator - table and index size Łukasz Walkowski