pgsql-performance since 2013-07-20 00:00

Discussion of PostgreSQL's performance issues. Please see Guide to reporting problems and Slow Query Questions for some tips on how to write your performance question.

Search the Archives

(enter a message-id to go directly to that message)
Advanced Search

Browse Archives

Prev | Next

July 20, 2013

Thread Author Time
Re: FTS performance issue - planner problem identified (but only partially resolved) Marc Mamin 08:46

July 23, 2013

Thread Author Time
Fw: [osdldbt-general] Running DBT5 on remote database server amul sul 02:13

July 25, 2013

Thread Author Time
Re: Fw: [osdldbt-general] Running DBT5 on remote database server Samrat Revagade 13:03
How is memory allocated/used by Postgresql Database connections McKinzie, Alan (Alan) 13:23
Re: Fw: [osdldbt-general] Running DBT5 on remote database server sachin kotwal 13:26
Re: How is memory allocated/used by Postgresql Database connections Tom Lane 13:41
Re: How is memory allocated/used by Postgresql Database connections Jeff Janes 17:32

July 29, 2013

Thread Author Time
Re: FTS performance issue - planner problem identified (but only partially resolved) Kevin Grittner 20:28
Re: FTS performance issue - planner problem identified (but only partially resolved) Stefan Keller 23:29

July 30, 2013

Thread Author Time
to many locks held Jeison Bedoya 10:52
Re: to many locks held bricklen 14:48

July 31, 2013

Thread Author Time
Re: to many locks held Michael Paquier 05:18
PG performance issues related to storage I/O waits Tasos Petalas 11:58
Re: PG performance issues related to storage I/O waits Tomas Vondra 12:40
Re: Fw: [osdldbt-general] Running DBT5 on remote database server Greg Smith 16:02

Aug. 1, 2013

Thread Author Time
Re: PG performance issues related to storage I/O waits KONDO Mitsumasa 02:02
Looks like merge join planning time is too big, 55 seconds Sergey Burladyan 09:55
Re: Looks like merge join planning time is too big, 55 seconds Thomas Reiss 10:04
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan 11:27
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan 11:45
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan 14:30
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan 15:17
Re: Looks like merge join planning time is too big, 55 seconds David Kerr 17:58
Re: Performance bug in prepared statement binding in 9.2? Josh Berkus 17:58
Re: Looks like merge join planning time is too big, 55 seconds Jeff Janes 18:23
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan 19:13
Re: Performance bug in prepared statement binding in 9.2? Jeff Janes 19:20
subselect requires offset 0 for good performance. Scott Marlowe 19:40
Re: Looks like merge join planning time is too big, 55 seconds Jeff Janes 19:51
Re: subselect requires offset 0 for good performance. Merlin Moncure 21:15
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan 21:50
Re: subselect requires offset 0 for good performance. Tom Lane 23:44

Aug. 2, 2013

Thread Author Time
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan 00:16
Re: subselect requires offset 0 for good performance. Scott Marlowe 01:22
Re: Looks like merge join planning time is too big, 55 seconds Alvaro Herrera 03:19
Re: subselect requires offset 0 for good performance. Vik Fearing 07:37
Sub-optimal plan for a paginated query on a view with another view inside of it. slapo 13:43
Re: Looks like merge join planning time is too big, 55 seconds Jeff Janes 15:29
Re: Looks like merge join planning time is too big, 55 seconds Jeff Janes 15:35
Re: Looks like merge join planning time is too big, 55 seconds Tom Lane 15:50
Re: Looks like merge join planning time is too big, 55 seconds 📎 Sergey Burladyan 16:20
Re: Looks like merge join planning time is too big, 55 seconds Alvaro Herrera 16:23
Re: subselect requires offset 0 for good performance. Scott Marlowe 17:08
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan 17:11
Re: subselect requires offset 0 for good performance. Tom Lane 19:31
Re: Looks like merge join planning time is too big, 55 seconds Tom Lane 19:43
Re: subselect requires offset 0 for good performance. Scott Marlowe 19:58
Re: subselect requires offset 0 for good performance. Scott Marlowe 20:26
Re: subselect requires offset 0 for good performance. Tom Lane 20:51
Re: to many locks held Kevin Grittner 21:03
Re: Looks like merge join planning time is too big, 55 seconds Sergey Burladyan 21:17
Re: subselect requires offset 0 for good performance. Scott Marlowe 21:27

Aug. 3, 2013

Thread Author Time
Re: PG performance issues related to storage I/O waits Tomas Vondra 20:38

Aug. 5, 2013

Thread Author Time
Re: Sub-optimal plan for a paginated query on a view with another view inside of it. slapo 08:14
Re: PG performance issues related to storage I/O waits Tomas Vondra 20:28
ORDER BY, LIMIT and indexes Ivan Voras 23:04
Re: ORDER BY, LIMIT and indexes Claudio Freire 23:25

Aug. 6, 2013

Thread Author Time
Re: ORDER BY, LIMIT and indexes Michael Paquier 00:20
Re: ORDER BY, LIMIT and indexes Josh Berkus 01:22
Re: ORDER BY, LIMIT and indexes Sergey Konoplev 01:42
Re: ORDER BY, LIMIT and indexes David Johnston 01:54
Re: PG performance issues related to storage I/O waits Tasos Petalas 04:46
Re: ORDER BY, LIMIT and indexes Ivan Voras 10:04
Re: ORDER BY, LIMIT and indexes Ivan Voras 10:46
Re: ORDER BY, LIMIT and indexes Claudio Freire 15:47
Re: ORDER BY, LIMIT and indexes Nikolas Everett 16:09
Re: ORDER BY, LIMIT and indexes Jeff Janes 16:57
Re: Sub-optimal plan for a paginated query on a view with another view inside of it. Pavel Stehule 19:01
Re: subselect requires offset 0 for good performance. Scott Marlowe 22:12
Re: ORDER BY, LIMIT and indexes Mark Kirkwood 22:56
Re: ORDER BY, LIMIT and indexes Claudio Freire 23:03
Re: ORDER BY, LIMIT and indexes Claudio Freire 23:09
Re: ORDER BY, LIMIT and indexes Sergey Konoplev 23:50

Aug. 7, 2013

Thread Author Time
Re: ORDER BY, LIMIT and indexes Sergey Konoplev 00:00
Re: ORDER BY, LIMIT and indexes Tom Lane 04:52
Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. slapo 12:42
Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Igor Neyman 13:46
RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. slapo 14:42
Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Igor Neyman 14:48
Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Pavel Stehule 14:48
Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Pavel Stehule 14:49
RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. slapo 15:33
Better performance possible for a pathological query? Alexis Lê-Quôc 15:38
Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Igor Neyman 15:50
Re: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. Tom Lane 15:53
Re: Better performance possible for a pathological query? Tom Lane 16:07
Re: Better performance possible for a pathological query? Alexis Lê-Quôc 16:28
Efficiently query for the most recent record for a given user Robert DiFalco 18:12
Re: Efficiently query for the most recent record for a given user Claudio Freire 18:19
Re: Efficiently query for the most recent record for a given user Tom Lane 18:34
Re: Efficiently query for the most recent record for a given user Igor Neyman 18:35
Re: Efficiently query for the most recent record for a given user Robert DiFalco 18:39
Re: Efficiently query for the most recent record for a given user Claudio Freire 18:39
Re: Efficiently query for the most recent record for a given user Tom Lane 19:04
Re: Efficiently query for the most recent record for a given user Alvaro Herrera 19:05
Re: Efficiently query for the most recent record for a given user Claudio Freire 19:13

Aug. 8, 2013

Thread Author Time
Re: [PERFORM] RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it. slapo 06:59
Efficient Correlated Update Robert DiFalco 18:06
Re: Efficiently query for the most recent record for a given user Claudio Freire 20:08
Re: subselect requires offset 0 for good performance. Vik Fearing 22:09
Re: Efficient Correlated Update Robert DiFalco 22:21

Aug. 9, 2013

Thread Author Time
Re: Efficient Correlated Update Kevin Grittner 15:44
Re: Efficient Correlated Update Klaus Ita 15:49
Re: Efficient Correlated Update Robert DiFalco 15:52
Re: Efficient Correlated Update Igor Neyman 15:54

Aug. 12, 2013

Thread Author Time
function execute on v.9.2 slow down Александр Белинский 12:21
Function execute slow down in 9.2 Александр Белинский 14:59
Re: Function execute slow down in 9.2 Pavel Stehule 15:24

Aug. 13, 2013

Thread Author Time
Index on a range array Daniel Cristian Cruz 20:47
Re: subselect requires offset 0 for good performance. Scott Marlowe 21:01
Re: subselect requires offset 0 for good performance. Tom Lane 22:50
Re: subselect requires offset 0 for good performance. Scott Marlowe 23:42

Aug. 14, 2013

Thread Author Time
Interesting case of IMMUTABLE significantly hurting performance Craig Ringer 00:41
Re: Interesting case of IMMUTABLE significantly hurting performance Craig Ringer 02:46
Re: Interesting case of IMMUTABLE significantly hurting performance Pavel Stehule 03:52
Re: Interesting case of IMMUTABLE significantly hurting performance Craig Ringer 03:57
Re: Interesting case of IMMUTABLE significantly hurting performance Tom Lane 04:17
Re: Interesting case of IMMUTABLE significantly hurting performance Craig Ringer 04:44
Need some basic information M Tarkeshwar Rao 05:38
Re: Index on a range array Daniel Cristian Cruz 12:21
queries with DISTINCT / GROUP BY giving different plans Tomas Vondra 15:33
Re: queries with DISTINCT / GROUP BY giving different plans Tom Lane 18:35
Re: Interesting case of IMMUTABLE significantly hurting performance Tom Lane 19:05

Aug. 15, 2013

Thread Author Time
Re: Index on a range array Heikki Linnakangas 07:30

Aug. 16, 2013

Thread Author Time
Re: Need some basic information Josh Berkus 00:57
DBT5 execution failed due to undefined symbol: PQescapeLiteral amul sul 04:13
Re: DBT5 execution failed due to undefined symbol: PQescapeLiteral Albe Laurenz 07:26
Re: Function execute slow down in 9.2 Александр Белинский 12:27
Re: queries with DISTINCT / GROUP BY giving different plans Tomas Vondra 19:20
Re: queries with DISTINCT / GROUP BY giving different plans Tomas Vondra 19:36

Aug. 17, 2013

Thread Author Time
Create one query out of two Robert DiFalco 20:19

Aug. 18, 2013

Thread Author Time
Re: Create one query out of two Calvin Dodge 00:31
Re: Create one query out of two Kevin Grittner 20:23

Aug. 20, 2013

Thread Author Time
How to investiage slow insert problem Rural Hunter 01:44
Re: How to investiage slow insert problem Sergey Konoplev 02:38
Re: How to investiage slow insert problem Rural Hunter 02:45
Re: How to investiage slow insert problem Sergey Konoplev 03:01
Re: How to investiage slow insert problem Jeff Janes 04:34
Re: How to investiage slow insert problem 📎 Rural Hunter 05:30
Re: DBT5 execution failed due to undefined symbol: PQescapeLiteral amulsul 07:13
Re: queries with DISTINCT / GROUP BY giving different plans Tomas Vondra 15:13
Re: queries with DISTINCT / GROUP BY giving different plans Tom Lane 16:24
Re: queries with DISTINCT / GROUP BY giving different plans Tomas Vondra 17:56
Can query planner prefer a JOIN over a high-cost Function? David McNett 18:06
Re: Can query planner prefer a JOIN over a high-cost Function? Tom Lane 19:52
Re: queries with DISTINCT / GROUP BY giving different plans Tom Lane 21:02
Re: queries with DISTINCT / GROUP BY giving different plans Tomas Vondra 22:21
Re: queries with DISTINCT / GROUP BY giving different plans Tom Lane 23:32

Aug. 21, 2013

Thread Author Time
How to investiage slow insert problem Jeff Janes 00:24
Re: How to investiage slow insert problem Rural Hunter 01:33
Re: Function execute slow down in 9.2 Pavel Stehule 09:03
Re: How to investiage slow insert problem Matheus de Oliveira 13:10
Re: How to investiage slow insert problem Matheus de Oliveira 13:17

Aug. 22, 2013

Thread Author Time
PostgreSQL 9.2.4 very slow on laptop with windows 8 girish subbaramu 11:30
Re: PostgreSQL 9.2.4 very slow on laptop with windows 8 Imre Samu 15:25

Aug. 23, 2013

Thread Author Time
Re: PostgreSQL 9.2.4 very slow on laptop with windows 8 Richard Huxton 08:14

Aug. 26, 2013

Thread Author Time
Poor performance on simple queries compared to sql server express Adam Ma'ruf 05:09
Re: Poor performance on simple queries compared to sql server express Pavel Stehule 06:36
Re: PostgreSQL 9.2.4 very slow on laptop with windows 8 girish subbaramu 07:23
stable and immutable functions in GROUP BY clauses. Marc Mamin 11:03
SQL statement over 500% slower with 9.2 compared with 9.1 Rafael Martinez 12:33
Re: Poor performance on simple queries compared to sql server express Adam Ma'ruf 13:02
Re: Poor performance on simple queries compared to sql server express Tomas Vondra 13:40

Aug. 27, 2013

Thread Author Time
Re: Poor performance on simple queries compared to sql server express Adam Ma'ruf 04:06
Cpu usage 100% on slave. s_lock problem. Дмитрий Дегтярёв 07:57
Re: SQL statement over 500% slower with 9.2 compared with 9.1 Rafael Martinez 09:19
Re: Cpu usage 100% on slave. s_lock problem. Merlin Moncure 13:23
Re: Cpu usage 100% on slave. s_lock problem. Merlin Moncure 13:38
Re: Cpu usage 100% on slave. s_lock problem. 📎 Merlin Moncure 14:12
Re: Cpu usage 100% on slave. s_lock problem. 📎 Merlin Moncure 14:57
Re: Cpu usage 100% on slave. s_lock problem. Andres Freund 15:55
Re: Cpu usage 100% on slave. s_lock problem. 📎 Merlin Moncure 17:17
Re: SQL statement over 500% slower with 9.2 compared with 9.1 Tomas Vondra 21:27
Re: Poor performance on simple queries compared to sql server express Tomas Vondra 21:37

Aug. 28, 2013

Thread Author Time
Re: SQL statement over 500% slower with 9.2 compared with 9.1 Jeff Janes 04:10
Re: SQL statement over 500% slower with 9.2 compared with 9.1 Rafael Martinez 09:07
Re: SQL statement over 500% slower with 9.2 compared with 9.1 Rafael Martinez 10:15
Re: SQL statement over 500% slower with 9.2 compared with 9.1 Tom Lane 19:08
Poor OFFSET performance in PostgreSQL 9.1.6 📎 fburgess 20:39
Re: Poor OFFSET performance in PostgreSQL 9.1.6 Greg Spiegelberg 21:26
Re: Poor OFFSET performance in PostgreSQL 9.1.6 📎 fburgess 22:08
Re: Poor OFFSET performance in PostgreSQL 9.1.6 Merlin Moncure 23:10

Aug. 29, 2013

Thread Author Time
Re: Poor OFFSET performance in PostgreSQL 9.1.6 David Rowley 04:43
Re: Poor OFFSET performance in PostgreSQL 9.1.6 hubert depesz lubaczewski 11:00
How clustering for scale out works in PostgreSQL bsreejithin 12:14
Re: How clustering for scale out works in PostgreSQL Richard Huxton 14:59
Re: How clustering for scale out works in PostgreSQL Joshua D. Drake 15:08
Re: How clustering for scale out works in PostgreSQL bsreejithin 16:13
Re: How clustering for scale out works in PostgreSQL Mike Blackwell 16:21
Re: How clustering for scale out works in PostgreSQL bsreejithin 16:42
Re: How clustering for scale out works in PostgreSQL Joshua D. Drake 16:46
Re: How clustering for scale out works in PostgreSQL Igor Neyman 16:49
Re: How clustering for scale out works in PostgreSQL bsreejithin 16:52
Re: How clustering for scale out works in PostgreSQL bsreejithin 16:54
Re: How clustering for scale out works in PostgreSQL Thomas Kellerer 17:45
Re: How clustering for scale out works in PostgreSQL bsreejithin 17:48

Aug. 30, 2013

Thread Author Time
Optimising views Bastiaan Olij 02:22
Query plan change with multiple elements in IN clause 📎 Mathieu De Zutter 09:05
Re: Query plan change with multiple elements in IN clause Tom Lane 14:00

Aug. 31, 2013

Thread Author Time
Varchar vs foreign key vs enumerator - table and index size Łukasz Walkowski 13:35

Browse Archives

Prev | Next